command won't stick 5

[NewtownGuy]

Hello,

I need to issue this command:

chown root:apache /dev/ttyS0

each time my Fedora Core 3 server boots. I've included it in rc.local with other startup commands, which run ok so I know the script is running, but for some unknown reason I have to reissue this command manually from root each time the machine boots.

How should I make sure this command executes each time Linux boots ? I have a second machine that is supposedly identical and runs fine, so there must be some difference between them, but I can't find it.

Thank you.

-- NewtownGuy

 

[RhythmAce]

Hmmm. That's odd. Anyway, if Mohammed won't go to the mountain you can bring the mountain to Mohammed by adding apache to the group uucp. I think the default group for ttyS0 is uucp.

 

[NewtownGuy]

TO: RhythmAce

Thank you.

Do you mean ? :

chgrp apache uucp

How do I check which group ttyS0 is in ? I looked in /etc/group and it wasn't listed.

-- NewtownGuy

 

[zeland]

You can put the chown command in /etc/rc.local so that it will run every time your server restarts.

I'm not too sure if FC3 already implemented udev. With udev, all system device are created on-the-fly when your system starts. Edit the file /etc/udev/rules.d/50-udev.rules and set the proper group & group permission to the desired device.

--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[RhythmAce]

You can use usermod with the -aG option or easier yet just open /etc/group and look for this line:

apache:x:48:

and add the new group to the end like this:

apache:x:48:uucp

I think zeland is correct in that the ttyS0 device file is being recreated on boot up. It defaults to user root and group uucp so by adding apache to the group uucp, we bypass that problem.

 

[NewtownGuy]

TO: zeland

This is baffling... Here's rc.local on my two Fedora Core 3 machines:

setserial /dev/ttyS0 divisor 12
setserial /dev/ttyS0 spd_cust
setserial /dev/ttyS0 baud_base 115200
setserial /dev/ttyS0 close_delay 50
setserial /dev/ttyS0 closing_wait 100
stty --file=/dev/ttyS0 -onlcr -ocrnl

[COLOR=blue]chown root:apache /dev/ttyS0[/color]
chmod 666 /dev/ttyS0

The chown line is present in both machines, but I have to execute it manually after each boot on one of them. This is the machine where the command isn't sticking.

TO: RhythmAce

I tried adding :uucp as you suggested, but it doesn't work.

Could there be something that's undoing the chown command in /etc/rc.local, or that's undoing the line in /etc/group ? But it's only happening on one of two presumably identical machines...

-- NewtownGuy

 

[Annihilannic]

I think RhythmAce meant:

...just open /etc/group and look for this line:

uucp:x:14:

and add the new user to the end like this:

uucp:x:14:apache

i.e. you want to add the apache user to the uucp group, not the other way around.

Annihilannic.

 

[NewtownGuy]

TO: Annihilannic

Thank you. That solved the problem.

However, I noticed that several groups named themselves, such as:

uucp:x:14:uucp

In the case of uucp, I replaced the right-most uucp by apache. What is the effect of removing uucp on the right ? Why do other entries name themselves on both the left and right ?

-- NewtownGuy

 

[zeland]

It means that user uucp (right hand) is part of group uucp (left hand).

It is a bit strange because the user uucp should already have the group uucp as their primary group. Naming themselves here meant that they belong to the group as a secondary group. What is their primary group assignment in /etc/passwd?

--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[chipperMDW]

It sounds like your device node is being created dynamically every time your machine boots up, which means you're using either devfs or udev. If you really want the device file to have apache as its group owner, the solution would be to find out which of those systems you're using and, as zeland suggested, modify the rules for creating that node.

Run:

[tt] $ ps aux |grep dev[/tt]

and look for either devfsd or udevd. If you're using devfs, read this. If you're using udev, read this instead.


I guess whether or not that's better than making apache part of the uucp group depends on what exactly you're doing.


Regarding your /etc/group file...

In the case of uucp, I replaced the right-most uucp by apache.

If uucp was already there, you may not want to replace it with apache; just add apache to the list of users in that group. If you do that, your line will read like this:

[tt] uucp:x:14:uucp,apache[/tt]

 

[NewtownGuy]

TO: zeland,

I'm not sure what the primary group assignment is, so here's the entire /etc/passwd:

[root@-001 etc]# vi passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
rpm:x:37:37::/var/lib/rpm:/sbin/nologin
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin
pcap:x:77:77::/var/arpwatch:/sbin/nologin
apache:x:48:48:Apache:/var/[URL unfurl="true"]www:/sbin/nologin[/URL]
squid:x:23:23::/var/spool/squid:/sbin/nologin
webalizer:x:67:67:Webalizer:/var/[URL unfurl="true"]www/usage:/sbin/nologin[/URL]
xfs:x:43:43:X Font Server:/etc/X11/fs:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin

Does this help ?

-- NewtownGuy

 

[NewtownGuy]

TO: chipperMDW

Here's the result of:

ps aux | grep dev

[root@-001 etc]# ps aux |grep dev
root      1106  0.0  0.1  3524  508 ?        S<s  09:12   0:00 udevd
root      2280  0.0  0.1  2440  532 ?        Ss   09:12   0:00 gpm -m /dev/input/mice -t imps2
root      8833  0.0  0.0  3416  168 pts/0    R+   11:43   0:00 grep dev

Does this mean I'm running udev ? If so, what is it ?

-- NewtownGuy

 

[chipperMDW]

Yes, that means you're running udev.

Once upon a time, /dev directories contained all the device nodes a system might ever need, even if those devices weren't present on the system. That meant you had thousands of device nodes, most of which were never going to be used.

udev is a system that solves this problem by creating only the device nodes needed on a system. At boot time, it detects all attached devices and creates appropriate nodes. When new devices are plugged into a running computer, udev notices and creates nodes for those devices. When devices are unplugged, udev notices and removes the unneeded nodes for those devices. When you shut your computer down, all those nodes, which are usually stored on a temporary filesystem in RAM, disappear.

What all this means is that, as you've noticed, you can't make changes to device nodes and expect them to stick across a reboot because udev needs to recreate them.

However, you can give udev rules telling it how the nodes should be created in the first place, and it will follow these rules each time it creates the nodes. To do what you asked in the original post, you'd want to use a rule like this:

KERNEL=="/dev/ttyS0", OWNER="root" GROUP="apache"

More information about udev and udev rules.

Again, writing a udev rule may not be a better solution than what you've already got (adding apache to the uucp group), but it is the way to accomplish what you originally asked.