[nottingham] SuSE7.1 - Initial impressions and Personal Firewall Info

From: Robert Davies (Rob_Davies@NTLWorld.Com)
Date: Sun 06 May 2001 - 00:38:57 BST


This is intended mainly for the SuSE interest group in Nottingham, but there
was a request a while back about SuSE on the Leicester list, so I've sent to
both, ignore if it's not relevant to you!

Been playing around with it quite a bit this week, general impression good,
suitable for 1st time Linux user as well as techies. Used a mix of ext2 and
ReiserFS and both 2.2.18 and 2.4 kernels, so far without mishap. I
overclocked the HW and manged to produce some lockups, it takes some getting
used to, not having an fsck run after a crash before an fs is mounted, and I
even switched kernel versions post crash, without troubles. ReiserFS is in
the main kernel tree from 2.4.1 so it should rapidly gain wider use and
hopefully prove reliable.

The default KDE is pretty acceptable, and I've not seen any stability
problems. Menus seem clearer and better thought out than old, and the whole
distribution has a much maturer and more professional feel. Sadly the
messages wishing you a lot of fun on login, appear to have bit the dust.
Actually KDE2 is pretty intuitive, I soon found myself tailoring a few
items, which is something I resisted doing with Gnome under Redhat, even
after a year of using it. If you find that odd, it's because I've used and
hopped between many different systems, so I got bored of customising the
interfaces and tend to live with whatever the default is, unless it's really
terrible. KDE on Redhat never ran as stabley as it has done for me on
Caldera and SuSE. Kandalf's tips were actually useful, and I found myself
learning something about the GUI, quite scary, as normally I get confused by
wizards ;)

There's a very nifty boot menu with lilo, which is similar to boot magic,
but with Tux present, and best of all a boot option to memtest86, which will
cut down support work, as you can rule out crashes due to RAM problems
quickly.

If you use the 2.2 series kernel, then DMA is not enabled on disks by
default, but you can set that with Yast2 if you look in the System
Optimisations section (poss under Hardware). Alternatively figure out how
to get an append line added to the 2.2 entry in lilo.conf 'ide0=dma
ide1=dma', or a script which runs 'hdparm -d 1 -u 1 -c 1 /dev/hd<disk>'.
Disk throughput seems a little quicker with 2.4, though my figures were less
than I'd expect on my main system, which has a higher quality motherboard.
Will def. check this.

top shows with 2.4 a daemon called kapm-idled which oddly tends to grab
about 25-39% of the CPU time, I've read something about this in summaries of
the kernel mailing list, so I decided not to worry about it.

Have used an NTLWorld free Erlang pretty much solid, so far downloaded about
230MB of KDE 2.1.1 updates, and plan to produce a CD-RW or CD-R if anyone
interested in one. Probably I'll mirror the update tree, and a CD source
can be used rather than the net, in the Yast2 auto update configuration.

Auto update looks quite well done, you get to choose the source (a la apt),
and have choice of auto or manual authorisation of rpm updates it decides it
needs to make.

The other Nottingham Rob, asked before about setting up the Personal
Firewall. This is actually very easy, you just start Yast2, and click on
Misc, then the rc-config editor. Under Firewall, there's an item SuSE
Personal Firewall, which has one variable with a number of options. From
what I can see all you need is to change the 'no' to be 'ppp0' for the
reject incoming connections. Of course you could just use vi and edit the
config file, rc.config :)

As far as I can see, this will simply use the -y option in ipchains to
prevent incoming connections, they talk about blocking UDP as well, but I've
not inspected their scripts. Anyone turning this on will break protocols
which require, reverse connections to be initiated by the server ie. non
passive mode ftp, DCC and CTCP IRC connections, real audio/video and *da da*
most seriously Quake. If this is a problem for you, you could add rules to
permit these connections into the INPUT chain.

As by default inetd is not even started, a netstat -l shows daemons
listening on very few ports, two of them were to do with Sun RPC. It should
be possible to bolt down the portmapper, through access rules, or ipchains
rules if you are especially paranoid.

The default installation certainly tightens up security considerably, on say
RH 6.2 or 7.0. There are also options to tighten file permissions, and
account for machine class eg) workstation, networked, server.

Rob

--------------------------------------------------------------------
http://www.lug.org.uk http://www.linuxportal.co.uk
http://www.linuxjob.co.uk http://www.linuxshop.co.uk
--------------------------------------------------------------------



This archive was generated by hypermail 2.1.3 : Thu 22 Nov 2001 - 13:11:57 GMT