System-config-network-tui Not Part Of Base Install… Wtf

Home » CentOS » System-config-network-tui Not Part Of Base Install… Wtf
CentOS 37 Comments

Who was the genius that decided that system-config-network-tui should NOT be part of the base CentOS 6.3 install ??

Not to mention it has insane deps like wifi firmware packages… not really if all you want to do is configure eth0 from the command line…

FC

37 thoughts on - System-config-network-tui Not Part Of Base Install… Wtf

  • /sbin/ifconfig eth0 w.x.y.z netmask v.v.v.0
    /sbin/route add default gw a.b.c.d echo nameserver e.f.g.h > /etc/resolv.conf echo nameserver i.j.k.l >> /etc/resolv.conf

  • Yes I know BUT for that I have to THINK. Screens and input fields ie type tab tab tab enter type tab tab tab enter are what is known as
    “user friendly” since the MS-DOS 5.0 setup.exe onwards…

    ;)

    FC
    PS: I had forgotten about echo >> … good enough for saving me from the vi madness. (I know, I know, esc i blah blah esc :w but still, I
    REFUSE -it’s a matter of principle not to use vi ;-)


    During times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario
    – George Orwell

  • After having built a number of machines, I kind of rattle off that by heart, just enough to then do a:

    yum install system-config-network-tui after a minimal install.

    But, yes, you’re right, it was a minor annoyance.

  • Why create GUI installers then?. Let’s just package a tarball and let users unpack it manually.

    In fact, are you advocating for the removal of system-config-network-tui ? how about removal of all non-modal text editors like joe ? let’s force everyone to “think” in ‘vi’…

    *sarcasm*
    FC

  • Unfortunately, according to folks who have more knowledge than I do about these things, in later versions of Fedora, and therefore, probably the next version or so of RH, just manually editing sysconfig/network-scripts will overlook some necessary parts. system-config-network-tui may wind up becoming necessary. Through RH
    5.x it was enough to manually edit the necessary files.

    However, in later versions of Fedora, this may cause errors because there will be some other scripts or files elsewhere, that system-config-network-tui manipulates. Meanwhile, Fedora is trying to make NetworkManager the default interface handler, (and there is apparently a command line version.)

    I know I’m old and cranky, but to me, it just seems like those meddlesome kids with their newfangled smartphones and touch screens are taking over development, and that many of them just don’t care about the sysadmin portion of use.

  • Good news!.

    My point is simple: I install the base config. I’m in text mode. I
    need networking to work to install extra packages and begin setting up my system, users, permissions, packages, etc. I have no problem doing that manually AFTER I get the system up and running (and by “running”
    I mean ‘having network connectivity’). Having me edit config files manually is an *annoyance*.

    ONCE I get networking up and running. I have no problem editing config files, because by then, with networking enabled, I’d have installed my favorite tools (joe editor etc).

    My point being that if the networking stack is part of the base OS
    install, so should be system-config-network-tui

    FC

  • Interestingly, even when I use system-config-network-tui (at least on CentOS 6.2) I still had to manually edit the ONBOOT network parameter in
    /etc/sysconfig for my Ethernet to be enabled at startup.

    Not sure if there is something in the menu system that would do that for me…

  • No. A “tui” is a pretty user interface. It’s not necessary for the functioning nor configuration of the operating system; it’s a “ease of use” tool. Nothing more, nothing less.

    In Other Words: it’s an optional component.

  • How can anyone deal with command lines and not love vi? Think of it as a set of commands to change text. Even what most people call insert ‘mode’ is a command that takes an optional repeat count: try
    20i – to get a dashed line. Maybe being old enough to have used keyboards without arrows or function keys helps, though…

  • Yes, let’s go back to the days of typing the boot code in hex to get the system started. It’s all optional.

  • The way it’s supposed to be done is to set up networking during install. The GUI installer has a button, that is clearly labeled, during install. You set it up to connect automatically, and be active for all users, and it starts even in text mode during boot up.

    The text installer is effectively deprecated; if you want/need to do, say, a serial console install you’re supposed to do a VNC install and run the GUI remotely over a VNC session (the serial console/text mode handler will do enough network configuration to get the GUI installer running over VNC).

    Barring that, if the ‘Desktop’ package set is installed (I last did this with 6.1, so it may be different now) with certain server packages also installed (no, I don’t have a rigorous package set to quote, that’s left as an exercise for the reader as I’m not going to do your homework for you on that one…..) the system will come up in runlevel 3, but will bring up a text mode firstboot that includes a text mode network configurator. While it would be interesting to see the exact package set that triggers this, I have not had the time nor the motivation to do that myself, just going by what happened when I installed some boxes a while back.

  • That’s a non-sequitor.

    If anything, a “tui” _is_ closer to boot strapping by hand entering hex. It’s a user interfce. A modern machine doesn’t need assistance in booting. If you do it properly it also doesn’t need assistance in network configuration. It “just works”.

    If you were going to argue that “text editors should be optional by this argument” then you’d have a really good point. Indeed I might agree with that. Counter argument: at least one text editor (“vi”?)
    is pretty much a BAU tool on every machine, so it makes sense to include it. system-config-network-tui is not a BAU tool; it doesn’t fill the same gap.

    Remember the “E” in RHEL. Es (in my place we have around 40,000 RHEL
    installs) configure networking during the build phase. Our standard install doesn’t include this unnecessary component.

  • Sorry, I grew with DR-DOS and the Wordstar hotkeys. ie Ctrl-K-B
    Ctrl-K-K (mark text block). It’s engraved in my brain cells.

    That’s why I use Joe… or “pico” back in the days of Caldera OpenLinux 2.3…

    FC

  • OK I’m a SOHO with a single server trying to setup a VM. What you’re saying is that RHEL/CentOS should not care about my needs because there’s a Good Reason(TM) for the way things currently are.

    FC

  • Basically, small environments will/should have DHCP service so you don’t do individual interface configuration at all (or you configure the DHCP server to give a known IP to your MAC address if you need that) and larger ones will need something that can be automated. So even though I agree with you strongly that there should be a simple text mode fill-in-the-form way to set up an interface that hides the magic OS-specific script hints, I understand why nobody considers it important. So my practical advice is to get a SOHO router that does DHCP if you don’t already have one, and if you do have one, configure it to give out the IP you want instead of fighting with the CentOS
    setup.

  • The installer switched to base mode/text install due to ‘low memory’. I just used the default recommendation by Virtualbox for Linux-RedHat.

    FC

  • Fernando Cassia wrote:

    Gag. I loathed Wordstar. The first word processor I ever voluntarily used, and still prefer to Dirt, er, Word, was WordPerfect 5. That was
    *useable*.*


    vi. emacs is a great (I suppose) windowing operating system masquerading as a text editor.

    Wonder if I could configure the *best* text editor ever to run under wine:
    brief.

    mark

    * My old criteria for evaluating a word processor: since the primary function of a word processor is to replace a typewriter, if I couldn’t sit down and write and print out a letter inside of 5 min, then its interface and bells & whistles have overwhelmed its primary function.

    Btw, in ->’95< -, in a review of word processors, PC Mag noted that 90% of the users, *then*, never used more than 10% of the capabilities, and of the remaining 10%, they used some of them no more than 10% of the time. But we need 100M+ word processors….

  • Of course, in the grand scheme of things, it’s not a “problem”. A
    “problem” is a crashing kernel or buggy drivers.

    My opinion after this experience is that it’d help for CentOS to include system-config-network-tui as part of the base install. That is my honest opinion about this experience. It’d have saved me from some minor annoyance, albeit an annoyance nonetheless.

    Just think the opposite: what would be the expense-damage of including it as part of the base install?. Would it:

    1. Break the OS
    2. Make things easier for people who end up in the same situation I did.
    3. Affect the balance of the Universe. ;)

    Your choice. I think 2.

    FC

  • I agree in principle. But my personal experience led me to have static routing on my home LAN.

    If I enable DHCP I end up not knowing what IP address a ‘new device’
    just plugged into the network has, at any given time.

    DHCP gives “initial” convenience, for “long term hassle”. (say you want to telnet-in to your ethernet enabled media player)

    FC

  • Umm, no. It takes me longer than that to find the mac address on the interface in question.

    My machines usually have 6 interfaces or so, are set up in one location, then moved to the production location with the final configuration (including IP’s) done by operators that are better at windows than linux. Sorry if that doesn’t match your view of the way the world should work.

  • All things considered, I think Reinhald’s reaction is somewhat understandable… ie preservation of the status quo “there’s nothing wrong with the system, it’s fine as it is, the problem is the user”.

    “Resistance to change” I think some call it… ;)

    Anyway, I’ll file a Request for Enhancement for RHEL if that’s possible…

    FC

  • Every DHCP server should have a way to configure a fixed IP address to be given out to a specified ethernet MAC address. My advice was to learn and use that way.

    No, DHCP will do what you tell it to do. The choice is whether you want to learn the quirks of configuring every device/OS that you might use on your network or the quirks of the one DHCP server.

  • If I did it all ‘hands-on’ I might even agree. But this is something you need to be able to tell someone else how to do over the phone because until at least one interface comes up with correct routing in your remote location, you aren’t going to be able to SSH in to do the rest.

  • Like my tivo?
    host tivo {
    hardware ethernet 00:11:d9:0b:c3:a4;
    fixed-address 10.0.0.144;
    }

    Or other appliance devices?
    host wii {
    hardware ethernet 00:1f:32:73:c6:a7;
    fixed-address 10.0.0.153;
    }

    host printer {
    hardware ethernet 00:1b:a9:22:21:89;
    fixed-address 10.0.0.10;
    }

    Personally I have my own config file:
    MACHINE 10.0.0.10 ; 00:1b:a9:22:21:89 ; printer ; Brother MFC-9120CN
    MACHINE 10.0.0.144 ;!00:11:d9:0b:c3:a4 ; tivo ; TiVo
    MACHINE 10.0.0.153 ;!00:1f:32:73:c6:a7 ; wii ;

    begins with !) and IPv6 rDNS values.

    % ping tivo
    PING tivo (10.0.0.144) 56(84) bytes of data.
    64 bytes from tivo (10.0.0.144): icmp_seq=1 ttld time=2.08 ms
    64 bytes from tivo (10.0.0.144): icmp_seq=2 ttld time=0.505 ms
    ^C

    % ping6 printer
    PING printer(printer) 56 data bytes
    64 bytes from printer: icmp_seq=1 ttld time=1.09 ms
    64 bytes from printer: icmp_seq=2 ttld time=0.370 ms
    ^C

    I use a CentOS machine as my dhcp server. The same can be done on most SOHO routers via the admin GUI.

  • The question becomes “Does upstream include it in their upstream EL?” If the answer is yes, it will be included. If the answer is no, it will not be included, as a rule of thumb.

    Yes. It would break the bug-for-bug, feature-for-feature, compatibility with upstream EL, which is one of the goals of CentOS.

  • A few people on Fedora forums. My own, very un-scientific evidence is that once or twice, manually editing has given errors that I don’t believe were due to typos. After getting bitten once, now I just quickly set up the network, download network-tui and fix it.

    Sorry if I was not clear on this. My point is that Fedora is trying to make it the default and pushing people to use it rather than the more traditional tools. At present, yes, it can still be disabled without any special effort.

  • And you chose not to setup networking at install time ? Had you done that, you would not be in this situation.

    A bare minimal install is targeted at people who know what they are doing and will make decisions with that level of situational comprehension backing them up.

    If you really dont know what you are doing : install a more complete system and the tools will be available.

  • Can you be a bit more specific about what you mean by a ‘base install’ ?
    Its not actually possible to get a minimalist @base only install without kickstarting the installer instance – at which point you might as well
    + whatever you need.

    Or perhaps you using the ‘base’ work more as a language thing to imply a minimalistic environ ?

  • erm, have you looked at the anaconda setup group selections ? None of them default to an @base only install.

    Are you saying here that even when you select a Desktop or Workstation install profile you end up with a minimalist install ? I find that pretty hard to believe.

  • yes and no. We have some liberty to change / adapt the install class’s based on what comes down stream ( remember, we normalise the distro core to remove variant specific / pricing specific options from upstream ).

    The install classes and groups are things that we build, locally, in CentOS – in an attempt to match what is pushed downstream. If there are issues, its certainly worth testing to see if its a CentOS induced issue or not.

  • That sounds reasonable enough (and I wondered about that for the first question).

    What about the second issue? Would CentOS change RPM dependencies from upstream (if it were possible)? That seems a lot less likely to me.

    –keith

  • We would not change the dependencies of an RPM, we might change the install groups in the comps file.

    The reason it is not included in CentOS now is because it is not included upstream.

    For us to change it, there would need to be a compelling reason.

  • I did’nt mean to imply rpm level changes – as Johnny already clarified, we dont do that. Every package is built and delivered with the intent of looking as close to upstream as possible.

    So to clarify what I did mean : upstream has different variants, and we need to normalise those. Sometimes its tricky. Eg: a ‘minimal’ install option for their RHEL-6-Server looks a bit different from RHEL-6-Workstation or RHEL-6-ComputeNode. When we deliver a CentOS-6, we also have a minimal install option that tries to get the best match for the user. If there was something totally whacked out, we might then need to rename and add another group. eg. assume that RHEL-6-Workstation has a LibreOffice component included, which might be considered reasonable on a workstation, we would not want that to cascade into the CentOS-6
    minimal install. A potential compromise there would be a regular
    ‘minimal install’ option for CentOS-6, as well as a ‘Mimimal-Workstation install’ option.

    Hope that clears it up.

    Regards,

LEAVE A COMMENT