Home/Support/Support Forum/File permissions on tty's created by the dgrp daemon
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

File permissions on tty's created by the dgrp daemon

0 votes
I am wondering if it is possible to have the dgrp daemons
create the file permissions on the tty's it is creating
to be '777'. I am running Red Hat AS 2.1 dgrp 1.7-1.
The ttys are being created as;

crw
1 root root 254, 2 May 28 15:06 tty002

The problem is that I have some of the serial ports connected
to devices that need to be accessed by general users. I am
reading the man page on dgrp_cfg_node and it appears that
you have the ability via the -m <mode>, -o <owner> and
-g <group>. However, the documentation is not very clear
on this. So, I used the dgrp_gui to make the assumed
changes and what happens is that it issues the command, I
go back to see if the changes 'took' and everything is back
to 'default'. I do a ls -al /det/tty002 and permissions are
still the same. Am I looking in the right direction here ?
Does anyone know how to go about this ?
asked May 28, 2004 in Realport by AnthonyD New to the Community (3 points)

Please log in or register to answer this question.

7 Answers

0 votes
These settings will only be applied when creating the devices and will not change existing devices. This is by design since, the devices are all recreated after a reboot with the original daemon settings.

Try removing the entry and re-adding with the new device permission settings.
answered May 28, 2004 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
So are you saying that linux is creating the tty's and not
the dgrp daemons ? If this is true, I guess I've misunderstood what the dgrp daemons are doing. Here are some pieces to the puzzle.

backing store config file;
#
# ID IP PortCount SpeedString IPPort Mode Owner Group Encrypt EncryptPort
0 192.168.101.60 16 auto default 777 502 502 never default


Here is the inittab for said tty's (some printers and
some terminal logins);

D0A:2345:respawn:/sbin/agetty tty000 9600 vt100 -L
D0C:2345:once:< /dev/tty002 > /dev/null &
D0D:2345:once:ditty-rp 9600 /dev/tty002
D0E:2345:respawn:/sbin/agetty tty003 9600 vt100 -L
D0F:2345:respawn:/sbin/agetty tty004 9600 vt100 -L
D0G:2345:respawn:/sbin/agetty tty005 9600 vt100 -L
D0H:2345:respawn:/sbin/agetty tty006 9600 vt100 -L
D0I:2345:respawn:/sbin/agetty tty007 9600 vt100 -L
D0J:2345:respawn:/sbin/agetty tty008 9600 vt100 -L
D0K:2345:respawn:/sbin/agetty tty009 9600 vt100 -L
D0L:2345:respawn:/sbin/agetty tty012 9600 vt100 -L
D0M:2345:once:< /dev/tty013 > /dev/null &
D0N:2345:once:ditty-rp 9600 /dev/tty013
D0O:2345:respawn:/sbin/agetty tty014 9600 vt100 -L
D0P:2345:respawn:/sbin/agetty tty015 9600 vt100 -L

This is something comming up in the /var/log/messages;

May 24 12:33:30 testuv modprobe: modprobe: Can't locate module char-major-254

It a coincidence that 254 is major for the tty's in question. Finally, this is a lising of the '/dev' files. I really dont understand why the tty010 and tty011 have the permissions they way they do.

crw
1 root root 254, 0 May 28 16:49 tty000
crw
1 root root 254, 1 May 28 16:48 tty001
crw
1 root root 254, 2 May 28 16:48 tty002
crw
1 root root 254, 3 May 28 16:49 tty003
crw
1 root root 254, 4 May 28 16:49 tty004
crw
1 root root 254, 5 May 28 16:49 tty005
crw
1 root root 254, 6 May 28 16:49 tty006
crw
1 root root 254, 7 May 28 16:49 tty007
crw
1 root root 254, 8 May 28 16:49 tty008
crw
1 root root 254, 9 May 28 16:49 tty009
crw-rw-rw- 1 root root 254, 10 May 28 16:48 tty010
crw--w---- 1 root root 254, 11 May 28 16:48 tty011
crw
1 root root 254, 12 May 28 16:49 tty012
crw
1 root root 254, 13 May 28 16:48 tty013
crw
1 root root 254, 14 May 28 16:49 tty014
crw
1 root root 254, 15 May 28 16:49 tty015

