Re: [DNG] netman: support for wlan1, wlan2, ... and eth1, eth2, .... and new systemd's naming scheme
> If you're already getting a list of devices to display, couldn't you just > verify that the chosen device matches one of those names? I don't know > what it's like to test for illegal characters in the language you're > using, but I can tell you it's a pain in the ass in bash. Yes, it is a good idea. List the available devices using ip link, extract a list of available network interfaces, and verify that the devices loaded from netman.default.devices is a valid device. Edward On 07/10/2015, fsmithred wrote: > One connection at a time should be enough for anyone. (Or they can edit > their interfaces file.) > > If you're already getting a list of devices to display, couldn't you just > verify that the chosen device matches one of those names? I don't know > what it's like to test for illegal characters in the language you're > using, but I can tell you it's a pain in the ass in bash. > > -fsr > > > On 10/06/2015 03:28 PM, Edward Bartolo wrote: >> Hi, >> >> Now, the frontend can create a text file to declare a default wifi and >> ethernet devices. Since this file is writable by ordinary unprivileged >> users, and because the file will be used by the backend to decide >> which devices to use in cases where such a file exists, I am thinking >> about validating the device names before using popen or execl. The >> validation will check for illegal characters like shell delimiters >> which can be inserted by malicious users to run malicious commands. My >> impression is that device names will be composed of letters from the >> English alphabet and digits with all other characters unallowed. >> >> With the backend directly accessing the text file, additional >> parameters to define the network interface to use will be avoided for >> both Connect and Disconnect. This means, the backend command set will >> remain unaltered. >> >> Edward >> >> >> On 06/10/2015, Edward Bartolo wrote: Is it possible to run more than one instance of netman? >>> >>> No, only the previous versions allow more than one instance of netman >>> to run. The current one I am working on (not yet pushed to git) >>> prevents users from running more than one instance. >>> >>> Edward >>> >>> On 06/10/2015, Clarke Sideroad wrote: On 10/06/2015 09:24 AM, Edward Bartolo wrote: > In the case of more than one wifi and/or more than one ethernet > connector, netman will either use decide by itself to use a device > from the available list or choose a device from the defaults set by > the user. > > I think, netman should not support more than one active connection as > is currently the case. > > Please give feedback so that I start to work on the backend. > > There are cases when multiple connections and networks do come in handy, but I think in those cases we are dealing with things that might be better off started separately going back to the basics. AFAIK Wicd only handles one connection at a time. Is it possible to run more than one instance of netman? Thanks, Clarke > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Alternative for ARM processors
On Mon, 5 Oct 2015 20:11:38 -0500 hal wrote: > I recently upgraded one my ARM devices and it appears to have > incorporated systemd into the updates. Anyone know of a systemD-less > ARM distro? ___ Dng > mailing list Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I think Void Linux has a no-systemd version for ARM. SteveT Steve Litt October 2015 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman: support for wlan1, wlan2, ... and eth1, eth2, .... and new systemd's naming scheme
One connection at a time should be enough for anyone. (Or they can edit their interfaces file.) If you're already getting a list of devices to display, couldn't you just verify that the chosen device matches one of those names? I don't know what it's like to test for illegal characters in the language you're using, but I can tell you it's a pain in the ass in bash. -fsr On 10/06/2015 03:28 PM, Edward Bartolo wrote: > Hi, > > Now, the frontend can create a text file to declare a default wifi and > ethernet devices. Since this file is writable by ordinary unprivileged > users, and because the file will be used by the backend to decide > which devices to use in cases where such a file exists, I am thinking > about validating the device names before using popen or execl. The > validation will check for illegal characters like shell delimiters > which can be inserted by malicious users to run malicious commands. My > impression is that device names will be composed of letters from the > English alphabet and digits with all other characters unallowed. > > With the backend directly accessing the text file, additional > parameters to define the network interface to use will be avoided for > both Connect and Disconnect. This means, the backend command set will > remain unaltered. > > Edward > > > On 06/10/2015, Edward Bartolo wrote: >>> Is it possible to run more than one instance of netman? >> >> No, only the previous versions allow more than one instance of netman >> to run. The current one I am working on (not yet pushed to git) >> prevents users from running more than one instance. >> >> Edward >> >> On 06/10/2015, Clarke Sideroad wrote: >>> On 10/06/2015 09:24 AM, Edward Bartolo wrote: In the case of more than one wifi and/or more than one ethernet connector, netman will either use decide by itself to use a device from the available list or choose a device from the defaults set by the user. I think, netman should not support more than one active connection as is currently the case. Please give feedback so that I start to work on the backend. >>> There are cases when multiple connections and networks do come in handy, >>> but I think in those cases we are dealing with things that might be >>> better off started separately going back to the basics. AFAIK Wicd only >>> handles one connection at a time. >>> >>> Is it possible to run more than one instance of netman? >>> >>> Thanks, >>> >>> Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman: support for wlan1, wlan2, ... and eth1, , eth2, .... and new systemd's naming scheme
Hi David, It's not necessary to add build-essential to the build-deps list. Add the APT repository to your sources.list and download the sources of netman: # apt-get source netman Now go to the parent directory of the sources, uninstall build-essential and run: # dpkg-checkbuilddeps You will get the following message: # dpkg-checkbuilddeps dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native Aitor. On 10/06/2015 07:33 PM, David Hare wrote: I built from latest git with dpkg-buildpackage, using the debian.tar.xz available with the netman deb package. BTW the build-deps list don't include build-essential, which was necessary although everything else was straightforward. I was a bit disturbed that they were around 900MB to install. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Alternative for ARM processors
On Tue, 06 Oct 2015 15:59:48 -0500 vmlinux wrote: > Both systems run Debian arm and I am afraid to ever apply upgrades to > them again. :( If there weren't any major changes to the repository in the last few weeks, you can easily install Devuan on a Raspberry Pi (-> armhf), using the method I described a while ago in this mail: https://lists.dyne.org/lurker/message/20150805.163347.dcffacec.en.html The latest devuan-baseconf package works perfectly fine, I don't know what went wrong on my first attempt. Probably I hit the wrong version... Since Raspian went Jessie some days ago, you'll have to make sure that you have "release=wheezy" in your installer‑config.txt on the SD card. Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Alternative for ARM processors
Hopefully you have more time than I to build an ARM distro. Hardest part for me was getting tool chain compiled but that was many years ago. Maybe it is easier now. I have a B+ and A+. B+ runs a USB temperature monitor for beer fridge to control the thermostat. A+ is nice if you can get by with WiFi network. I run cups server on the A+ to make laser printer a wifi network printer. Both systems run Debian arm and I am afraid to ever apply upgrades to them again. :( On October 6, 2015 1:13:53 PM CDT, aitor_czr wrote: ::I have in my mind to build a ARM distro, but i still haven't any ::machine ::with that processor. :: ::I'm interested in buying a Raspberry Pi with free hardware. :: ::Aitor. :: ::On 06/10/15 19:33, hal wrote: ::> Maybe Alpine Linux? ::> ::> http://alpinelinux.org/downloads/ ::> ::> On Mon, Oct 5, 2015 at 10:11 PM, hal wrote: ::> ::>> >I recently upgraded one my ARM devices and it appears to have ::incorporated ::>> >systemd into the updates. Anyone know of a systemD-less ARM ::distro? ::>> >___ :: :: :: :: :: ::___ ::Dng mailing list ::Dng@lists.dyne.org ::https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Sent from a Mobile device.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman: support for wlan1, wlan2, ... and eth1, eth2, .... and new systemd's naming scheme
Hi, Now, the frontend can create a text file to declare a default wifi and ethernet devices. Since this file is writable by ordinary unprivileged users, and because the file will be used by the backend to decide which devices to use in cases where such a file exists, I am thinking about validating the device names before using popen or execl. The validation will check for illegal characters like shell delimiters which can be inserted by malicious users to run malicious commands. My impression is that device names will be composed of letters from the English alphabet and digits with all other characters unallowed. With the backend directly accessing the text file, additional parameters to define the network interface to use will be avoided for both Connect and Disconnect. This means, the backend command set will remain unaltered. Edward On 06/10/2015, Edward Bartolo wrote: >>Is it possible to run more than one instance of netman? > > No, only the previous versions allow more than one instance of netman > to run. The current one I am working on (not yet pushed to git) > prevents users from running more than one instance. > > Edward > > On 06/10/2015, Clarke Sideroad wrote: >> On 10/06/2015 09:24 AM, Edward Bartolo wrote: >>> In the case of more than one wifi and/or more than one ethernet >>> connector, netman will either use decide by itself to use a device >>> from the available list or choose a device from the defaults set by >>> the user. >>> >>> I think, netman should not support more than one active connection as >>> is currently the case. >>> >>> Please give feedback so that I start to work on the backend. >>> >>> >> There are cases when multiple connections and networks do come in handy, >> but I think in those cases we are dealing with things that might be >> better off started separately going back to the basics. AFAIK Wicd only >> handles one connection at a time. >> >> Is it possible to run more than one instance of netman? >> >> Thanks, >> >> Clarke >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Alternative for ARM processors
I have in my mind to build a ARM distro, but i still haven't any machine with that processor. I'm interested in buying a Raspberry Pi with free hardware. Aitor. On 06/10/15 19:33, hal wrote: Maybe Alpine Linux? http://alpinelinux.org/downloads/ On Mon, Oct 5, 2015 at 10:11 PM, hal wrote: >I recently upgraded one my ARM devices and it appears to have incorporated >systemd into the updates. Anyone know of a systemD-less ARM distro? >___ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman: support for wlan1, wlan2, ... and eth1, eth2, .... and new systemd's naming scheme
>Is it possible to run more than one instance of netman? No, only the previous versions allow more than one instance of netman to run. The current one I am working on (not yet pushed to git) prevents users from running more than one instance. Edward On 06/10/2015, Clarke Sideroad wrote: > On 10/06/2015 09:24 AM, Edward Bartolo wrote: >> In the case of more than one wifi and/or more than one ethernet >> connector, netman will either use decide by itself to use a device >> from the available list or choose a device from the defaults set by >> the user. >> >> I think, netman should not support more than one active connection as >> is currently the case. >> >> Please give feedback so that I start to work on the backend. >> >> > There are cases when multiple connections and networks do come in handy, > but I think in those cases we are dealing with things that might be > better off started separately going back to the basics. AFAIK Wicd only > handles one connection at a time. > > Is it possible to run more than one instance of netman? > > Thanks, > > Clarke > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Didier Kryn writes: > Le 05/10/2015 18:54, Rainer Weikusat a écrit : [...] >> A file >> >> /etc/udev/rules.d/75-persistent-net-generator.rules >> >> can be created (on Debian up to wheezy at least) to avoid this "install >> the system to new hardware and get a whole bunch of new ethN instead of >> the onese which aren't available anymore" mess altogether. > This logic was implemented in older versions of Debian by the mean > of the file you say, but this file is not installed on my Debian > Wheezy; therefore I am afraid they have implemented the same logic in > some hidden place. By default, this file doesn't exist. But the udev package contains a /lib/udev/rules.d/75-persistent-net-generator.rules which is responsible for "writing net rules" and creating the /etc file of the same (base-)name overrides that. [...] >> It's not that simple as MAC addresses are neither necessarily persistent >> nor necessarily unique. Eg, by default, so-called "virtual ethernet pair >> interface" (used to connect containers to physical interfaces via bridge >> interfaces) use random MAC addresses. It's also often/ usually possible >> to change the MAC address of an interface. That's just something the >> people who came up with the previous less-than-bright idea didn't think/ >> know about at the time they did come up with it (according to the 'code >> comment' documenting the new scheme). >> > Yes, changing the MAC address of a real network interface can be > done to fool a DHCP server (I don't see any other reason), but this is > done in user space, after the kernel has registered it. "Once upon a time in the past", I deal with a SoC running Linux (2.4) where the interface MAC addresses had to be programmed into the hardware based on date read from the flash ROM ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] live-build experiment worked!
Hej, I just wanted to mention that I got an experimental Devuan jessie live-build to work with LXDE and lightdm and iceweasel. And amprolla seems to have lost the Contents-amd64.gz file so I had to make one. The only systemd components are udev and libudev1 (215-17+deb8u2) There's an annoying PolicyKit1 error at the beginning but otherwise it works. Thanks everyone who made this possible! I had to modify the live-build scripts quite a bit, which I'd like to upload. I haven't tested if they still work for Debian jessie. Another tip: after lb config, edit config/apt/preferences to add: Package: libpam-systemd Pin: release o=Debian Pin-Priority: -1 It was a bit tricky to convince lightdm it didn't need systemd. If you'd like, you can e-mail me suggestions for what to include until 1 DVD (4 Gb) is full, for a generic Devuan workstation. Version 0 has: - lxde-core - lxterminal - iceweasel - vim - xorg - locales - util-linux-locales - lightdm I'm probably going to put on it: - build-essential - linux-source and dkms - dpkg-dev - git - ssh - lvm2 - mdadm - parted - gnu-fdisk - openssl - lynx - debianutils - debootstrap - xpdf - gnuplot (hey I like gnuplot) - libreoffice-writer - mondo and mindi, although they're in non-free due to the license of afio can you give me more suggestions? greetings, Frits ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman: support for wlan1, wlan2, ... and eth1, eth2, .... and new systemd's naming scheme
On 10/06/2015 09:24 AM, Edward Bartolo wrote: In the case of more than one wifi and/or more than one ethernet connector, netman will either use decide by itself to use a device from the available list or choose a device from the defaults set by the user. I think, netman should not support more than one active connection as is currently the case. Please give feedback so that I start to work on the backend. There are cases when multiple connections and networks do come in handy, but I think in those cases we are dealing with things that might be better off started separately going back to the basics. AFAIK Wicd only handles one connection at a time. Is it possible to run more than one instance of netman? Thanks, Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman: support for wlan1, wlan2, ... and eth1, eth2, .... and new systemd's naming scheme
Hi All, In the case of more than one wifi and/or more than one ethernet connector, netman will either use decide by itself to use a device from the available list or choose a device from the defaults set by the user. I think, netman should not support more than one active connection as is currently the case. Please give feedback so that I start to work on the backend. Edward On 05/10/2015, Edward Bartolo wrote: > Hi, > > I removed the icon and used text instead. > > It is important to note that normal users who have only one wifi card > and one ethernet connector do not absolutely need to use that option, > as it doesn't make sense to talk about default devices where there is > no choice other than the one device provided. Such an option will > certainly be only used by users having uncommon systems, implying they > should be able to handle the situation. Providing automatic filling of > device names complicates the GUI unnecessarily. Please keep in mind, > the more automation we include, the heavier the processing burden, > which is something we want to avoid. In fact, I removed some code > which updated the active device name every five seconds. If a user > wants to know which network device is UP, he/she can always click the > Connected/Disconnected button. > > In case where there are multiple devices of the same kind, users can > also opt to manually edit a text file under > ~/.config/netman/netman.default.devices. The syntax is: > wlanX=wldevice > ethX=ethdevice > > Edward > > On 05/10/2015, fsmithred wrote: >> I can't tell from the pictures exactly what the flow is from one window >> to >> another, but if it works out such that you can select the interface from >> a >> list and have it auto-fill the interface name in the window that asks for >> it, then you'll have one-up on wicd, which makes you type the interface >> name. >> >> It would be bad if the user has to remember something like >> wlx78e7d1ea46da >> and type it into the next window. (Or even have to remember to >> copy/paste). If the auto-fill isn't possible, then I'd suggest having >> both >> windows open so the user can look at it while they're typing. >> >> For reference, in wicd, you can manually enter the default interface in >> the gui or in a config file. Putting it into either one will >> automatically >> add it to the other. >> >> RE: "gnome foot' icon: >> I thought the same thing, until I saw it enlarged. I think it's really a >> wolverine or maybe a wolf. >> >> -fsr >> >> >> On 10/04/2015 10:41 AM, Edward Bartolo wrote: >>> Hi All, >>> >>> These are more screenshots of the evolution of the frontend. >>> >>> http://postimg.org/image/enimq62sh >>> http://postimg.org/image/y6n7zj1k1 >>> http://postimg.org/image/4g03drgkh >>> >>> Edward >>> >>> On 04/10/2015, Edward Bartolo wrote: Hi David, The new device naming scheme will be supported. Regarding listing 'lo', I was told to filter it off the list of devices. At the moment I am concentrating on the frontend before I start to code support for enp and wl. The reason is to have a clear view of what I should code in the backend. Edward On 04/10/2015, David Hare wrote: > Some observations, testing netman. > > I have a (devuan-based) installation running eudev. The (usb) wireless > device shows as wlan0 and netman works fine. As this machine is a > fixed > tower it doesn't normally need netman gui so my autostart calls this, > and it works: > > xterm -title "Connecting to network..." -e > "/usr/lib/netman/bin/backend > 10" > > I would like to do similar before user login, maybe with an > initscript. > > WICD and its *** dbus reliance is now sacked for this machine. > > I have also live-images with eudev, unfortunately they can't use > netman > so far because: > > root@exefce:/home/user# iwconfig > lono wireless extensions. > > enp5s4no wireless extensions. > > enp2s0no wireless extensions. > > wlp0s29f7u3 IEEE 802.11bg ESSID:off/any >Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm >Retry short limit:7 RTS thr:off Fragment thr:off >Encryption key:off >Power Management:on > > Those interfaces (except "lo") do show in netman's main window. > However: > > wlan0: ERROR while getting interface flags: No such device > > ERROR: power_scan(): "/sbin/ifconfig wlan0 up" did not exit > successfully > (status=255). > > I hope this can be fixed soon. I built from latest git with > dpkg-buildpackage, using the debian.tar.xz available with the netman > deb > package. BTW the build-deps list don't include build-essential, which > was necessary although everything else was straightforward. I was a > bit > disturbed that they were around 900MB to
Re: [DNG] Alternative for ARM processors
Maybe Alpine Linux? http://alpinelinux.org/downloads/ On Mon, Oct 5, 2015 at 10:11 PM, hal wrote: > I recently upgraded one my ARM devices and it appears to have incorporated > systemd into the updates. Anyone know of a systemD-less ARM distro? > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can I do after netman?
Thanks, you are right. Aitor. On 06/10/15 00:03, Riccardo Boninsegna wrote: A little nitpick: the Description: of those packages is formally incorrect -- it should be an one-line short description followed by a multiline one (indented with one space, and with a single dot for blank lines). As it is now, there's only a long description whose first line leaks into the short's:) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Didier Kryn wrote: > Out of curiosity, why are the virtual Ethernet given random addresses? Well they have to have something ! For Xen, they've registered an OUI to get a block of MAC addresses to use. If you don't specify teh MAC address in the VM config then it'll pick one at random, but you can specify a specific address (that's what I do - derived from the IP address) and that will be used. If you specify an address then the machine will behave as though it has a fixed address - but obviously you have to manage the assignment of addresses and ensure uniqueness within your own network. "Interesting" things happen if you get this wrong and start two VMs with the same MAC address :-( I suppose the alternative would be for the virtualisation manager to keep some state - assign random addresses to new VMs, but then store those assignments to make them sticky - only changing them if something else (eg a VM hosted on another host) has taken the same one. Windows HyperV is the same. VMs change MAC addresses every time they are restarted - the difference is that my colleagues can't be bothered setting fixed ones. I know this as I have Nagios setup to monitor the network for rogue devices (or duplicated IP addresses) - and I have to update it's config every time one of the Windows VMs is restarted. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
On Tue, Oct 6, 2015 at 9:44 AM, Didier Kryn wrote: > Le 05/10/2015 18:54, Rainer Weikusat a écrit : > Yes, changing the MAC address of a real network interface can be done to fool > a DHCP server (I don't see any other reason), > but this is done in user space, after the kernel has registered it. > Out of curiosity, why are the virtual Ethernet given random addresses? > It looks like a means to increase disorder with no reason. I bet it's not > your choice. At least with the g_ether driver, you can actually use a fixed MAC through module arguments! A common fixed default wouldn't probably cut it if you need more than one g_ether device at a time, and a system-specific default has been used by Debian to add gratuitous systemd dependencies to Gummiboot ;) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Le 05/10/2015 18:54, Rainer Weikusat a écrit : Didier Kryn writes: Le 03/10/2015 09:49, Simon Hobson a écrit : Lets face it - there is no "right" answer to this other than a system with enough intelligence to read the user/admin's mind and work out what they intend to happen - and I think we're a bit off that yet ! Looking back, I think I've "moved" something at least as often as I've replaced it with a different something in the same location - probably more in fact. This is exactly the point. But let's consider which devices are a concern. As was remarked already, disks are no longer a problem since partitions are uniquely identified, so that nobody cares of a random device name. And even symlinks are created in /media, named after the labels of the partitions. All of these 'UUID' and 'partition labeling' is the exact same kind of workaround for the exact same kind of "udev design strangeness" as for the ethernet interfaces and I'm not using that anywhere except on a 'USB install disk' where the intended root partition needs to be found by the booting kernel and OS regardless of which mass storage devices may be found as part of the computer the system is booting on. Which is how these things should work: Use the more complicated solution for the more complicated case, don't just use it for the simple cases because it can also handle them. [...] Yes this is all workaround. There is a need to put order in a world which is disordered by nature. Currently we are discussing three ways to denote identical things: 1) call them after the order in which they are discovered (sda, sdb, sdc, eth0 eth1...) 2) give them a unique name (uuid, label, MAC address) 3) call them after the place where they are I think the second method is the most stable, in general. When you boot your computer from a rescue disk, your hard drive is going to be named sdb instead of sda. Your life is going to be simpler if you use labels of uuids in your fstab: you can chroot and mount -a. The pitty is there are uuids and labels for partitions but not for disks (eg in the partition table), which implies you must still call them sd[a-z] when invoking parted or cfdisk. Ethernet interfaces are maybe the only issue, which explains why distros have implemented a solution by the means of udev rules. The way it is implemented is secure: every new ethernet device is given a new device name (ethX) and no entry is created in /etc/network/interfaces; therefore the interface isn't connected without an action of the admin. If it is a replacement, then the admin should just edit the MAC address in /etc/udev/rules.d/70-persistent-net.rules. Not a big deal, compared to replacing the hardware. As I already wrote: A file /etc/udev/rules.d/75-persistent-net-generator.rules can be created (on Debian up to wheezy at least) to avoid this "install the system to new hardware and get a whole bunch of new ethN instead of the onese which aren't available anymore" mess altogether. This logic was implemented in older versions of Debian by the mean of the file you say, but this file is not installed on my Debian Wheezy; therefore I am afraid they have implemented the same logic in some hidden place. The new policy Poettering et al are enforcing means to relieve the admin from this little and rare work, at the cost of a nightmare for all the rest. It's not that simple as MAC addresses are neither necessarily persistent nor necessarily unique. Eg, by default, so-called "virtual ethernet pair interface" (used to connect containers to physical interfaces via bridge interfaces) use random MAC addresses. It's also often/ usually possible to change the MAC address of an interface. That's just something the people who came up with the previous less-than-bright idea didn't think/ know about at the time they did come up with it (according to the 'code comment' documenting the new scheme). Yes, changing the MAC address of a real network interface can be done to fool a DHCP server (I don't see any other reason), but this is done in user space, after the kernel has registered it. Out of curiosity, why are the virtual Ethernet given random addresses? It looks like a means to increase disorder with no reason. I bet it's not your choice. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
