IP config files on Red Hat 9

From - E J -

Answered By: Mike Martin, Jay R. Ashworth, Jim Dennis, David Mandala, Kapil Hari Paranjape, Ben Okopnik, Thomas Adam

Please note I am trying to configure IP on a Red Hat 9 system. I would like to see about changing from the default DHCP configuration to a STATIC configuration.

I have tried a couple of things only to trash a test system, in one case I got the system up - but X no longer worked.

I know the hostname is saved in /etc/sysconfig/network.

What are the other files necessary to changing the configuration?

Thanks in Advance.

[MikeM] first of all, for any problem try to do it manually so

once logged in (as root) do

ifdown eth0 ifconfig eth0 address <your ip address> then if you access a router directly do route add gw <name of your default gateway>

If this works add to /etc/hosts a line <your hostname (machie name)> <your machines IP address>

also this may be useful

https://www.faqs.org/docs/linux_network

[jra] But don't worry about that.

Use the RedHat program netconfig, which has a button for DHCP. Turn it off, and fill in the blanks.

[Breen] That'll work, Jay. If EJ wants to know what's going on behind the curtain, the documentation is in

/usr/share/doc/initscripts-<version>/sysconfig.txt

The subject of this thread then changes.... -- Heather

[Breen] /usr/share/doc/initscripts-<version>/sysconfig.txt

[JimD] I felt stupid reading that, too. I've complained for years at the lack of documentation for those. Sometimes I just read through the rc scripts that source the /etc/sysconfig files to figure how which names they want to use. Sometimes I just run the silly GUI config tool (when I can remember which name it goes by in which versions of Red Hat). I had never found this particular file.

I still think it's a bug. Red Hat should include a set of comments in each /etc/sysconfig file that list all of the valid variable names and show examples of the valid values.

Now that the "Red Hat Distribution" is a "community maintained project" rather than a shrink wrapped product ... heck with it; I'll still recommend that advanced Linux users switch to Debian and that businesses pressure Oracle and other ISVs to support Debian.

I think the "Red Hat community project" should set a goal for itself -- to provide a transition to Debian over the next several releases. They can write rpm command wrappers around apt-get/dpkg, add or help Debian add the -V and -K (verification and GnuPG key package signing) features to the .deb package format and the /var/lib/dpkg "database"), etc.

[DavidM] Gack, I hope that never happens, I dislike Debian intensely. I use it on some of my servers and I grate my teeth every time I need to do something with it. Debian needs a lot more then just a rpm wrapper. I'll try not to start a religious war here and simply say you stick with Debian and I'll stick with Red Hat and I hope they get more compatible but I hope that happens by Debian getting closer to Red Hat and not the reverse (except apt-get, that is quite nice).

[Ben] Yeeew. I sure hope that never happens either. I really hate the "papa knows best, just watch the blinkenlights" approach of RedHat, and money is what it takes to get me to play with it these days.

Fortunately, none of this is an issue since we _do have both of these distros plus a whole lot of others, which seems to satisfy a broad range of us picky techie types (say _that 3 times fast with a mouth full of marbles, and your dental problems will be a thing of the past.)

[JimD] In other words, I think a convergence is in order. Let's have both major "community projects" try to consolidate (improving both).

[DavidM] I strongly disagree here. The beauty of Linux and the various projects is there is no "one true way" and those who like it different can have it that way. Otherwise you are just like Microsoft and Apple each having a single "true way".