Does any of this make sense ? If so care to elaborate a little more so that I can understand it as well.
Thanks
answered May 28, 2004 by AnthonyD New to the Community (3 points)
0 votes
The dgrp daemons create the devices on every boot with the settings specified in the backing store file. For open permission settings on the devices a 4 digit value needs to be added. For example: 0777

The different permissions shown on the two ports you pointed out, appear to have had the permissions changed after the initial boot/device creation (perhaps an application?).

The /var/log/messages error indicates that the dgrp daemon is unable to communicate with the unit. This error is commonly seen when there is a getty running on a port that is not accessible.
answered Jun 1, 2004 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
So, I changed the permissions as suggested. The backing store file is now;

0 192.168.101.60 16 auto default 0777 default default never default
1 192.168.101.61 16 auto default 0777 default default never default
2 192.168.101.62 16 auto default 0777 default default never default
3 192.168.101.63 16 auto default 0777 default default never default
4 192.168.101.64 16 auto default 0777 default default never default
5 192.168.101.65 16 auto default 0777 default default never default
6 192.168.101.66 16 auto default 0777 default default never default
7 192.168.101.67 16 auto default 0777 default default never default
8 192.168.101.68 16 auto default 0777 default default never default
9 192.168.101.69 16 auto default 0777 default default never default
A 192.168.101.70 16 auto default 0777 default default never default

I changed the 192.168.101.60 to be owned by default instead of group 502 as well. I wasnt sure about this to begin with. The /dev/ttys are still comming up with the same permissions as before. There isnt an application running that is using /dev/tty010, dev/tty011. So, I dont understand how these permissions are being set they way they are.

The 'messages' entry still appears, which is;
Jun 1 11:38:05 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:05 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:05 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:05 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:05 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:05 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:05 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:15 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:15 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:16 testuv modprobe: modprobe: Can't locate module char-major-254
Jun 1 11:38:17 testuv modprobe: modprobe: Can't locate module char-major-254

It appears that it is listed one time for each tty it is trying to spawn off a login on in the /etc/inittab.

You mentioned that this is usually caused by a getty running on a port that is not accessible. Im not sure I know what to do about this ?

Does all of this appear buggy or am I doing something wrong ?
answered Jun 1, 2004 by AnthonyD New to the Community (3 points)
0 votes
Seems as though the driver is failing and not the daemon:

Jun 1 11:38:17 testuv modprobe: modprobe: Can't locate module char-major-254

This occurs when the system doesn't currently have a driver for that major loaded,so modprobe is called to try to find a driver to autoload that will claim major 254.

1) If you run "/sbin/lsmod", is dgrp listed?
2) Run /etc/init.d/dgrp stop
3) Run /sbin/rmmod dgrp (assume 1. came back with the driver loaded)
4) Run /etc/init.d/dgrp start
5) Run "/sbin/lsmod", is dgrp listed now?

If on 5) the driver is not listed, there is the real problem you need to resolve. A typescript of the driver compilation/installation may give some clues.

The "mknod/chown" stuff is not run until the driver is loaded into the kernel correctly.
answered Jun 1, 2004 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
during the lsmod, dgrp is listed;
[root@testuv init.d]# /sbin/lsmod
Module Size Used by Not tainted
dgrp 80532 133

the /etc/rc.d/init.d/dgrp_daemon stop is successful

Now the next command /sbin/rmmod dgrp will not execute, because of error;

[root@testuv init.d]# /sbin/rmmod dgrp
dgrp: Device or resource busy

I guess this is because of all the gettys still hanging around ??

When you stop the daemon from running is it supposed to stop all gettys ?

Anyway, this is as far as I got. From what I recall I did not encounter any errors during the driver install.

Any workarounds for step #3 ?
answered Jun 1, 2004 by AnthonyD New to the Community (3 points)
0 votes
At this point, I recommend contacting Digi Tech. Support.
answered Jun 1, 2004 by userid0 Veteran of the Digi Community (2,158 points)
...