yast2 disconnect with files?

English Install/Boot/Login
#1

OK.

I changed some things in ifcfg-ra0 (my usb plug-in wifi nic). These were different from what I had when I set up the nic originally using yast.

I have just run yast for that nic and the value for the essid is shown as the original one. Huh?

I changed the MTU setting, using yast, for the wlan to 4096 (max for 802.11 is 7900-odd) to see if it would improve bandwidth use. Check ifcfg-ra0 and… the mtu setting is blank and ifcfg tells me that mtu is still 1500 (the ether v2 value).

I change ifcfg-ra0 mtu value to 4096, reboot and ifcfg tells me that mtu is indeed 4096. Yast tells me mt is 4096!

I am confused here. How come some stuff can be read from ifcfg-xxx (or is it sample from ifcfg?) and some not. Why is an mtu setting made in yast not carried through to ifcfg-nic?

Yes, I am willing to get into a testing thing with the yast guys.

#2

Well…

Hmmm…

My post was made based on looking at my 11.4 system. I have just made a similar change of MTU under 12.2 and the change propogated to the ifcfg-nic file.

#3

OK. More twist. After reboot, ifconfig on the nic in question is still showing 1500 even though I changed it in yast to 4096 and ifcfg-wlan0 shows MTU=4096.

#4

On 02/15/2013 03:26 PM, antttikutoja wrote:
>
> OK. More twist. After reboot, ifconfig on the nic in question is still
> showing 1500 even though I changed it in yast to 4096 and ifcfg-wlan0
> shows MTU=4096.

The maximum MTU for wireless connections is 1500. The system is doing the right
thing even though you are not.

#5

On 02/15/2013 11:04 PM, Larry Finger wrote:
>
> The maximum MTU for wireless connections is 1500.

through trial and error while using the info in post #4 of this
thread http://tinyurl.com/ydhz3pa i learned my hardware/system
networks FASTER with an MTU of 1472 than the default 1500…

and, that thread also addresses the ‘problem’ of setting a persistent
MTU.

some “rules” to underscore here:

  • bigger numbers do not always mean better, faster, cooler, etc

  • the newest available is not always the best, especially if
    stability is important

  • random experimentation might lead to a smile, but just pushing the
    biggest number possible into any crack found with no study to learn
    the implications is (imho) far to troublesome a method pursue

  • if it ain’t broke, don’t fix it

  • use what works

  • when making random stabs at ‘fixing’, always know how to get back
    to what works

–
dd
http://tinyurl.com/DD-Caveat

#6

Really?

I just looked it up again.