[JimD] I have similar opinions on gentoo; why create a new distibution when they could have poured that energy into creating a Debian build system that could build your entire distribution from sources, with locally defined optimization and other flags). (BTW: the argument that this results in significant performance gains seems to have been somewhat refuted:

 https://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227

... though it's possible that this test was flawed.

(That said I've been thinking of installing gentoo on a machine just to see what it's like).

[JimD] I knew my statement was likely to rankle. However, without it degenerating into a religous war, what specific things do you dislike about debian? /etc/sysconfig/network-scripts/ifcfg-* versus /etc/network/interfaces? The installer? Lack of Kickstart? The dpkg commant? dpkg-reconfigure or dpkg-repack? The fact that many packages ask configuration questions during pre-install or post-install? The fact that you can't tell the package manager to exclude the docs during installation?

I want to know because I'd like to see Debian make the necessary changes or options available to make Red Hat users happier.

[DavidM] This is important in the business world where you need 50 machines exactly the same, not close but exactly the same. Also unless you make your own Debian depository the changes in the Debian tree make it all but impossible to do this if you are installing machines over the course of several months.

Another irritant is that Debian package maintainers patch the packages to run in funny places and have odd patches on them. We were running SAMBA on one machine and we were having a major problem that we could not explain. As luck would have it I was able to get tridge to take a look and even he was mystified for several hours. As it turned out the package maintainer had really messed up the package. There is not enough testing done on the edge cases by the Debian developers, so either leave the source alone or truly understand it and test all possible uses of the package which in the case of SAMBA is impossible, the SAMBA developers have spent a huge amount of time getting donated machines available to be able to test the edge cases, there is no way a Debian developer is going to have access to the same resources that the SAMBA developers have.

At tridge's advice and this is advice I've been given many times from others as well. "Use Debian as a base install but for packages you really care about make your own from source as you never quite know what they've done to them." The problem with this of course is if I can't trust what I'm installing then why am I installing it at all?

Followed by the fact that stable is most always too old thus forcing me to use testing which gets broken at times.

[DavidM] I don't think it's possible for Debian developers to make Red Hat users happier, they like to do things their way and the hell with the rest of the folks. An example, change the init levels to match Red Hats, make init 3 the normal run level sans X and level 5 with X. Virtually every other Linux distro is the same as Red Hat very very few are different. But as a business software developer I need to know that if my package it to be installed on both Red Hat and Debian I need to install my startup scripts in different run levels or bad things happen. That is silly.

I agree that one does need to minimize gratuitous differences so tackle the run level differences first, if you can get that changed (which I strongly doubt) perhaps there is a possibility that Debian can become a stronger player in the Corporate market place. What I think you will get is many reasons why Debian is correct but that is irrelevant, it's not about being technically correct it's about minimizing gratuitous differences, and I don't think it's possible for the Debian community to change.

[JimD] Well "funny places" is the main sort of gratuitous change I also object too. FHS was supposed to reduce this (and probably has, somewhat).

We could argue that Red Hat and SuSE put their stuff in "funny" places; then we could both reach for copies of the FHS to bolster our arguments.

I agree about the runlevels and the way the run xdm as an rc script rather than in inittab. Those are gratuitous and Debian should bow to the more widespread convention in both cases.

As for the Samba anecdote: so what. Red Hat applies over a 100 patches to their kernels and they apply patches to many packages, including core packages like Samba. We could exchange package maintainer horror stories for hours. Usually the Debian packaging is better than Red Hat packaging. Debian has a published policy that is derived from the consensus of it's maintainers/developers. There are ongoing discussions on how to change that policy. Maintainers that don't conform to the policy see NMUs (non-maintainer uploads) of their packages and are eventually replaced by new maintainers.

Of course it's possible for them to change. It is easier for us to change Debian than it would be for us to change Red Hat Inc.

[DavidM] Jim, here again we differ, I feel it's easier to change Red Hat all it takes is cash, nothing more nothing less. Changing Debian is akin to herding cats you have to get a large portion of the entire development community into agreement which is damned hard if not impossible to do. You need to join them in overwhelming force in order to out vote them on policy. Any single person is doomed to failure, it was designed that way and it works quite well. Debian is a hackers play land, it was designed to be that and that it will stay, the bylaws they live by are specifically designed to keep it that way and human inertia and apathy will tend to keep it that way.

How long did it take to fix the networking init script that would only start networking and not stop or reset it take? More then 3 years by my count, if you can't fix something like a simple init script how you expect to fix a fundamental difference in philosophy?

[JimD] To effectively change Red Hat Inc. we have to either buy them, or represent a large enough portion of their revenues that they'll listen. To change Debian all we have to do is join them, work on the project and explain our reasons for recommending the change.

My problem with the Red Hat "distribution" is that it's been essentially abandoned by Red Hat Inc. Now, the community will maintain it; RH Inc. will take parts that they like and fold them into their proprietary AS/ES products. However, RH will also make changes that may make AS/ES diverge somewhat from the RH distro.

My comments are mostly intended to discourage people from create yet another distro for broad consumer use.

I'm not saying everyone should just abandon the RH distro -- just try to transition some parts to the Debian base (where that makes sense) and to join Debian in sufficient numbers and quality to effect changes there.

Notice that I'm mostly a proponent of changing Debian in many of the specifics. The one thing that I would push on the other distros is the use of the same package/dependency infrastructure and granularity. I'm not talking about the commands used to manipulate the packages (apt-get, dpkg, aptitude, rpm, etc) --- I personally would prefer to see a command named 'pkg' taking arguments somewhat like the rpm command (except for that idiocy of -U being "upgrade" and install thus necessitating the odd -F --freshen switch to mean just "upgrade"). The difference would be that pkg -i foo would look at your local policy file (/etc/apt/sources.list) and know how to fetch the foo from your preferred location or media.

[DavidM] That is not the only problem, as far as I can tell, when a package changes (is updated) there is no history, the old package is removed and the new inserted replacing it. I could be wrong but the gents I used at my last place were dedicated Debian devotees and they could not find where "outdated" packages were stored. Thus if a package was "updated" you were screwed and could not make an identical from that point forward unless you went to the extreme of maintaining your own Debian depository.

[JimD] If it happens at all I expect it to take several years and releases of each of the two distributions. We've already seen lots of people implementing apt on RPM based distributions. The problem with that superficial approach is that the underlying granularity and dependency cycle problems remain. The real value of Debian in in that acyclic dependency tree.

[Kapil] Joining the distro wars once more ...

Just some random points.

1. While Kickstart is a great idea, systemimager is not a bad replacement. For the more hardcore debian-ers, Kickstart seems too complicated when compared with "dpkg --get-selections" in combination with "dpkg --set-selections".

[Kapil] 2. When comparing "rpm" with "dpkg" (or deb) what is lacking in dpkg is the automated signature/md5sum checking. On the other hand try to unpack an "rpm" on a non-RedHat machine...not all that automatic (you need to install "alien"). To unpack a "deb"...you will (most likely) find "ar" on any machine and so can unpack deb's quite easily.

[Kapil] 3. I don't dislike RedHat as intensely as David seems to dislike Debian! However, the choice was made for me by RedHat when they decided to exclude text-mode tools for installation and management. Even "dselect" is better than nothing except "rpm". I used "purp" on RedHat systems for a while but it was always in "contrib" and often out-of-date.

[Kapil] 4. Re: xdm. I think all daemons were "meant to be" started from rc scripts so in fact the RedHat policy of starting "xdm" from inittab is strange. For example, in the old days it was possible for the console user to somehow "kill" the xdm/gdm/kdm on RedHat (possibly by killing the X server or something) causing all external Xterminal users to be logged out!

[Kapil] 5. Finally, about building things from source. To some extent I agree. It would be nice if we had the following set-up:

A. All the system administrator had to do to was install a base system.

B. Most utility/application packages could be installed by users in (say) /opt/username/packagename/{bin,lib,...}.

[Kapil] C. There would be a user-level package management system that would allow users to mix and match their requirements by creating symlink farms in /home/username/{bin,lib,...} that point to different packages under /opt possibly installed by different users.

[Kapil] This way, those users who need "cutting edge" or even "bleeding edge" tools could install them. The system could remain "stable" and (hopefully) "secure". Such a setup may even be useful on single-user systems as the user could play with upgrades without messing up the running system. Disk space is not really an issue any more unless you use "KDE" or "Gnome" or "Openoffice"

Meet the Gang   1   2   3   4   5   6   7   8