Hi People, Recently an issue where I was trying to changed the group and permission associated with the device /dev/net/tun. As I knew devices were controlled by udev I went looking at its configuration and found this rule 50-udev.rules:KERNEL=="tun", NAME="net/%k". Some research on the web suggested that modifying the default rules was a bad idea and that you should in fact override them with your own custom rules. So I tried setting up a custom rule, this failed. I then tried modifying the default rule this also failed. A helpful response from here pointed me to MAKEDEV and I was able to change /etc/makedev.d/01linux-2.6.x to do what I wanted. But this has raised a couple of questions for me. 1. If udev doesn't directly control the creation of this device why is there a udev rule for it? 2. Is modifying /etc/makedev.d/01linux-2.6.x likely to cause me issues in future ? My investigation to date has led to me to believe that devices listed in /etc/udev/makedev.d/ are the devices that you always want to be present on a system rather than relying on something about your systems Hardware configuration to lead to a device being created. Is this correct ? Thank you for any thoughts / information you can share relating to this.
Filipe Brandenburger
2008-Oct-28 13:54 UTC
[CentOS] The relationship between udev and MAKEDEV
Hi, On Tue, Oct 28, 2008 at 00:21, Clint Dilks <clintd at scms.waikato.ac.nz> wrote:> 2. Is modifying /etc/makedev.d/01linux-2.6.x likely to cause me issues in > future ?Possibly, since this file is owned by the MAKEDEV rpm. If there is an upgrade in MAKEDEV, it may overwrite this file. Or if it doesn't, but there was an addition of a new device there, you would not get the new device. I would say it would be safer to create a separate file instead of modifying those.>From man MAKEDEV:CONFIGURATION CONFLICTS: In the event that the set of configuration files contains multiple rules for a given device name, MAKEDEV will use all of them. The end result is typically that the last rule given (either by virtue of being listed below all other matching rules in the same file, or by being listed in a file which is read after all others which contain alternate rules) will apply. MAKEDEV reads the set of configuration files in sorted order, so this misfeature can be exploited dependably. So I believe if you restore the 01linux-2.6.x file to its original state and create a 99local file with your customized rule, it should work. Try to do that in a test environment and let us know how that goes. I cannot answer your other questions about why it's created with MAKEDEV and not by udev itself, unfortunately I don't know enough of udev or of /dev/net/tun to be able to tell why it's done like this. HTH, Filipe