harlow
asked on
Permission issues on new installation
I just installed Slackware 8.0 on a new system (PIII-750, 192 mb, 11 Gb, Compaq Armada M700) and have run into a variety of "can't run" issues that I suspect are related to permissions. Initially, I was unable to start the X server, except as root; it turned out that /dev/null was write protected, a little thing I never would have thought to look for except for a chance encounter with the problem in the latest O'Reilly Sysadmin book.
I fixed that. Next I found that I could not run the KDE "konsole" program except as root. That turned out to be that all of the pseudo-tty devices were write protected. This also coincidentally fixed Acrobat Reader, which would also not run except as root!
OK, so I am making progress. Now I am trying to get kppp to make a connection to my ISP. Miraculously, it understands my linmodem, and dials out just fine. kppp runs my login script just fine, and starts pppd. pppd does not immediately die with the infamous "pppd died unexpectedly" message, but it does not run either. Running as root doesn't help here. I ran kppp from a shell so I could see what messages it was logging; it goes through all the dialup and authentication stuff OK and gets an IP address as it should. But when it starts pppd, it gets stuck. Here is what transpires:
bash-2.05# /opt/kde/bin/kppp
kppp: helperPid: 346
kppp: sendRequest: trying to send msg type 6
kppp: sendRequest: sent message
kppp: recvResponse(): waiting for message
kppp: recvResponse(): received message
kppp: response.status: 0
kppp: sendRequest: trying to send msg type 2
kppp: sendRequest: sent message
kppp: response.status: 0
kppp: Locking Device: 0000000345
kppp:
kppp: sendRequest: trying to send msg type 1
kppp: sendRequest: sent message
kppp: response.status: 0
kppp: QSocketNotifier started!
kppp: AcctEnabled: false
kppp: End of script
kppp: QSocketNotifier stopped!
kppp: started if timeout timer with 30000
kppp: sendRequest: trying to send msg type 9
kppp: sendRequest: sent message
kppp: recvResponse(): waiting for message
kppp: recvResponse(): received message
kppp: response.status: 1
kppp: execppp() returned with return-code 1
kppp: Interface is down
Kernel supports ppp alright.
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
<ad nauseam till timeout>
What I see is that it is negotiating the authentication OK, but then something called QsocketNotifier seems to get a bad response, and things go downhill from there. I am over my head here; any experts out there that can tell me what trivial setting is not right this time?
As a companion question, I am really curious about the issue of all those standard /dev files being write protected by default. Is this normal? Is there a security issue involved here? Should I not write-enable them, and if so, how am I expected to run as a normal user?
Thanks
JEH
I fixed that. Next I found that I could not run the KDE "konsole" program except as root. That turned out to be that all of the pseudo-tty devices were write protected. This also coincidentally fixed Acrobat Reader, which would also not run except as root!
OK, so I am making progress. Now I am trying to get kppp to make a connection to my ISP. Miraculously, it understands my linmodem, and dials out just fine. kppp runs my login script just fine, and starts pppd. pppd does not immediately die with the infamous "pppd died unexpectedly" message, but it does not run either. Running as root doesn't help here. I ran kppp from a shell so I could see what messages it was logging; it goes through all the dialup and authentication stuff OK and gets an IP address as it should. But when it starts pppd, it gets stuck. Here is what transpires:
bash-2.05# /opt/kde/bin/kppp
kppp: helperPid: 346
kppp: sendRequest: trying to send msg type 6
kppp: sendRequest: sent message
kppp: recvResponse(): waiting for message
kppp: recvResponse(): received message
kppp: response.status: 0
kppp: sendRequest: trying to send msg type 2
kppp: sendRequest: sent message
kppp: response.status: 0
kppp: Locking Device: 0000000345
kppp:
kppp: sendRequest: trying to send msg type 1
kppp: sendRequest: sent message
kppp: response.status: 0
kppp: QSocketNotifier started!
kppp: AcctEnabled: false
kppp: End of script
kppp: QSocketNotifier stopped!
kppp: started if timeout timer with 30000
kppp: sendRequest: trying to send msg type 9
kppp: sendRequest: sent message
kppp: recvResponse(): waiting for message
kppp: recvResponse(): received message
kppp: response.status: 1
kppp: execppp() returned with return-code 1
kppp: Interface is down
Kernel supports ppp alright.
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
kppp: Interface is down
<ad nauseam till timeout>
What I see is that it is negotiating the authentication OK, but then something called QsocketNotifier seems to get a bad response, and things go downhill from there. I am over my head here; any experts out there that can tell me what trivial setting is not right this time?
As a companion question, I am really curious about the issue of all those standard /dev files being write protected by default. Is this normal? Is there a security issue involved here? Should I not write-enable them, and if so, how am I expected to run as a normal user?
Thanks
JEH
Interesting your thought about /dev write protections
I can't tell you how it is with Slackware but as far as it goes for the latest REDHAT implementations I'd say they really went over the top with security issues.
I had trouble myself trying to get an IP connection going
as 'normal' user. Indeed, ONE key solution for me it was to get write access to my modem interface. Bluntly I did a
chmod a+rwx /dev/ttyS1
& in /etc/group I added my account name to group uucp
uucp:x:14:uucp,myname
& then it worked.
The only difference to your setup is that my connection works over the classic pppd,chat line with manual /etc/ppp/options & chat file configuration, which requires a 'chmod' to all files participating in the setup. Works nicely though ! (Had nightmares with rp3 & kppp myself)
Your pppd return code 1: An immediately fatal error of some kind occured, such as an essential system call failing, or running out of virtual memory. (quoting the pppd manual)
Ok, your log says that ppp is in the kernel, but maybe something else is
missing. If you've installed the latest version of ppp (2.4.1) then you'll have to create a device /dev/ppp if it doesn't exist already.
I can't tell you how it is with Slackware but as far as it goes for the latest REDHAT implementations I'd say they really went over the top with security issues.
I had trouble myself trying to get an IP connection going
as 'normal' user. Indeed, ONE key solution for me it was to get write access to my modem interface. Bluntly I did a
chmod a+rwx /dev/ttyS1
& in /etc/group I added my account name to group uucp
uucp:x:14:uucp,myname
& then it worked.
The only difference to your setup is that my connection works over the classic pppd,chat line with manual /etc/ppp/options & chat file configuration, which requires a 'chmod' to all files participating in the setup. Works nicely though ! (Had nightmares with rp3 & kppp myself)
Your pppd return code 1: An immediately fatal error of some kind occured, such as an essential system call failing, or running out of virtual memory. (quoting the pppd manual)
Ok, your log says that ppp is in the kernel, but maybe something else is
missing. If you've installed the latest version of ppp (2.4.1) then you'll have to create a device /dev/ppp if it doesn't exist already.
xberry is probaly right, there is maybe an essential software component which is missing. If you are running a 2.4 kernel, you should have the following modules loaded or compiled in your running kernel :
ppp_generic
ppp_async
slhc
hope this can help,
Bye.
ppp_generic
ppp_async
slhc
hope this can help,
Bye.
ASKER
Hmmm. I am using kernel version 2.2.19. The ppp-related modules that are loaded are ppp and ppp_deflate, as well as slip and slhc for good measure, I guess. Earlier, I had done what xberry suggests, adding myself to group uucp and dialout, and setting a+rwx on ttyS14 (the device for my linmodem). pppd itself is a+rw. I am wondering what component pppd is missing. l ldd'ed it and no libs are missing. Any idea what piece it might be looking for? There is that cryptic notation about
AcctEnabled: false
that has me puzzled too....
AcctEnabled: false
that has me puzzled too....
mmm... I'm an all-life slackware user, but for some reasons I haven't installed Slackware 8...
The 'classic' setup of dialout networking in slackware is the use of "ppp-setup" command... have you tried it?, it's log will be more useful for me than kppp's...
*I'm consulting about your problem with other Slack users who had succesfully installed 8.0, hope to have an answer soon...
-garisoain
The 'classic' setup of dialout networking in slackware is the use of "ppp-setup" command... have you tried it?, it's log will be more useful for me than kppp's...
*I'm consulting about your problem with other Slack users who had succesfully installed 8.0, hope to have an answer soon...
-garisoain
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I agree on all points: Slack is for the hard of core, real modems are better, and there is some sort of install issue. Bugs me though, because everything, including the Linmodem, worked fine under Slack 7.1. Not sure about the defective CD story; usually that kind of major pathology makes itself evident in less subtle ways.
Anyway, this is probably enough on this thread, so I'll give it garisoain.
Thanks
JEH
Anyway, this is probably enough on this thread, so I'll give it garisoain.
Thanks
JEH
In your kppp configuration did you try to use a simple connection script instead of a PAP authentification, it could help you solve your problem ?
Bye