Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
It means the application does NOT require root access to run which is a good thing. Running apps as root is a good way to get your system hacked. The root user is the "super" user on UNIX/Linux so it override most security mechanisms on your server.
You can either run as a regular user (e.g. your non-root user account) or better yet create an application administrative user specifically for this app. We do the latter here for most applications as we have multiple people that might need to access the application administrative setup so could not run it as any of those individuals.
For example if your app was called GreatSoftware you might use useradd to create an account:
This creates a user called "greatsw" with a home directory of /opt/greatsw. You then login as the greatsw user (or do "su - greatsw" to switch to the greatsw user from whatever you're currently logged in as) then do the software install as the greatsw user.
In our environment we typically would first make a new filesystem for a new application to avoid having it fill up other directories (e.g. /opt might not be a separate filesystem so if Great Software filled up /opt it would actually fill up the root filesystem). We also use a predetermined range of user id numbers for such application accounts so would specify "-u <UIDnumber> in the useradd. We also would often want a functional group of users in the same group as the new adminstrative account so would add "g <GIDnumber> to have it in that same group.
Last edited by MensaWater; 07-29-2011 at 01:38 PM.
you are going to have to provide a lot more information
Quote:
I am about to install some software on Red Hat Linux.
What software ?
WHAT version of RHEL ??????
Quote:
I can understand all the instructions apart from the first.
what instructions and for what ?
Quote:
Log on to the UNIX system
RHEL is NOT unix
IBM unix is unix
red hat is Linux
-- close but NOT THE SAME --
so WHAT is this "software"
Quote:
Caution: Do not install as root.
from this i am guessing that this unnamed software is some already build binary
for WHAT version of what operating system was it designed to be ran on ?
Thank you for the comprehensive reply from MensaWater. I will give it a try on Monday when I am back at the Office with a user as suggested. I am testing with VMware so I will take a snapshot before I start so I can do no real harm. What about the line in the instructions "with the privileges required to install software" though - it made me think that the user had to be in some way special.
Thank you for the reply from "John VV". I was trying to install on Red Hat Linux version 4.1 I think - I will need to check when I am back in the Office on Monday to be sure. The software I have got to install is "Connectirect" which definitely stated it was supported on the version of Red Hat Linux that I had. The only instruction which worried me (the first) was "Log on to the UNIX system with the privileges required to install software. You can create an account specifically for this purpose. Caution: Do not install as root." - the bit that really worried me was "with the privileges required to install software" - I was thinking the user had to be in some way special and I had been trying to decide in what way special.
That is a bit on the old side and 4.9 is current in the 4 series.( rhel6.1 is the current release)
So for 4.1 you must have a long term support contract from red hat so that backported security fixes can be installed on that older version of 4
That is a bit on the old side and 4.9 is current in the 4 series.( rhel6.1 is the current release)
So for 4.1 you must have a long term support contract from red hat so that backported security fixes can be installed on that older version of 4
Thank you for the comprehensive reply from MensaWater. I will give it a try on Monday when I am back at the Office with a user as suggested. I am testing with VMware so I will take a snapshot before I start so I can do no real harm. What about the line in the instructions "with the privileges required to install software" though - it made me think that the user had to be in some way special.
Thank you for the reply from "John VV". I was trying to install on Red Hat Linux version 4.1 I think - I will need to check when I am back in the Office on Monday to be sure. The software I have got to install is "Connectirect" which definitely stated it was supported on the version of Red Hat Linux that I had. The only instruction which worried me (the first) was "Log on to the UNIX system with the privileges required to install software. You can create an account specifically for this purpose. Caution: Do not install as root." - the bit that really worried me was "with the privileges required to install software" - I was thinking the user had to be in some way special and I had been trying to decide in what way special.
Perhaps that means choose a user who has group rights to /usr/local as that may be where the software will be wanting to install to.
There are, really, two ways that you can "install software" on a Linux/Unix box:
"Install a package." No thought-process required. (That is to say, "on your part." The good person who sweated bullets to build that package for you has already lost the appropriate number of hair-follicles on your behalf ... )
"Do it yourself." (As they say on a classic-country radio station in my neck of the woods, "If you have a keyboard macro for ./configure && make && make install, you're one of us...")
It's a long-standing tradition among Linux/Unix shops that "local software" is installed into the directory /usr/local, and what I would please ask you to do next is to ... "Google It™."
Last edited by sundialsvcs; 08-01-2011 at 08:42 PM.
There are, really, two ways that you can "install software" on a Linux/Unix box:
"Install a package." No thought-process required. (That is to say, "on your part." The good person who sweated bullets to build that package for you has already lost the appropriate number of hair-follicles on your behalf ... )
"Do it yourself." (As they say on a classic-country radio station in my neck of the woods, "If you have a keyboard macro for ./configure && make && make install, you're one of us...")
It's a long-standing tradition among Linux/Unix shops that "local software" is installed into the directory /usr/local, and what I would please ask you to do next is to ... "Google It™."
You seem to be assuming the user meant one of the various FOSS offerings when he said "application". My assumption was that he was talking about something more canned from a 3rd party vendor (i.e. Oracle apps or something like that). Simply "installing a package" doesn't quite match what you do for such things and DIY isn't an option usually. My assumption was based on what he was being given as instructions in the first place. Of course my assumption could be invalid.
Also /usr/local may or may not be where such applications usually reside. For example putting Oracle in /usr/local isn't prohibited but it wouldn't be expected by most Oracle users. Other things like Nagios do expect to reside there but don't have to do so.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.