|
|
|Internet IPv4 Path MTU|At least 68[4]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-4)|Practical path MTUs are generally higher. IPv4 links must be able to forward packets of size up to 68 bytes. Systems may use Path MTU Discovery[5]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-rfc1191-5) to find the actual path MTU. This should not be mistaken with the packet size every host must be able to handle, which is 576.[6]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-6)|
|Internet IPv6 Path MTU|At least 1280[7]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-7)|Practical path MTUs are generally higher. Systems must use Path MTU Discovery[8]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-8) to find the actual path MTU.|
|Ethernet v2|1500[9]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-9)|Nearly all IP over Ethernet implementations use the Ethernet V2 frame format.|
|Ethernet with LLC and SNAP, PPPoE|1492[10]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-10)||
|Ethernet Jumbo Frames|1500-9000|The limit varies by vendor. For correct interoperation, the whole Ethernet network must have the same MTU. Jumbo frames are usually only seen in special purpose networks.|
|WLAN (802.11)|7981[11]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-11)||
|Token Ring (802.5)|4464||
|FDDI|4352[5]](http://en.wikipedia.org/wiki/Maximum_transmission_unit#cite_note-rfc1191-5)||

Certainly ifconfig shows mtu on the wlan nic as being 4096.

My point is that the values being shown in yast are not reflective of the values in, say, ifcfg-wlan0. I manually set up ifcfg-wlan0 to get into the wlan at my hame. I had originally set it up to connect to my daughter’s wlan. The values for SSID and passphrase are shown in yast as the ones for my daughter’s wlan. The values in ifcfg-wlan0 are for my home wlan and it connects just fine.

MTU in yast for this nic is 7900, the value I started with when playing with different MTU sizes for wlan0, whereas in ifcfg-wlan0, it is 4096 which is the value I am currently playing with and the value shown by ifconfig.

Yast is, clearly, getting these values from somewhere other than the underlying system config files. My guess is that it only changes the values in the underlying system config files if one changes the value shown by yast.

#7

dd.

Followed your link and, yes, it was interesting and, basically, describes what I have been doing vis-a-vis my MTU settings. I also agree with and endorse the rest of your posting. When “playing” I always make copies of the working configuration files before making changes.

Whilst I do find yast useful at times, there are occasions when I want to make changes “on the fly” and see their effect asap. In these cases, I tend to directly edit the underlying configuration files rather than go through all the yast dialogues.

The NIC in question is working just fine, it is the disconnect between what yast displays and what is actually in the configuration files that are being used to configure the devices in question that is he real point of my post.

#8

On 2013-02-16 10:36, antttikutoja wrote:
> Yast is, clearly, getting these values from somewhere other than the
> underlying system config files. My guess is that it only changes the
> values in the underlying system config files if one changes the value
> shown by yast.

Yast uses its own places to store variables and values, usually
“/etc/sysconfig/*”, and does not necessarily read what the system
configs have. Yast writes them, not read them - in general.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#9

On 02/16/2013 11:56 AM, antttikutoja wrote:
> the disconnect between
> what yast displays and what is actually in the configuration files that
> are being used to configure the devices in question

i think maybe you have the feeling that if Linux Flavor Y (or a
‘generic’ Linux book) looks at /nic_config-mtu (yes i just made that
up) to decide how the kernel’s ins and outs affect the networking
stream then the flavor known as openSUSE does also…

and, that is (could be, maybe) not a swell assumption in all
cases…and sometimes leads to problems understanding what is going on.

if you use a text editor to look through the ‘guts’ of various
configuration files you might understand why some folks say:

When you have seen one Linux, you have seen one Linux.

because there is LOTS of stuff going on in this distro which
different from other distros, or books about ‘generic linux’

here, try this


sudo grep SuSE /etc/sysconfig/network/scripts/*

and, then if you change it to


sudo grep mtu /etc/sysconfig/network/scripts/*

and you will see that some of the behind the scenes magic of MTU is
done by the smoke and mirror of SuSE copyrighted stuff which you may
or may not find in Linux Flavor Y which is in detail covered by The
Linux Book…

ah…i see that Carlos covered this also, in a lot fewer
words…thank you Carlos

–
dd
openSUSE®, the “German Engineered Automobile” of operating systems!

#10

Carlos, dd.

Thanks for that. It certainly gels with what I observe.

In future, I will bear all this in mind and make sure that, in future, any manual changes I make get put into yast when I’m done. At least that should keep yast’s view of the config consistent with the real config.

Cheers - AK

#11

On 2013-02-16 15:06, antttikutoja wrote:
>
> Carlos, dd.
>
> Thanks for that. It certainly gels with what I observe.
>
> In future, I will bear all this in mind and make sure that, in future,
> any manual changes I make get put into yast when I’m done. At least that
> should keep yast’s view of the config consistent with the real config.

Typically (I’m not talking of this case) you configure something with
YaST, then turn over to configure that service directly for more
details, At this point, you should not use YaST again to configure that
service.

Normally, YaST will notice the external modification and abort. On some
other cases, YaST redoes the configuration destroying your changes.

I don’t know in your particular case what happens.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#12

Carlos. Yes, what I am seeing is reflective of the behaviours of yast. It works the way it works but I now know that, particularly if I make changes in the background, what yast tells me about my box’s configuration is not necessarily the case.

In a sysadmin tool, I would consider that a bug.

Why can’t yast show me how my system is really configured rather than what it last knew about? After all, it knows what the underlying config files are so why not use them as its repository? Probably some of its modules do but clearly some do not.

During the 5.x etc series, one edited, among other things, a file in etc called rc.conf. Basically, it defined your system and was central to the configuration. After any change to rc.conf though, one had to run the SuSEconfig script in order to propogate changes into the system as a whole.

They way yast works is the way it works and I use it extensively. I have only recently noticed the anomalies that I have posted about here. The point is that now I know it works like this, I will have to make sure that I either only ever use yast or I remember to “update” it from time to time.

This is personal but one of the reasons why I have found so many MS “admins” incapable of really sorting out problems is that all they are taught is how to operate their various gui tools. Very few seem to know exactly from where and how the box is really configured. I’d rue the day is SuSE became like that. I’ve always liked the way it introduced the gui without screwing the underlying configuration architecture.

The analogy of the car (Sig in the other poster’s post) is a good one. You don’t need to know anything about cars to drive one but the more you do know, the better driver you become.

Cheers - AK

#13

Agreed on the bold part (also for the computer analogy), but that’s where it stops for me. I’ve seen too many exceptions on that, in cars as well as in computers / software. Point IMHO is that “better driver” is discutable.

#14

On 2013-02-18 12:36, antttikutoja wrote:
>
> Carlos. Yes, what I am seeing is reflective of the behaviours of yast.
> It works the way it works but I now know that, particularly if I make
> changes in the background, what yast tells me about my box’s
> configuration is not necessarily the case.
>
> In a sysadmin tool, I would consider that a bug.
>
> Why can’t yast show me how my system is really configured rather than
> what it last knew about? After all, it knows what the underlying config
> files are so why not use them as its repository? Probably some of its
> modules do but clearly some do not.

Read on…

> During the 5.x etc series, one edited, among other things, a file in
> etc called rc.conf. Basically, it defined your system and was central to
> the configuration. After any change to rc.conf though, one had to run
> the SuSEconfig script in order to propogate changes into the system as a
> whole.

Correct. Now it is not a single file, but a bunch of files under
“/etc/sysconfig/*”. You write there, run SuSEconfig, and they are
applied to the real config files. This goes in one direction: the “real”
configuration files are not read, they are only written to.

That’s the reason of what you describe.

There is a bunch of files under “/var/adm/SuSEconfig/md5” that is used
by SuSEconfig to detect changes to the real config files. If a change is
detected, it aborts and does not touch the real file again for life.

YaST, in general, does not parse those real config files.

All that said, SuSEconfig is being deprecated, it does less and less
these days. What you see can also be a result of this. Some devs propose
that the entire “/etc/sysconfig/*” structure be removed. I do not know
how they then intend YaST to work, because parsing all the real config
files of all the modules that YaST configs is a LOT of work and will
produce bugs for years to come. It is a death sentence for YaST.

> This is personal but one of the reasons why I have found so many MS
> “admins” incapable of really sorting out problems is that all they are
> taught is how to operate their various gui tools. Very few seem to know
> exactly from where and how the box is really configured. I’d rue the day
> is SuSE became like that. I’ve always liked the way it introduced the
> gui without screwing the underlying configuration architecture.

And if they GUI fails, they only can reinstall again. I know. Have you
tried to install an Exchange server with AD? /That/ is a nightmare.
Specially for people like me used to Linux.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)