| Author |
Message |
|
|
Post subject: ceni and persistent rules
 Posted: Oct 08, 2008 - 01:39 AM
|
|
Joined: Dec 02, 2006
Posts: 1687
Location: Germany / NRW
Status: Offline
|
|
It would be very helpfull, if ceni could change/delete/recreate the udev persitant network rules.
If you have a persistant rule for eth0 and there is a change of networkcard(s), ceni cannot configure eth0, because eth0 seems to be "occupied".
If this can't be done, please add a help message which tells people where to change those rules. But if there would be a way for re-scanning for network interfaces, this would be really really time saving. |
|
|
| |
|
|
|
 |
|
|
|
Post subject: RE: ceni and persistent rules
Posted: Oct 08, 2008 - 10:17 AM
|
|
Joined: Dec 19, 2006
Posts: 1029
Status: Offline
|
|
| I do not totally understand the problem you want Ceni to fix here. And I don't like the idea of Ceni writing to another file than /etc/network/interfaces, that is not it's job. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: ceni and persistent rules
Posted: Oct 08, 2008 - 10:50 AM
|
|
Joined: Dec 02, 2006
Posts: 1687
Location: Germany / NRW
Status: Offline
|
|
I expected this reaction. And I do understand, that a developper wants to keep clean his program. But from a users point of view it is different. If ceni offers eth1 only (due to hw changes), even the average user suspects that there has to be done some reset/rescan ... but he feels lost without any hint how to do this or where to look.
I think, that ceni is _the_ network configuration tool and therefore should be eager to cover _all_ related problems. So if it can't offer a feature, it would be very helpfull to offer info. |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: ceni and persistent rules
Posted: Oct 08, 2008 - 10:55 AM
|
|
Joined: Dec 19, 2006
Posts: 1029
Status: Offline
|
|
|
michaa wrote:
So if it can't offer a feature, it would be very helpfull to offer info.
I asked you first, I didn't understand fully your first post. Please make a more detailed description about what you want.
Also, I am travelling, only have laptop and not really able to simulate this scenario very well with my limited hardware (a single laptop) so I need detailed information, steps to reproduce and show example of the problem (including the showing of change to persistent rules and suggestions about how to handle it). |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: ceni and persistent rules
Posted: Oct 08, 2008 - 11:48 AM
|
|
Joined: Dec 02, 2006
Posts: 1687
Location: Germany / NRW
Status: Offline
|
|
|
kelmo wrote:
michaa wrote:
So if it can't offer a feature, it would be very helpfull to offer info.
I asked you first, I didn't understand fully your first post.
Ok. The last days I had some hw changes. I had two network cards, now I removed one. As then my network didn't work, I tried to reconfigure the network card. But ceni showed the remaining card as eth1, not eth0 and whatever I tried, I couldn't connect to my lan. I suspected I had to change eth1 to eth0 but how?
I read about this problem before, but could not recall the exact solution. I could not connect to the net (for obvious reasons) and was really lost.
I needed to boot with a live cd, and then I searched the forum (zillions of eth0 threads) and found the solution (one needs to edit the udev persistent netcard rules). But if I hadn't read this before I never would have found the solution.
On the other hand, when I saw that there was no eth0, it was quite obvious that there had to be done some basic config editing.
In the forum there are quite some cases where people a seeking help because ceni failed to deal with hw changes (due to persistent rules). As this problem affects the connectivity I would preferre if the user would not need to post in or search the forum.
For me this problem is solved, but I am sure other users who encounter this problem the first time would be glad to find some specific hint.
I hope I now explaind it well enough. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: ceni and persistent rules
Posted: Oct 08, 2008 - 12:01 PM
|
|
Joined: Dec 19, 2006
Posts: 1029
Status: Offline
|
|
So what is your suggestion for an action that Ceni should take when Linux/udev fails to gracefully handle your hardware change?
Yes, I am sceptical about editing udev rules, that is not a possibility for Ceni imo. I do think you have a problem that could do with some work to help avoid, but i also think Ceni is the wrong place to be fixing the problem. I also do not see how Ceni can know a hardware change has been made and causes problem.
The latest version of ceni, 2.0, it offers a list of interfaces that are not related to hardware -> logical interfaces. If the scenario you describe occurs, i would expect the old eth0 configuration stanza would be listed in this box, and thus could be managed properly. |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Re: RE: ceni and persistent rules
Posted: Oct 08, 2008 - 02:00 PM
|
|
Joined: Dec 02, 2006
Posts: 1687
Location: Germany / NRW
Status: Offline
|
|
|
kelmo wrote:
So what is your suggestion for an action that Ceni should take when Linux/udev fails to gracefully handle your hardware change?
I don't know the possibilities, but
- would it be possible to trigger a rescan for hw-detection limited to network interfaces?
- what happens when the udev rule in question gets deleted?
- a very simple solution could have been to give a hint where to look in case the alias or name isn't correct, something like:
"If the device name isn't what you expect it to be look at /etc/udev/rules.d/persistent-network for obsolete entries".
It seems to me, that the new list ceni 2.0 offers is very helpfull in this regard (I only just installed it ). If problems with obsolet entries can be managed with ceni, then this would be what I suggested. If not, then the above message with the path should be shown.
As said above, for me this problem is solved, all I wanted to do with this post is to give a feedback from a users point of view, because I think for skilled developpers it is not obvious where the average user needs or expects help.
Thanks for your attention. |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Re: RE: ceni and persistent rules
Posted: Oct 08, 2008 - 02:09 PM
|
|
Joined: Dec 19, 2006
Posts: 1029
Status: Offline
|
|
|
michaa wrote:
kelmo wrote:
So what is your suggestion for an action that Ceni should take when Linux/udev fails to gracefully handle your hardware change?
I don't know the possibilities, but
- would it be possible to trigger a rescan for hw-detection limited to network interfaces?
Every time the first form of Ceni is presented to the user, a new hardware detection routine is run to create the list.
It is not possible to tell if you changed your in-built hardware, imho. For example, how would you know if the person simply unplugged a removable network interface last time?
michaa wrote:
- what happens when the udev rule in question gets deleted?
It gets regenerated on next boot, but any configuration you make before next boot could then be rendered useless, or even more problematic, as it is not guaranteed that the interfaces will have the same names.
michaa wrote:
- a very simple solution could have been to give a hint where to look in case the alias or name isn't correct, something like:
"If the device name isn't what you expect it to be look at /etc/udev/rules.d/persistent-network for obsolete entries".
I believe it would confuse a new user. Linux/udev should do a better job of not causing such problems, and a user should rarely need to know about their inner workings.
michaa wrote:
It seems to me, that the new list ceni 2.0 offers is very helpfull in this regard (I only just installed it ). If problems with obsolet entries can be managed with ceni, then this would be what I suggested. If not, then the above message with the path should be shown.
As said above, for me this problem is solved, all I wanted to do with this post is to give a feedback from a users point of view, because I think for skilled developpers it is not obvious where the average user needs or expects help.
Thanks for your attention.
No worries.
Suggestion about the way ceni presents these lists is appreciated. But be aware there are design restrictions to consider, and the more complexity added to the program, the more work it takes to keep it working well. |
|
|
| |
|
|
|
|
|
|
|
