Correct place to set MTU for Mandriva? - Mandriva

This is a discussion on Correct place to set MTU for Mandriva? - Mandriva ; I edited the ifcfg-ethn scripts but it disappeared at the next reboot. I could shoehorn a script in rc.local or similar but I'd just like to find out where Mandriva expects it. Cheers, Lordy...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Correct place to set MTU for Mandriva?

  1. Correct place to set MTU for Mandriva?

    I edited the ifcfg-ethn scripts but it disappeared at the next reboot.
    I could shoehorn a script in rc.local or similar but I'd just like to
    find out where Mandriva expects it.

    Cheers,
    Lordy

  2. Re: Correct place to set MTU for Mandriva?

    On 14 Jun 2007 18:53:51 GMT, lordy wrote:
    > I edited the ifcfg-ethn scripts but it disappeared at the next reboot.


    Little vague there, disappeared from (config file or setting) ?

    Maybe it depends on type of connection (static,dhcp,ppp,..),
    Mandriva release, ip4/ip6, ...

    You could look in the documentation

    $ locate sysconfig.txt | grep initscripts

    edit the returned file and search for mtu.

    Note: I have seen Mandriva Control Center remove custom
    settings/values from command files.

    > I could shoehorn a script in rc.local or similar but I'd just like to
    > find out where Mandriva expects it.


    I would create a little script in
    /etc/sysconfig/network-scripts/ifup.d/
    to dump mtu setting to see when it changed. Note: x_fn was chosen to
    have it run after other scripts in same directory.

    Example commands/script follow:


    cd /etc/sysconfig/network-scripts/ifup.d/
    touch x_debug_net
    chmod +x x_debug_net

    kwrite x_debug_net
    /bin/echo "========== $1 =============" >> /tmp/x_debug_net
    /sbin/ifconfig -a >> /tmp/x_debug_net
    #*************** end x_debug_net **************

    To test:
    service network restart

    Quick check
    grep -i mtu /tmp/x_debug_net

    If you see value change then,
    cat /tmp/x_debug_net

  3. Re: Correct place to set MTU for Mandriva?

    lordy wrote:
    > I edited the ifcfg-ethn scripts but it disappeared at the next reboot.


    RANT ON
    This sort of thing is becoming a pervasive and incredibly annoying
    problem. The current fad is to build in a mess of config writing
    scripts which are constantly rewriting critical configuration files
    underneath /etc, and by doing so are making it damned hard to figure out
    where to enter a stable configuration value, such as MTU. To
    my mind this started with msec and it's been all downhill since then.
    As I've pointed out before, these #$&#&$# config writing scripts
    invariably start the config file you can find with:

    #This is an automatically generated file do not edit

    but neglect to tell you which file you SHOULD edit to eventually
    change this one's contents. Also the source location for this
    information eventually always turns out to be:

    /etc/something_not_obvious/blather/doofus,

    which you can generally only find, if you're lucky, by running grep down
    through every file under /etc, or spending an hour prowling through man
    files.

    ENOUGH ALREADY!!!!

    Static configuration information, defined here as relatively
    simple data well represented by files consisting solely of:

    SETTING1=whatever
    SETTING2=whatever
    etc.

    belongs either in /etc itself (like the good old days), or in
    /etc/sysconfig/scriptname (if it all fits in one file) or
    /etc/sysconfig/scriptname/* (if it needs multiple files). If the
    configuration file is significantly more complex (defined as either
    a lot of values required, or some other more complex syntax required),
    then, and only then, should it be placed in:
    /etc/scriptname/some_godawful_mess_of_files.

    I'm also beginning to think this has reached the point where
    we need a "confighow" utility. Anything that requires, writes,
    or rewrites a configuration file, or configuration values,
    would provide a .confighow file which would be added to this
    knowledgebase. Then one could type something along these lines:

    % confighow network
    network is a keyword for these configurable objects:
    wired_ethernet
    wireless
    2_tin_cans_and_string
    % confighow wired_ethernet
    Matching Configurable object modifiers:
    eth0
    eth1
    % confighow wired_ethernet eth0
    Matching Configurable object modifiers:
    routing
    interface
    firewall
    % confighow wired_ethernet eth0 interface
    Configuration files:
    /etc/sysconfig/network-scripts/*
    Man pages:
    ifconfig
    ifup
    some_script_you_have_never_heard_of_that_rewrites_ the_config_files
    Command line configuration:
    script_that_sets_config_values_for_script_mentione d_above
    GUI_configuration
    drakconf
    netGUIconf #for instance, if it exists
    webmin

    And in the case at hand:

    % confighow -search MTU
    MTU is a configurable parameter of these configurable objects:
    wired_ethernet
    wireless


    The point being that there would be an official way to find all of this
    information without having to hunt all over the system, and often, all
    over the internet, for the answer. (Obviously the syntax above is just
    an example, it could be very different, just as long as it provides a
    path from "how do I do this" to "modify these files" or "run this
    configuration program".)

    RANT OFF

    Regards,

    David Mathog

  4. Re: Correct place to set MTU for Mandriva?

    On Fri, 15 Jun 2007, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , David Mathog wrote:

    >lordy wrote:
    >> I edited the ifcfg-ethn scripts but it disappeared at the next reboot.

    >
    >RANT ON
    >This sort of thing is becoming a pervasive and incredibly annoying
    >problem. The current fad is to build in a mess of config writing
    >scripts which are constantly rewriting critical configuration files
    >underneath /etc, and by doing so are making it damned hard to figure out
    >where to enter a stable configuration value, such as MTU.


    This user friendliness is some dickheads idea of what is needed to
    allow the windoze click-and-drool crowd to use Linux. They are basing
    this misguided concept that you need to make everything "just work"
    no matter how much the user screws around with stuff. When I learned
    UNIX, I was six months before I even realized who this "root" user was,
    and it was another six months before I got even elementary privileges
    beyond the normal user. With the average Linux (and *BSD) installation,
    root is the first (and in a few st00pid cases only) account the user
    gets. Most modern Linux users don't feel the need to have even the
    slightest idea of why/how something happens.

    I'm not advocating going back to the "one year experience needed before
    you get root" stage, as that simply won't work. But I really am
    advocating that the users be able to read a well written man page or
    similar documentation that comes with realistic examples that can be
    used as default configurations. The reason microsoft adopted the
    ZeroConf (LinkLocal) crap of the system grabbing a random IP address out
    of the 169.254.0.0/16 range is because their "simple" DHCP setup got so
    screwed up by MSCEs sometimes that this was the only way to "make it
    work" so that the boss doesn't cloud up and rain all over my parade.

    >To my mind this started with msec and it's been all downhill since then.


    Actually several other distributions had this dubious helper as much as
    seven or eight years ago. It was one of the "features" of linuxconf
    (that wonderful security hole creation helper introduced in 1998).

    >As I've pointed out before, these #$&#&$# config writing scripts
    >invariably start the config file you can find with:
    >
    >#This is an automatically generated file do not edit


    That garbage goes back even further - Red Hat was doing this stupidity
    back in 1996 in RH2.1, but this was based on even earlier work in some
    branded versions of UNIX.

    >but neglect to tell you which file you SHOULD edit to eventually
    >change this one's contents.


    What a terrible idea - giving the user _useful_ information. They'd
    just screw things up even more.

    >Also the source location for this information eventually always turns
    >out to be:
    >
    > /etc/something_not_obvious/blather/doofus,


    Well, /etc/ _is_ where the system configuration files are supposed to
    live. When I encounter something like this, my first reaction (if I'm
    not allowed to wipe the install and put on something sane) is to use
    grep to search for variables and filenames. Looking for the data, a
    'grep -i VARIABLE_NAME /etc/*" (and then /etc/*/*, and /etc/*/*/*
    and so on) will often turn up the secret location. As this garbage
    normally runs as root, 'strings /sbin/* | grep filename' (and also
    in /usr/sbin/*) will often turn up the so-called helper program. Then
    it's a matter of how to disable this crap tool.

    >which you can generally only find, if you're lucky, by running grep down
    >through every file under /etc, or spending an hour prowling through man
    >files.


    That assumes that the a$$hole who created the program bothered to create
    a man page - "it's so helpful it doesn't _need_ a man page". By the
    way, I also grep for keywords in the man page directories for the very
    same reason. When you've got several thousand man pages to look through
    trying to find the GHODdamn _field_ to look for the stupid haystack you
    need to search through gets old really fast.

    >ENOUGH ALREADY!!!!


    Tell us how you _really_ feel!

    >Static configuration information, defined here as relatively
    >simple data well represented by files consisting solely of:
    >
    >SETTING1=whatever
    >SETTING2=whatever


    Ah, but that assumes that you know what is looking where to find the
    variables - again, most users couldn't follow the trail from the boot
    loader configuration file, through /sbin/inittab and on to the boot
    script links in the runlevel directories. Windoze doesn't need this
    crap, so why do you expect the windoze "trained" user to understand?

    >belongs either in /etc itself (like the good old days), or in
    >/etc/sysconfig/scriptname (if it all fits in one file) or
    >/etc/sysconfig/scriptname/* (if it needs multiple files). If the
    >configuration file is significantly more complex (defined as either
    >a lot of values required, or some other more complex syntax required),
    >then, and only then, should it be placed in:
    >/etc/scriptname/some_godawful_mess_of_files.


    Oh, you mean like the terribly simple way that the various desktops
    have there files spread over fifty acres of disk space?

    >I'm also beginning to think this has reached the point where
    >we need a "confighow" utility. Anything that requires, writes,
    >or rewrites a configuration file, or configuration values,
    >would provide a .confighow file which would be added to this
    >knowledgebase. Then one could type something along these lines:
    >
    >% confighow network
    >network is a keyword for these configurable objects:
    > wired_ethernet
    > wireless
    > 2_tin_cans_and_string


    Ah, but this sh!t is handled automagically when you install or boot or
    get r00ted. The user doesn't need to know about this complex stuff.

    >The point being that there would be an official way to find all of this
    >information without having to hunt all over the system, and often, all
    >over the internet, for the answer.


    You've forgotten another end of the problem. Each of these wonky "let
    me help you" "tools" tend to be either unique to the distribution (and
    $GHOD help you if you have to support more than one distribution, never
    mind one variant of *nix), or possibly unique to the windoze desktop^W^W
    GUI environment you happen to be using.

    >(Obviously the syntax above is just an example, it could be very
    >different, just as long as it provides a path from "how do I do this"
    >to "modify these files" or "run this configuration program".)


    Nothing wrong with your concept except that it's going to be a bitch to
    implement because every fscking distribution knows better than anyone
    else how to do stuff (just look at how your kernel has been "improved"
    to incompatibility), and they see little reason to do things in a
    common (let alone coherent) manner.

    >RANT OFF


    Don't stop - file a bug report.

    Old guy

+ Reply to Thread