Comodo AV for Linux

[keniv]

Ah, you're getting things confused here, mate.....and it's easy to do. Took me a wee while to figure it out.

There's two separate updaters within the program. One updates the antivirus signature database. The other is the updater for the actual program itself.

Your pictures 'window5' & 'window6' are the program updater.

That explains why I was convinced that it had updated the first time I tried. I think I updated the program.
I've had another go at updating the but again it did not work. Here is what I did,
I clicked on the directory on my desktop to open it see win-a. I clicked on
comodo-antivirus.desktop. When the window appeared I clicked on antivirus brining up win-b. I the went back to win-a and clicked on cmdagent. then I win-b I clicked update virus database. This brought up win-c. However, win-c just sits like this as long as I care to leave it. If I look at processes duering this time I see cav running between 0.5-1.0% of cpu. Below are images of the windows I mentioned.

Regards,

Ken.

Edit It struck me that it might matter where the directory containing the two sys linked files were place. I made a new Directoty in /my-applications and deleted the other but it made no difference.

[keniv]

I think my problem is still with running cmdagent. If I run it in a terminal I still get this.

Code: Select all

# /opt/COMODO/cmdagent
Unable to load library icui18n "Cannot load library icui18n: (icui18n: cannot open shared object file: No such file or directory)"

You can see at the top of win-usr-lib below the two sys links and icui18n.so.51.2 file are in /usr/lib. Is this definately the correct place for them?

Regards,

Ken.

[Mike Walsh]

Hi, Ken.

Just to show it does work in Precise, here's the updater running:-



...and finished:-



So it does function. However, I suspect you've got some more missing dependencies. This is pure speculation, but I originally had to install libicui18n.so around 2 years ago when I was trying to get Chromium to run on here. To get the system completely happy, I then had to 'install' a further 6 libs. These all appear to be Python dependencies.....but the first 3 aren't happy working without these 6.

So; give these a try, and let me know if it helps. Put 'em in /usr/lib, same as the others. I'm afraid this one's quite a sizeable chunk of data..!

http://www.datafilehost.com/d/28538ffa

Let me know what happens, please. If this don't work, I'll drag myself off my lazy arse, hightail it up the A1 to Bonnie Scotland, and we'll beat the bugger into submission...!!

If it runs on mine, it'll run on yours.


Mike.

[keniv]

Hello Mike,
Thanks again for the extra files. Installed them as instructed but I still get the same result. Tried running /opt/COMODO/cmdagent but also get the same result.

Code: Select all

# /opt/COMODO/cmdagent
Unable to load library icui18n "Cannot load library icui18n: (icui18n: cannot open shared object file: No such file or directory)" 
# 

Regards,

Ken.

[bigpup]

In your image of /usr/lib directory.

libicui18n is shown as a symbolic link.
Link to what?

If this is a 64bit version of Slackware.
Should be a /usr/lib64 directory with 64 bit versions of lib's.

[Mike Walsh]

Hi, Ken.

Hm. Odd. I think it's time we tried a trick I came across a while ago, which I've never had to use myself.....but it may work in your case.

In a terminal, enter:-

Code: Select all

ldconfig

This is supposed to help the system to 'see' files (like libs) that you've installed manually. After you've done that, do a reboot, and try Comodo again, following the same tricks & tips as before.

Let us know what happens.


Mike.

[keniv]

Hi Mike,
Here,s what happened when I ran ldconfig in a terminal.

Code: Select all

# ldconfig
bash: ldconfig: command not found
# 

I don't understand this as I remember having to use it before to install a lexmark printer I used to have in Puppy. I searched for it using pfind. It turned out to be a directory containing what I thought was an unrelated file. see win1 and win2.

Hi bigpup,
libicui18n is sys linked to libicui18n.so.51.2 as is libicui18n.so.51. These are some of the files Mike gave me to install.

Regards,

Ken.
PS I seem to remember I had to install ldconfig when I used it before. I'll try that and report back.

[keniv]

