[BCC'd to feedback@suse.de so as to avoid list replies going there] Having recently gone through the SuSE 7.1 installation four times in quick succession (yay for reinstalling after a break-in) I have some comments that the folks at SuSE, and users of SuSE, may or may not be interested in. Many of these are minor issues, but it's the attention to detail that makes a distro great, right? 1) When you are asked to choose a root password and a user password in the installation process (and presumably anywhere in YaST2) it doesn't allow the '@' character. I assume this is a bug. 2) The RPM update for apache conflicts with the update for mod_ssl; the update for apache also conflicts with various Perl apache modules. Easily gotten around with --nodeps, but annoying nonetheless. 3) If you install using YaST2, then attempt to save your installation config using YaST1, it will succeed, but the package list will not be recognized by YaST1 if you try to use it later. It really sucks to find this out right after your disk has been wiped for a reinstall. 3a) YaST2 should really have a way to save the config of a particular machine to floppy, and to load said configuration during an install, a la YaST1. It would have saved me loads of trouble. 4) The DM option in /etc/sendmail.cf is set to YAST_ASK, which is really annoying, because YaST never asked. So when sendmail didn't work I had to go track this down. 5) If you're using YaST2, and select "minimal install", it doesn't install X. This is fine, until the system installs LILO and restarts, at which point you get a blank screen because the system automatically went to tty7. If you know enough to press alt-f1, you get YaST2 back, but you have to know to do it. 6) If you want ypbind, and try to configure it using YaST1, it won't let you specify that you want to find an NIS server by broadcast instead of by IP. This has been a problem since at least SuSE 6.4. 7) The default configuration of the 3c90x ethernet module generates the following warning message on boot: insmod: Warning: /lib/modules/2.2.18/net/3c90x.o parameter switchdelay has max < min! Not a big deal, but it looks bad. 8) Right after my installation, I downloaded and installed the updates that SuSE had posted on the website. I later discovered the YaST2 online update. It's a great tool (and free, unlike RH up2date!), but it doesn't recognize when I've manually updated a package. So I had to let the program re-download and re-install all the patches that I'd already installed. Waste of bandwidth, really. 9) When I configured my static IP (no special routing or anything) I found that the default route wasn't ever added. So I had to go into the "expert" configuration and add it myself. So those are my nitpicks. I also want to express my happiness that the init scripts are now in /etc, and that the runlevels now match Redhat's. It makes it a lot easier to tar up and save system configurations, and to install generic RPMs without having to move around rcN symlinks. -tara
On Tue, 8 May 2001, Tara L Andrews wrote:
[BCC'd to feedback@suse.de so as to avoid list replies going there]
Thanks!
Having recently gone through the SuSE 7.1 installation four times in quick succession (yay for reinstalling after a break-in) I have some comments that the folks at SuSE, and users of SuSE, may or may not be interested in. Many of these are minor issues, but it's the attention to detail that makes a distro great, right?
Indeed, an we appreciate your feedback.
1) When you are asked to choose a root password and a user password in the installation process (and presumably anywhere in YaST2) it doesn't allow the '@' character. I assume this is a bug.
I am not sure, but you may be right here. I still haven't found a reference that describes all valid chars for usernames/passwords. If anyone has some docu about that, feel free to send me the info.
2) The RPM update for apache conflicts with the update for mod_ssl; the update for apache also conflicts with various Perl apache modules. Easily gotten around with --nodeps, but annoying nonetheless.
Hmm, does it conflict, or are dependencies missing? These are two different things.
3) If you install using YaST2, then attempt to save your installation config using YaST1, it will succeed, but the package list will not be recognized by YaST1 if you try to use it later. It really sucks to find this out right after your disk has been wiped for a reinstall.
Yes, unfortunately both YaSTs use a different format for this file :(
3a) YaST2 should really have a way to save the config of a particular machine to floppy, and to load said configuration during an install, a la YaST1. It would have saved me loads of trouble.
That's a good suggestion - I will forward it to the SaX developers.
4) The DM option in /etc/sendmail.cf is set to YAST_ASK, which is really annoying, because YaST never asked. So when sendmail didn't work I had to go track this down.
I assume, SuSEconfig is using a default value in this case, but I have no real clue here.
5) If you're using YaST2, and select "minimal install", it doesn't install X. This is fine, until the system installs LILO and restarts, at which point you get a blank screen because the system automatically went to tty7. If you know enough to press alt-f1, you get YaST2 back, but you have to know to do it.
AFAIK this has been fixed by now.
6) If you want ypbind, and try to configure it using YaST1, it won't let you specify that you want to find an NIS server by broadcast instead of by IP. This has been a problem since at least SuSE 6.4.
Our YP maintainer (and original author of NIS for Linux) is against doing this - I assume he has a valid reason for it.
7) The default configuration of the 3c90x ethernet module generates the following warning message on boot: insmod: Warning: /lib/modules/2.2.18/net/3c90x.o parameter switchdelay has max < min! Not a big deal, but it looks bad.
This should be fixed in the kernel sources, then.
8) Right after my installation, I downloaded and installed the updates that SuSE had posted on the website. I later discovered the YaST2 online update. It's a great tool (and free, unlike RH up2date!), but it doesn't recognize when I've manually updated a package. So I had to let the program re-download and re-install all the patches that I'd already installed. Waste of bandwidth, really.
Well, there is not much we can do here :)
9) When I configured my static IP (no special routing or anything) I found that the default route wasn't ever added. So I had to go into the "expert" configuration and add it myself.
How are we supposed to find your default route, if you do not provide it? Black magic? Or are you rather saying, the user interface is not optimal here?
So those are my nitpicks. I also want to express my happiness that the init scripts are now in /etc, and that the runlevels now match Redhat's.
No, they now match the current LSB specification draft, which happens to be similar to Red Hat and other distributions. :)
It makes it a lot easier to tar up and save system configurations, and to install generic RPMs without having to move around rcN symlinks.
Glad you like it! Thanks for your suggestions. LenZ -- ------------------------------------------------------------------ Lenz Grimmer SuSE GmbH mailto:grimmer@suse.de Schanzaeckerstr. 10 http://www.suse.de/~grimmer/ 90443 Nuernberg, Germany Say something soft & sweet. Marshmallow.
On Tue, May 08, 2001 at 02:21:17PM +0200, Lenz Grimmer wrote:
On Tue, 8 May 2001, Tara L Andrews wrote:
3) If you install using YaST2, then attempt to save your installation config using YaST1, it will succeed, but the package list will not be recognized by YaST1 if you try to use it later. It really sucks to find this out right after your disk has been wiped for a reinstall.
Yes, unfortunately both YaSTs use a different format for this file :(
Lenz, do you mean if I installed with YaST2, then save configuration using YaST1 onto floppy, the saved configuration is unusable? I don't remember what I used to install 7.1, but most probably it was YaST2. Later I saved my configuration on a floppy using YaST1. When I try to load that configuration later, it fails. Actually, it does not add anything to the list, though the file is on the floppy and in perfect (at least to my eyes) order. Or let me rephrase my question. What is the way to save a 7.1 configuration on a floppy so that it may be loaded later? -Kastus
On Tue, May 08, 2001 at 02:21:17PM +0200, Lenz Grimmer wrote:
2) The RPM update for apache conflicts with the update for mod_ssl; the update for apache also conflicts with various Perl apache modules. Easily gotten around with --nodeps, but annoying nonetheless.
Hmm, does it conflict, or are dependencies missing? These are two different things.
Sorry, yes, the dependencies are wrong.
4) The DM option in /etc/sendmail.cf is set to YAST_ASK, which is really annoying, because YaST never asked. So when sendmail didn't work I had to go track this down.
I assume, SuSEconfig is using a default value in this case, but I have no real clue here.
Clearly it is. One of my pet peeves is the use of default values that will have to be changed 100% of the time, with no automatic notification or warning of the values set. In the case of sendmail.cf, you might as well leave the DM option blank. It often isn't needed at all.
6) If you want ypbind, and try to configure it using YaST1, it won't let you specify that you want to find an NIS server by broadcast instead of by IP. This has been a problem since at least SuSE 6.4.
Our YP maintainer (and original author of NIS for Linux) is against doing this - I assume he has a valid reason for it.
Unfortunately, I don't make the decisions in my company's IT department, so this just means that I (and others like me) can't reliably use YP.
8) Right after my installation, I downloaded and installed the updates that SuSE had posted on the website. I later discovered the YaST2 online update. It's a great tool (and free, unlike RH up2date!), but it doesn't recognize when I've manually updated a package. So I had to let the program re-download and re-install all the patches that I'd already installed. Waste of bandwidth, really.
Well, there is not much we can do here :)
Why not? The online update tool should be checking for new package version > old package version, not >=. It doesn't seem like it'd be that hard to do.
9) When I configured my static IP (no special routing or anything) I found that the default route wasn't ever added. So I had to go into the "expert" configuration and add it myself.
How are we supposed to find your default route, if you do not provide it? Black magic? Or are you rather saying, the user interface is not optimal here?
I'm saying the UI isn't optimal. If you don't want to guess a user's gateway based on IP and netmask, then put a box for "Gateway:" on the main screen. Don't make users have to click on "Expert" just because they have a static IP and want to get to the Internet.
So those are my nitpicks. I also want to express my happiness that the init scripts are now in /etc, and that the runlevels now match Redhat's.
No, they now match the current LSB specification draft, which happens to be similar to Red Hat and other distributions. :)
Point taken. :) (I didn't *want* to mention RH, but didn't know what else to say...) -tara
* Tara L Andrews [Tue, 8 May 2001 04:40:45 -0400]:
7) The default configuration of the 3c90x ethernet module generates the following warning message on boot: insmod: Warning: /lib/modules/2.2.18/net/3c90x.o parameter switchdelay has max < min! Not a big deal, but it looks bad.
Bug in the source code of that module. There where a few more in various modules. I fixed them all. They were all results of either sloppy coding or sloppy maintenance.
to install generic RPMs without having to move around rcN symlinks.
Well, beware of one caveat. If you examine one of the scripts in /etc/init.d, you'll see that they now have LSB conforming headers which allows /sbin/insserv to automatically create and delete appropriate symlinks in the runlevel directories (see 'man insserv' for more details). No generic RPM I've encountered so far has init scripts that conform to this but instead install the script and the symlinks. The next time insserv is called (all our packages that add init scripts do so in the post install script), those symlinks will get zero as priority (e.g. S0xxxxx) and thus will be started or stopped at the wrong time. As distributions get closer to the LSB spec (including ours), points like this will (hopefully) vanish. -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
Ok, given that I have just now learned about insserv and the way that SuSE
sets the runlevel for stuff.
Now if I install stuff manually (from source, for example) that installs an
initscript (the latest NetSaint in this instance) and I add the appropriate
header information and run insserv, will that set the symlinks right?
If my logic is correct, that should work. Am I right?
THanks,
Geordon
----- Original Message -----
From: "Philipp Thomas"
to install generic RPMs without having to move around rcN symlinks.
Well, beware of one caveat. If you examine one of the scripts in /etc/init.d, you'll see that they now have LSB conforming headers which allows /sbin/insserv to automatically create and delete appropriate symlinks in the runlevel directories (see 'man insserv' for more details). No generic RPM I've encountered so far has init scripts that conform to this but instead install the script and the symlinks. The next time insserv is called (all our packages that add init scripts do so in the post install script), those symlinks will get zero as priority (e.g. S0xxxxx) and thus will be started or stopped at the wrong time. As distributions get closer to the LSB spec (including ours), points like this will (hopefully) vanish.
On Tue, May 08, 2001 at 08:49:30PM -0500, Geordon VanTassle wrote:
Now if I install stuff manually (from source, for example) that installs an initscript (the latest NetSaint in this instance) and I add the appropriate header information and run insserv, will that set the symlinks right?
If my logic is correct, that should work. Am I right?
Yes -- Togan Muftuoglu
* Geordon VanTassle (gvantass@thecoventree.com) [20010509 03:49]:
Now if I install stuff manually (from source, for example) that installs an initscript (the latest NetSaint in this instance) and I add the appropriate header information and run insserv, will that set the symlinks right?
If my logic is correct, that should work. Am I right?
Yes, you're right. If you add the header and then call insserv, everything
should be ok.
Philipp
--
Philipp Thomas
Philipp Thomas wrote:
If you examine one of the scripts in /etc/init.d, you'll see that they now have LSB conforming headers which allows /sbin/insserv to automatically create and delete appropriate symlinks in the runlevel directories (see 'man insserv' for more details).
No generic RPM I've encountered so far has init scripts that conform to this but instead install the script and the symlinks. The next time insserv is called (all our packages that add init scripts do so in the post install script), those symlinks will get zero as priority (e.g. S0xxxxx) and thus will be started or stopped at the wrong time.
As distributions get closer to the LSB spec (including ours), points like this will (hopefully) vanish.
Are those LSB conforming headers generated automatically or by hand? If they're generated automatically, what tool do you use to generate them? Paul
On Wed, 9 May 2001, Paul Abrahams wrote:
Are those LSB conforming headers generated automatically or by hand? If they're generated automatically, what tool do you use to generate them?
They have to be added manually, since you have to define, which services have to be started before this script and which runlevels it should be started at all. "insserv" parses these comments and arranges the symlinks accordingly. See the insserv(8) man page and the LSB spec: http://www.linuxbase.org/spec/gLSB/gLSB/sysinit.html LenZ -- ------------------------------------------------------------------ Lenz Grimmer SuSE GmbH mailto:grimmer@suse.de Schanzaeckerstr. 10 http://www.suse.de/~grimmer/ 90443 Nuernberg, Germany Sex is like an industrial film covered in fur..
participants (7)
-
Geordon VanTassle -
Konstantin (Kastus) Shchuka -
Lenz Grimmer -
Paul Abrahams -
Philipp Thomas -
Tara L Andrews -
Togan Muftuoglu