>> "s" == servis <servis@purdue.edu> writes:
s> | Strange it works as root. As you can see, you don't have a
s> | /etc/ppp/options file. Create one and try again.
s> This fix doesn't seem like the right way to fix this problem. Why
s> would running it as root NOT fail when the options file is not present
s> and when run as a user it needs to have the options file present.
Don't know. This *is* strange, just as I said.
s> Well, now the error message goes away but it just exits without doing
s> anything, assuming because the options file is empty.
No. The options file may be empty.
s> A strace shows that it is trying to execute '/usr/sbin/pppd call
s> provider', which is what /usr/bin/pon does, but it fails.
s> [pid 1219] execve("/usr/sbin/pppd", ["/usr/sbin/pppd", "call", "provider"], [/* 36 vars */]) = -1 EPERM (Operation not permitted)
s> If I explicitly type in '/usr/sbin/pppd call provider' the log shows an
s> entry of
s> 'Aug 26 08:57:36 brian pppd[1221]: pppd 2.3.5 started by servis, uid 6262'
s> but no error message is returned and nothing happens.
Now I am *really* confused. In another mail you said:
% id
uid=6262(servis) gid=6262(servis)
groups=6262(servis),20(dialout),29(audio),30(dip)
% ls -l /usr/sbin/pppd
105 -rwsr-xr-- 1 root dip 105532 Jun 18 19:59 /usr/sbin/pppd*
This is OK.
If permissions are wrong, you should get a
$ /usr/sbin/pppd
su: /usr/sbin/pppd: Permission denied
(try this please)
Maybe you did the "adduser name dip" during the current session? Then
you should login again.
(and try /usr/sbin/pppd again. Different output/logs ?)
Ciao,
Martin
--
from a 1996 Microshit ad campaign:
"The less you know about computers the more you want Micro$oft!"
See! They do get some things right!