Got a firewall yet?

[agreimann]

Guys,

Do we have a firewall in Porteus? If not, do we really need one? I'm just curious where things stand on that, and/or whether we should spin in a firewall package into the next release or not...

-- Andrew

[Ahau]

See Porteus Tips and Tricks, #10:

http://porteus.org/info/docs/57-general ... ks.html#10

Let us know if that is insufficient.

Thanks!

[agreimann]

Seems I went into that one kind of fast. I guess we have a firewall after all, just not enabled by default, then. Thanks, Ahau.

[mikeruss]

I am trying to setup a firewall which blocks port 80 apart from specified URLs. On slax I used guarddog - I converted the guarddog.lzm to .xzm and it seems to work OK, but on activating the firewall I couldnt load any programs.

I am a linux novice - any ideas what I am doing wrong, or is there a firewall GUI that works ?

thanks .. Mike

[Ahau]

Hi Mike,

Could you please tell us what error message (if any) you receive when you try to load programs? If there is no message, cany give us a better description of what's happenning (for example, do you click on an application in the menu, and nothing seems to happen? does your system lock up?) -- If no error message is displayed, please try starting the application from a console, just type the application name, e.g. 'firefox', and you should get some kind of error there.

Are you using this module: http://www.slax.org/modules.php?action=detail&id=2335
and this dependency: http://www.slax.org/modules.php?action=detail&id=2860
?

If not, please provide a link to the modules you are using. If you are using the ones referenced above, I'll d/l those and test them out to see if I can reproduce the error.

Thanks!

[mikeruss]

thanks for the help Ahau

yes thats the correct module and I have also converted the lib audio dependancy

terminal and firefox wont run - they produce "Klauncher could not be reached by DCOP"

other programs dont respond at all - system appears dead

but menu still works

[Ahau]

the DCOP issue a known bug, with a fix on our server. Please download it here:

http://porteus.org/distro-download/down ... 2-bit.html

You can get the other fixes while you're at it. They can all go in your /porteus/modules folder, except the linuxrc patch. To apply that one, download it to your desktop, right click on it and tell it to extract xzm module, then enter the extracted folder and copy initrd.xz to /boot/initrd.xz (overwriting the existing initrd.xz).

I've tested guarddog with the DCOP fix in place, and it seems to work fine.

Please let us know if you have any other issues.

Thanks!

[mikeruss]

sorry to be a pain - but no change.

everything works fine until I load guarddog (which works OK), but I then get the DCOP error

have checked and there is a new version of initrd.xz in /boot, and 5 fixes at 4K each in /porteus/modules

Posted after 6 minutes 7 seconds:
contents of /porteus/modules

H:\porteus\modules\save.dat_manager-1.0-fix.xzm
H:\porteus\modules\magic_folders-1.0-fix.xzm
H:\porteus\modules\kwrite_as_default-1.0-fix.xzm
H:\porteus\modules\firefox_useragent-1.0-fix.xzm
H:\porteus\modules\DCOP_error-1.0-fix.xzm
H:\porteus\modules\libaudio2-1.8-4-i386.deb.xzm
H:\porteus\modules\guarddog-2.6.0-2.1-slax609.xzm
H:\porteus\modules\535-google-earth-4.3.xzm
H:\porteus\modules\2191-keepassx-0.3.3-i686-1mch.xzm

and in /boot
H:\boot\initrd.xz dated 28/6/2011 - 0226

[Ahau]

Are you by chance using saved changes? If so, you might have a file in your /changes directory (or save.dat container) that is still fouling things up -- try booting to always fresh mode and testing there.

[mikeruss]

no I deleted the .dat file as it got corrupted with the DCOP problem

[Ahau]

I'll have to do some more testing on this tonight, to see if I can replicate the error. Thanks for your patience!

Posted after 8 hours 37 minutes 6 seconds:
I was able to repeat this behavior when testing as guest user (my bad before, sorry!)

here's a quick fix for now:

su
toor
cp /mnt/sdXY/porteus/modules/guarddog.xzm /root
mkdir guarddog
xzm2dir guarddog.xzm guarddog
cd guarddog/usr/share/applications
kwrite guarddog.desktop

then, replace the contents of the file with the following:

Code: Select all

[Desktop Entry]
Type=Application
Name=Guarddog
GenericName=Firewall configuration utility
GenericName[ca]=Eina de configuració del tallafocs
GenericName[es]=Herramienta de configuración del cortafuegos
Comment=Configure the firewall
Comment[ca]=Configureu el tallafocs
Comment[es]=Configurar el cortafuegos
Exec=/usr/local/bin/kdesu guarddog
Icon=guarddog
Terminal=false
X-KDE-DocPath=guarddog/index.html
#X-KDE-RootOnly=true
#X-KDE-SubstituteUID=true
#X-KDE-Username=root
Categories=Network;

then,

cd /root/
dir2xzm guarddog guarddogfixed.xzm
mv guarddogfixed.xzm /mnt/sdXY/porteus/modules/
rm /mnt/sdXY/porteus/guarddog.xzm #remove the old module

of course, substituting whatever the actual module names are.

This is the same DCOP issue we had before. The problem is the guarddog calls it via the X-KDE-RootOnly=true option, and we only fixed /usr/local/bin/kdesu. All I've done is routed the call to the program through fanthom's fix.

Let me know if that doesn't work.

[mikeruss]

that works fine - thank you

presumably this will be wrapped into a future fix and I can go back to the original guarddog.xzm ?

[Ahau]

I hope so. IIRC, this is an upstream bug in Trinity, so the Trinity developers should be working on resolving it. Otherwise, it will depend on the workarounds that we can come up with here.