Found I had to install the devx to get ldgonfig. Did this and ran ldconfig. It worked this time. I left the devx installed as I thought I might be missing something that's in it. Shutdown and rebooted and tried COMODO again but got the same as before. Tried running /opt/COMODO/cmdagent and got the same as before.

Code: Select all

# /opt/COMODO/cmdagent
Unable to load library icui18n "Cannot load library icui18n: (icui18n: cannot open shared object file: No such file or directory)" 
# 

Regards,

Ken.

[bigpup]

Hi bigpup,
libicui18n is sys linked to libicui18n.so.51.2 as is libicui18n.so.51. These are some of the files Mike gave me to install.

I am in Xenialpup64, so I do not have same files as you.
Does properties of libicui18n.so.51.2 indicate it is a file of some size and permissions?
Similar to this one:

[keniv]

[quote="bigpup"

Does properties of libicui18n.so.51.2 indicate it is a file of some size and permissions?
Similar to this one:

Hello bigpup,
It looks similar to yours (see image) except for the permissions and run action. Could the fact that it shows no run action for this file be the issue?

Regards,

Ken.[/quote]

[bigpup]

Could the fact that it shows no run action for this file be the issue?

I would say yes, maybe.
Not sure how to change that.

Compare it to some of the other files in /usr/lib and see what they show for run action.

[Mike Walsh]

Afternoon, all.

@Ken: To get it showing as 'Execute file' (you've got the execute boxes checked already), all it should need is to hit the 'Refresh' button to the right of 'Close'.

That should change it from 'No run action defined' to 'Execute file'. Change things back & forth a couple of times by checking/unchecking the boxes & using the 'Refresh' button. You'll soon see how it works

That's the way I do it, anyway. However, AFAIK you don't do that with libs; they should be 'read-only', as far as applications are concerned. And anyway, the libs don't show up as 'application/x-executable'; you couldn't set them to run/execute if you tried, 'cos the system won't allow it.

Edit:- I believe you can do that by right-clk->Set Run Action.....and then entering an appropriate command in the box at the bottom, followed by 'OK'.


Mike.

[keniv]

Hello Mike/ bigpup,
I tried pressing the refresh button in the properties window several times but I am not sure that this did anything, I tried running comodo after each but got the same outcome as before. I've looked at the run action for a number of lib files in usr/lib. A number had no run action but I did find some that had the same run action as the one that bigpup posted ie listdd_wrapper so I went for that one. I used set run action to change the run action for libicui18n.so.51.2 to listdd_wrapper written in the same way as in bigpups properties window. This did appear to work. I clicked on the window to make it close then opend it again. I repeated this a number of times to make sure that it stuck and it did. I then tried to update the virus signitures in comodo but got the same result. I tried running/opt/COMODO/cmdagent in a terminal and got the same result as previously. However the new run action for this file shows up in both properties and set run action (see images). I presume If I find the correct run action this would be at least one step further forward.

Regards,

Ken.

[bigphil]

Hello all,
I'm a bit late posting in this thread because I have been using avast4workstions1.3.0 which they have recently stopped supporting so I'm attempting to get Comodo running.

I'm running Tahrpup 605 32 bit version.

The Comodo gui runs ok using the sfs from Mikes first post however on startup it reports COMODO Application not running so I run cmdagent as stated in a previous post and it then reports Filesystem filter driver is not loaded which I understand does not matter. I then attempt to update the virus database and it then goes back to report COMODO Application not running and the update window sits at 0% for ever.

Have you clever people got any ideas.

Regards
Phil.

[Mike Walsh]

Hi, bigphil.

Mmm... Sounds like you've got the CAV 'blues', all right!

TBH, Tahrpup is one where I've never been able to get the updater to run correctly myself. I get around this because I run around 10 Pups in total. I have a remote data partition where I keep a lot of my common applications that are used in all Pups. From here, I make use of Puppy's very powerful 'sym-link' function to link these progs/apps into each Pup at the appropriate locations.....and each Pup thinks they're installed locally.

The CAV updater works fine in some Pups, not in others; we never could figure out why, either. I only run occasional scans, more for form's sake than anything else; with the firewall in Linux, along with the robust permissions system, anything else isn't really needed. I put this package together more for others who like to use every available means at their disposal to keep things secure.....and because I used Comodo's stuff in XP for years beyond count, and never had any problems with my system.

Because I'm using one 'common', 'linked' install of CAV, that also means one 'common' database between Pups.....so I can guarantee that if I happen to be in a Pup where the updater refuses to function, the database will have been recently updated in one of the others.

I'm not too fussed whether the last 'update' may have been a couple of days previous; the Linux AV database isn't as regularly updated as the Whinedoze version is anyway!

Sorry that isn't of more use to you.....but I felt an explanation of my own personal use-case was indicated in this instance. One thought that's just occurred to me is that it could be to do with the versions of libpam.so & libaudit.so in use here; I forget exactly which Pup I packaged this up in, but with the multiplicity of different kernel variants and versions of the glibc in use across our Puppies, it's quite on the cards that the newer Pups want newer versions of these libs for everything to function properly. I believe libpam is used to link to SQL databases, so that could in fact be the culprit.

I'll have to investigate a wee bit more in-depth on this. Watch this space...

EDIT:- Yup, I'll bet pounds to peanuts libpam (Pluggable Authentication Module) is our culprit. It's used mainly for authentication to/from high-level APIs (i.e., our CAV application).

http://www.tuxradar.com/content/how-pam-works

And I can guarantee that connecting to a remote database would require authentication of some kind. I'll have to see if there's a newer version available through the PPM...


Mike.

[bigphil]

Hi Mike,

thanks for replying to my post.

Would you recommend a 'lightweight' Pup that I can install that will run the updater, at least using this approach I will have an on demand virus checker.

I have two Pups currently installed, Tahrpup and Precise 5.7.1. both frugal installs, both exhibit the same problem with the updater.

My system is somewhat like yours in as much as I keep a lot of applications etc. in one location and use symbolic links in both Pups to access them. Never have figured out the difference between relative and absolute links.

Still trying to get my head around libpam you mentioned in your post, however their is many instances of it in the PPM, all from the Ubuntu repositories.

Once again thanks for your help.

Phil

[Mike Walsh]

Hi again, Phil.

Would you recommend a 'lightweight' Pup that I can install that will run the updater, at least using this approach I will have an on demand virus checker?

Well, now...

I'm starting to think summat's happened with CAV itself. Either that, or Comodo have made changes at their end.

Prior to today, I had the updater working in at least four other Pups. Today, it refuses to co-operate in any of them...

Not one. So; until I investigate a wee bit further, I don't quite know what to suggest, mate. All I can say is, leave it with me. This could of course be my 'common' install playing up, but I won't know until I make the time to take a closer look at it.

May be a couple of days before I have something more concrete to report.....


Mike.

[bigphil]

Sorry to hear you are having problems Mike, I'll watch this space.

Regards
Phil

[bigphil]

I downloaded the 64 bit deb package from the Comodo website and installed it on my 64 bit machine running tahrpup 64. It ran 'out of the box' and the virus database updated OK as stated in previous posts.

I then downloaded the 32 bit deb package and installed it on my 32 bit machine (the one I couldn't get the database to update) with Tahrpup 32 bit version running. Voila - the database updated and it scans OK, still doesn't run cmdagent on initialization though.

Regards

Phil

[Mike Walsh]

Hi, Phil.

Hm. Well, I'm pleased to hear it's behaving itself at last.

Part of the problem with cmdagent, I believe, is the fact that Comodo have written that package for Debian-based systems, so a good bit of the syntax is different to what Puppy uses. Although many Pups are based around Ubuntu 'binaries', and hence, indirectly, Debian 'binaries', Pup doesn't run in the same way. Indeed, the standard terminal 'vocabulary' is rather abbreviated, since quite a bit of it is to do with the multi-user demands of a conventional distro.

Two ways round it. One, you can write a line for cmdagent itself into the start-up script. Two, you can simply drag cmdagent onto the desktop in a convenient (for you) location, and simply click on it as & when necessary.....which is probably the easiest option, TBH.

At least it's working..... That's the main thing.


Mike.