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.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.