• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

ClamAV GUI version 2.0.0

Started by CDRWSel, 2011.02.09, 09:56:57

Previous topic - Next topic

CDRWSel

Hi Dave,

Ok

DefaultMailParameters seems strange because "-compose" is thunderbird parm.
It  looks for me more interesting to have
DefaultMailParameters  -cwd  C:\programs\PMMail\Accounts

then, I didn't expect to see
DefaultMailWorkingDir   C:\programs\PMMail\Accounts      << this is account path !
I wrote the program in hope to find
DefaultMailWorkingDir   C:\programs\PMMail\bin               << same as suggested by Jep 

Now I know why it fail. I have to review my code to be able to manage parms like you have.
Until I did changes, could you do a try changing to:

DefaultMailParameters    -cwd  "C:\programs\PMMail\Accounts"   
(I set this when defaultmailexe is not Pmmail and you set "use it as default")

and
DefaultMailWorkingDir   C:\programs\PMMail\bin

don't forget to add the trailing blanks    '00'x   

CDRWSel

Hi Dave,

Please replace the exe file with this new one and tell how it works.
http://remydodin.levillage.org/outils/ClamAVGUI.ziq    (rename ziq ti zip)

Thanks

Kind regards,
Remy

David McKenna

Hi Remy,

  I removed '-compose' from DefaultMailParameters (don't know how that got there - maybe  from original eCS install?) and replaced ClamAVGUI.exe with this new one you suggest and now the 'write to GUI author' starts PMMail with Subject and your e-mail address inserted. Thanks!

Regards,

Dave McKenna

CDRWSel

Fine,

One more issue resolved.

Kind regards,
Remy

DougB

QuoteOne more issue resolved.

Perhaps not. It looks, to me, that David has his INI entries for PMMail messed up, somehow. They certainly are not right. These are the ones that should be there:

[HINI_USER_PROFILE\PMMail/2]
InstallRoot="W:\APPS\PMMail\BIN"
(path should, of course, match reality)

[HINI_USER_PROFILE\WPURLDEFAULTSETTINGS]
DefaultMailExe="W:\APPS\PMMail\BIN\pmmail.exe"
DefaultMailWorkingDir="W:\APPS\PMMail\Accounts"
DefaultMailParameters="-cwd W:\APPS\PMMail\Accounts -s DOUGB00.ACT"
(again, the paths need to match reality).

There are a couple of other entries, but they are not involved with what you want to do.

This will be set properly (IF you have not changed the location of the Accounts directory) by the migration tool, when it makes PMMail the default mail program (it is a stand alone option in the migration tool). Note that the Internet Application Integration program does NOT do it properly, and Chuck has declined to fix the problem, but it can be entered manually using IAI. What has been quoted looks like what IAI does. The DefaultMailParameters is the command to PMMail to open a compose window, in the specified account. All of that should be followed by the To: CC: Subject: and whatever else you want, in the same format as Firefox sends it in a Mailto: link. There is more information in the PMMail FAQ at:
http://pmmail.os2voice.org/index.php?title=PMMail_FAQ

David McKenna

Doug,

  Thanks for the heads-up about IAI (yes... I was using that). Fixed my entries as you suggest and still ClamAVGUI 'write to GUI Author' works fine. Maybe because I only have one account...

  I am intrigued by your suggestions for using ClamAV with PMMail and plan on giving them a try. Maybe they are something that can be added to a future version of PMMail...

Regards,

Dave McKenna

DougB

QuoteMaybe they are something that can be added to a future version of PMMail...

We discussed that, a couple of years ago, but ClamAV is not a very friendly OS/2 application, as you can see by what has been required to make it work with ClamAVGUI. My REXX script seems to work well, but it did require the addition of the UNIXROOT thing, after the ClamAV 0.96.4.4 update (possibly because of the way that I install it, and use it, plus UNIXROOT is used by SAMBA). It was decided that ClamAV was better supported by an external REXX program, which is the way that I use it, rather than try to keep up with it inside of PMMail. Perhaps that is not ideal from a user perspective, but from a developer perspective, it makes sense. There is really only one person working on PMMail, and he is overloaded already, so it is best to avoid loading him up with even more work, when it isn't necessary. That doesn't mean that it will never be done, but I can't see it happening in the foreseeable future.

QuoteClamAV-GUI doesn't need unixroot an I may suggest you give it a try :-D

I have tried it, and I don't like the way you do it (just my own preference, there is really nothing wrong with what you do), although SAMBA quit working after I installed ClamAVGUI, so I uninstalled it (Samba is more important). My own preference is to call ClamDScan.exe from a batch file, when that is appropriate (like from PMMail), otherwise, I have set the associations to have ClamDScan associated with every file, and adding a shadow of ClamDScan.exe to the  Extended Menu Options (X/eWorkplace) adds it to the popup menu for drives, and directories. A simple right click-> Open As-> ClamDScan.exe, and it scans the file. Or, RMB the drive, or directory, and ClamDScan is one of the options. I set ClamDScan so that it doesn't close the window when it is finished, and I can see the summary before closing the window. Not as flashy as what you did, but just as effective.

FWIW, I do trap an incoming mail virus, every once in a while, but i don't think I ever caught one lurking on my system otherwise.

CDRWSel

#37
Quote from: DougB on 2011.02.22, 02:17:10
QuoteOne more issue resolved.

Perhaps not. It looks, to me, that David has his INI entries for PMMail messed up, somehow. They certainly are not right. These are the ones that should be there:

[HINI_USER_PROFILE\PMMail/2]
InstallRoot="W:\APPS\PMMail\BIN"
(path should, of course, match reality)

[HINI_USER_PROFILE\WPURLDEFAULTSETTINGS]
DefaultMailExe="W:\APPS\PMMail\BIN\pmmail.exe"
DefaultMailWorkingDir="W:\APPS\PMMail\Accounts"
DefaultMailParameters="-cwd W:\APPS\PMMail\Accounts -s DOUGB00.ACT"
(again, the paths need to match reality).

I'm sure he has InstallRoot correct or it will not start
About other entries,  only
DefaultMailParameters="-cwd W:\APPS\PMMail\Accounts -s DOUGB00.ACT"
Wasn't correctly set but no need to have the account name appended to the parms.
(See PMMail doc)
Having  DefaultMailParameters="-cwd C:\programs\PMMail\Accounts" is enought and correct
Only in case of migration and with more accounts, adding the account name is helpfull here

But no matter about how his ini entries are. I do several check and able to start PMMail if default ini entries are set or not and if DefaultMailParameters are bad, I'm able to try new default parms....
What is making you tell "Parhaps NO" about my ClamAV-GUI resolved PMMail issue when starting it ?
Did you analyze my code ?  
 

CDRWSel

#38
Quote from: DougB on 2011.02.22, 07:50:48

QuoteClamAV-GUI doesn't need unixroot an I may suggest you give it a try :-D

I have tried it, and I don't like the way you do it (just my own preference, there is really nothing wrong with what you do), although SAMBA quit working after I installed ClamAVGUI, so I uninstalled it (Samba is more important).


Humm !
You didn't understand how UNIXROOT is used when installed via the "not official" ClamAV WPI build I did and how it is used with ClamAV-GUI
(You may see that what you have no reason to do it like you do)  

Let me tell you how the UNIXROOT is used when WPI installed.
The only required path using UNIXROOT is for the ClamAV database (This isn't the case when using RPM/YUM)

Why don't you add required ClamAV database under your existing UNIXROOT path ?
Realy, there is no need to create a batch programs to set environment variable and run ClamAV from it!        

Under a second system, I have ClamAV installed under  C:\programs\ClamAV
and "SET UNIXROOT=E:"     << see, it is not ClamAV installation path

How to do ?
Add under UNIXROOT used by SAMBA following directories
SAMBA_UNIXROOT\var\lib\clamav
That's all for "unixroot" and nothing to install  

Now, under ClamAV-GUI, set manually the database path to this created path and save despite the red led is on.  Run database update and it will updated config file and load database files into the right directory.  That's all and very easy to do (no batch or extra process to use and your SAMBA as well as ClamAV will work)

This is much easier to do as your suggestion  ;)

Futur ClamAV have more products dependencies and my latest tested WPI always fail depite adding more required dlls - internal error - It seems requiring RPM/YUM process :(
This may suppose you to review all your installation !

ClamAV is compatible with ClamAV WPI or RPM/YUM packaged  


Hi Dave,
Just create lists for you PMMail and you can scan it at request but if you start ClamD, no need to scan you PMMail path, mails are checked by ClamAV daemon     

Best regards,
Remy

DougB

QuoteDefaultMailParameters="-cwd W:\APPS\PMMail\Accounts -s DOUGB00.ACT"
Wasn't correctly set but no need to have the account name appended to the parms.
(See PMMail doc)

Well, a single account might work without that, but you may find that a user doesn't always want to use the first account that is found.

QuoteWhat is making you tell "Parhaps NO" about my ClamAV-GUI resolved PMMail issue when starting it ?
Did you analyze my code ?

I have been working with the new PMMail, for a few years now (as alpha, beta tester, plus support). I also wrote the migration tool, so I do have some insight into how it all works. You will find that not having the account defined can cause problems.

QuoteYou didn't understand how UNIXROOT is used when installed via the "not official" ClamAV WPI build I did and how it is used with ClamAV-GUI
(You may see that what you have no reason to do it like you do)

I do it the way that I do, because it works for me. UNIXROOT is a hard coded directory structure in *NIX, that I do not like, and I try to avoid using it whenever possible - even to the point of not using programs that insist on using that structure. My usual work around is to define a unique UNIXROOT for each program that wants to use that nonsense. How I do that depends on how the program uses UNIXROOT. Usually, I just add a new setting to point to the program install directory as the UNIXROOT path. I do that with DragText, most of the time, but RUN! will also do it, or I can simply use a wrapper cmd file. I haven't taken the time to try to get SAMBA sorted out, because it is delicate enough, without adding more possible ways for it to fail. How you use it is up to you, I am not particularly impressed with ClamAVGUI (my own preference, not a reflection on your work), so I don't intend to use it. I do like to have an AV program, and ClamAV seems to be the only choice for OS/2, so I use it, but I use it in the way that I like to use OS/2, I don't need a "front end" processor for that, the WPS does the job, in the way that I like to use OS/2.

QuoteThe only required path using UNIXROOT is for the ClamAV database (This isn't the case when using RPM/YUM)

Actually it is, because RPM/YUM takes over the UNIXROOT thing, and all programs must use it, or they won't work with RPM/YUM.

QuoteWhy don't you add required ClamAV database under your existing UNIXROOT path ?

Not a chance. My default UNIXROOT path is c:\MPTN\ETC (what SAMBA insists on using). There is already way too much junk in there, and it is on my boot drive, where I really don't want anything, except the actual OS2/eCS stuff. I like to be able to just install a new eCS, and pick everything else up from one of the other drives.

QuoteRealy, there is no need to create a batch programs to set environment variable and run ClamAV from it!

Well, there is, because PMMail links to outside programs using REXX exits. Since I will not use the default UNIXROOT entry in CONFIG.SYS, I need to set the UNIXROOT that I want ClamAV to use. I will, probably, change the way I do it, to use RUN!, when I find the time.

QuoteUnder a second system, I have ClamAV installed under  C:\programs\ClamAV
and "SET UNIXROOT=E:"     << see, it is not ClamAV installation path

That is okay, but now your ClamAV update files will be on E:, not with the rest of the ClamAV stuff, where they should be (and ClamAV and/or ClamAVGUI, should NOT be on the boot drive). I am not sure what SAMBA would do with that either.

QuoteThis is much easier to do as your suggestion

Is it? Can I RMB on a file (any file) and select ClamDScan as one of the programs to handle that file? Can I RMB on a folder, or a drive, and have ClamDScan as an option? I don't want to open a new program just to scan a file, directory, or drive.

I think we will need to disagree about how to use ClamAV. I will use it, as long as I don't need to jump through hoops just to get the updated program, and make it work. I am not planning to use ClamAVGUI, because I don't like working that way, when I don't have to. One of the great things about OS2/eCS is that there are many ways to do things, so a user can do it in a way that they feel comfortable with. The *NIX world has many restrictions, that OS/2 does not have, until someone decides to force them upon the user, and UNIXROOT is one of them. I don't need to submit to using it, in the prescribed way, though.

CDRWSel

Hi Doug,

I understand you position and I agree with most of them.
RPM/YUM (I hate) but I had to do with those using it.

By default, there is no entries under WPS to call ClamDscan under WPS options.
This means you wrote a program to update WPS entries and add ClamDscan as option

Of course, you can drag/drop a file or a folder on ClamAV-GUI and it works with the advantage to have the a log file, use of your usual conf file etc... 
Only when you drag/drop more than one file, it opens one ClamAV instance and because it is the same time, there is a shared log access issue. This can be improved next....

Have a nice evening
Cheers
Remy
   

DougB

QuoteBy default, there is no entries under WPS to call ClamDscan under WPS options.
This means you wrote a program to update WPS entries and add ClamDscan as option

I wrote nothing. I just used the facilities that already exist. To associate ClamDScan with every file in the system, I make a program object (icon) for ClamDScan, and set the association to "*" (asterisk, without the quotes). Now, when I RMB on the icon of any file on the system, it is associated with ClamDScan, and ClamDScan is listed in the Open As menu, click, and it runs. By also setting ClamDScan so that it leaves the window open, after running, I see the results before I close the window. Adding ClamDScan to the folder and drives menus, requires X/eWorkplace. I just put a shadow of ClamDScan into the Extended Menu Options folder, and that does the job. There is actually a way to do that without using X/eWorkplace, but it has been many years since I did it, and now I don't remember how to do it.

QuoteOf course, you can drag/drop a file or a folder on ClamAV-GUI and it works with the advantage to have the a log file, use of your usual conf file etc...
Only when you drag/drop more than one file, it opens one ClamAV instance and because it is the same time, there is a shared log access issue. This can be improved next....

I see the log problem, if I select more than one file at a time (rarely useful). The log is created/updated when ClamDScan runs, using its config file, or parameters, to define the log file. Since I leave the window open, it is not necessary to look in the log file, unless I want to review something later. I can also drag/drop onto the icon, but that means that I need to find the icon first. Just a lot more effort than what is required.

BTW, if you use E.EXE, or AE.EXE, a log file that is being used will not open (poor program design, but that is the way it is). If you use EPM.EXE, it will open a locked log file, although it is usually in read only mode.

CDRWSel

#42
How to add "ClamAV scan..." under Folder menu ?    
Open:
"Local system" folder
     - Open "System Setup" folder
            - Open "Extented Menu Option" folder
              1/ Create a new program
              2/ Give the name as you want have it display under Folder Menu
              3/ Specify ClamAVGUI.exe full path as program path
              4/ Add default parms like it is under original program folder.
Save and close all
Now do a try

To edit contain of an open/inuse logfile:
Create a temporary file through:
TYPE logfile > tempfile
Edit tempfile

Kind regards,
Remy

David McKenna

Remy,

  I finally got a chance to play around with starting Clamd from CONFIG.SYS. When I use 'Start ClamDaemon' and allow it to insert a line in my CONFIG.SYS, the next boot hangs at MPTSTART. If I move that line to the end of all 'RUN=...' lines in CONFIG.SYS, then booting completes.

  Then when I start ClamAVGUI, it shows that 'ClamD is Running', but if I try to perform a scan (using Clamdscan) I get buzzing and a message: ERROR: Can't connect to clamd: Can't assign requested address.

One strange thing at this point is if I choose 'Clamdscan (conf)' it displays the file /etc/clamd.conf NOT C:\Programs\ClamAVGUI\clamd_GUI.conf (as directed by the clamd parameter '--config-file=...' added by ClamAVGUI in CONFIG.SYS). Going in to ClamAVGUI settings and saving, then using Clamdscan (conf) again displays C:\Programs\ClamAVGUI\clamd_GUI.conf. This is confusing - which file is clamd really using?

  If clamd is not started from CONFIG.SYS, but manually started from ClamAVGUI using 'Start ClamDaemon', then I can perform scans using clamdscan with no trouble. It's not clear to me what may be wrong...

Regards,

Dave McKenna

CDRWSel

Hi Dave,

"One strange thing at this point is if I choose 'Clamdscan (conf)' it displays the file /etc/clamd.conf"
Hum ! This may be a bug in my code when ClamAV is RPM/YUM installed. I'll check this.

About "Can't connect to clamd: ..." it looks like the parameters in config.sys are ignored. I will check what happens here...