Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I had another question. Is su ing to root the same as logging in as root? Because I cannot login as root from the telnet prompt though I can su to root once I am logged in as myself.
Yes and no. You keep the same shell and .profile, or really .bash_profile as the original login. User and Group IDs become root's. This may be a problem of not having /usr/local/sbin in the user's path, which it almost certainly would not be by default.
Also, SecureShell allows (usually) for remote root login. Or, somewhere in init.d or xinit.d you can allow for remote root login in telnet... although if this machines is viewable at all to the outside world, that's a bad idea.
You were right, the path did not include /usr/local/sbin. But I still get the same errors with the install. It appears somehow that the root access is not recognized and hence the permission denied warning. Any other ideas?
Well, if you can't ssh in, and you can't change the root acceptance of the telnet daemon, you can try: "su -" The - will force the shell to take the environment variables of the user being switched to. It doesn't work on my Slack box. I don't know why... but I can ssh in as root, and I've never had this kind of problem with installing things remotely via an su'ed telnet session; so I've never had to fix it. On some systems /usr/local doesn't exist until you create it. Possibly you just need to make the dir.
Also, if the package is small enough, you could always poke through the 'install' part of the makefile and just move all of the binaries by hand, but this could cause some other problems if you don't figure out exactly what the install part of the Makefile wants to do.
Sorry if I'm no help. Just curious, but what's keeping you from the terminal offhand?
The machines are in a building which I dont have access to. I can just access them remotely for the time being.
I got some help from my friend. Due to the mount permissions on the /usr/local/sbin directory, I was unable to write on it inspite of being the root. So I had to install in a different directory and everything installed.
I feel like a total ignoramus about Linux right now. Thanks for all your help.
Ohhh.... I never thought of checking the write permissions to /usr/local/sbin. I just assumed it would be writeable. Sorry man, had I known that I wouldn't have led you on a little rat race there.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.