Author Topic: Unix system administration  (Read 1741 times)

zahc

  • friend
  • Senior Member
  • ***
  • Posts: 5,803
Unix system administration
« on: December 04, 2013, 08:10:48 PM »
I'm familiar with being a user on Linux systems. My dreamhost server has me as a user, and at my old job I was a user on a Suse webserver for years. In both cases I had my own websites and that's no problem.

At my new job, my "I need a server" request was fulfilled by spawning a virgin Red Hat VM and handing it over. This is terrifying. I'm able to log in, but there isn't even a home directory for me, and I can't create one because I don't have permission. So I changed my password, logged out, and decided I need to read a book on server administration or something. Anyone recommend me a short but good one? Is there a classic? I'm mostly concerned with how to create user and group policies that make sense, along with taking care of the security stuff. It's all insulated from the wild wild Internets, but that's no excuse.

I think I need to su, create a root user and password, then create a home directory for my normal user.
Maybe a rare occurence, but then you only have to get murdered once to ruin your whole day.
--Tallpine

lee n. field

  • friend
  • Senior Member
  • ***
  • Posts: 13,611
  • tinpot megalomaniac, Paulbot, hardware goon
Re: Unix system administration
« Reply #1 on: December 04, 2013, 09:01:55 PM »
]Essential System Administration: Tools and Techniques for Linux and Unix Administration

I see a paperback copy for .85.

Read Hat shouldn't be that hard. 
In thy presence is fulness of joy.
At thy right hand pleasures for evermore.

lee n. field

  • friend
  • Senior Member
  • ***
  • Posts: 13,611
  • tinpot megalomaniac, Paulbot, hardware goon
Re: Unix system administration
« Reply #2 on: December 05, 2013, 08:38:50 AM »
Quote
my "I need a server" request

 A server to do what, BTW?
In thy presence is fulness of joy.
At thy right hand pleasures for evermore.

zahc

  • friend
  • Senior Member
  • ***
  • Posts: 5,803
Re: Unix system administration
« Reply #3 on: December 05, 2013, 12:56:47 PM »
Mostly to query databases and create simple html reports. Quickly, to meet the niche business need of the day. Also provides a platform for little cgi programs to make life easier.
Maybe a rare occurence, but then you only have to get murdered once to ruin your whole day.
--Tallpine

RevDisk

  • friend
  • Senior Member
  • ***
  • Posts: 12,633
    • RevDisk.net
Re: Unix system administration
« Reply #4 on: December 05, 2013, 01:42:38 PM »

Ok, so you want Red Hat Linux admin info, not UNIX admin info, yes? Two very different beasts. Like AR15 vs AK47

cd - change directory
pwd - your current path
ls -list the directory's contents
yum - installs or removes packages. Use this whenever possible, don't compile binaries unless it's not in a repository
service - Starts, stops or restarts a service.
chkconfig - Use this command to start services at bootup
chmod - Change permissions
chown - change owner
useradd - Add user accounts
passwd - Change passwords

To get a LAMP server up and running, log in as root. Follow this sequence. Type anything starting with #, anything inside of ( ) do not type.
# yum update
# yum nano mysql mysql-server httpd php php-mysql
# nano /etc/httpd/conf/httpd.conf
(Change Servername is you have a domain name for the server, otherwise set it as the IP address.)
# ./mysql_secure_installation (or just mysql_secure_installation, I forget which)
# service httpd start
# service mysqld start
# chkconfig mysqld on
# chkconfig httpd on
# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
# /sbin/service iptables save

You now have a working HTTP server. Web files are in /var/www/html



"Rev, your picture is in my King James Bible, where Paul talks about "inventors of evil."  Yes, I know you'll take that as a compliment."  - Fistful, possibly highest compliment I've ever received.

zahc

  • friend
  • Senior Member
  • ***
  • Posts: 5,803
Re: Unix system administration
« Reply #5 on: December 05, 2013, 06:00:19 PM »
The webserver bit is important, because it was not set up at all. Why is the document root at /var/www and not /srv/www? I thought that was what /srv is there for. I think it's easy to change by editing httpd.conf.

Once I have my webserver, I'm not sure how to set up the file groups/permissions in the document root. I think I should create a group "web", add my normal user to "web", and have the files in /whatever/www be owned by root but with the group "web" and setgid the www directory, and generally give html files 765 permissions. Sound reasonable? It's this policy stuff that gets me.

How do I turn off telnet, block all ssh connections but my own workstation, otherwise disable things that might be turned on by default, and otherwise not do stupid things security-wise?
Maybe a rare occurence, but then you only have to get murdered once to ruin your whole day.
--Tallpine

GigaBuist

  • friends
  • Senior Member
  • ***
  • Posts: 4,345
    • http://www.justinbuist.org/blog/
Re: Unix system administration
« Reply #6 on: December 05, 2013, 09:03:53 PM »
Once I have my webserver, I'm not sure how to set up the file groups/permissions in the document root. I think I should create a group "web", add my normal user to "web", and have the files in /whatever/www be owned by root but with the group "web" and setgid the www directory, and generally give html files 765 permissions. Sound reasonable? It's this policy stuff that gets me.

Not familiar with RedHat (been a Debian/Ubuntu guy for a decade) but over on the Debian side the group isn't 'web' it's 'www'. Regardless of the name there's probably one already there.  Groups are stored in /etc/group. 

File permissions aren't hard over in *nix.  As long as you understand octets and binary math.  Unix is very user friendly, just picky about its friends.

Every file and directory has four octets (which are like bytes) that define security permissions.  They also have an owner and group.

Now, I just said they've got four octets (0755, 4755, 1600 are examples) but we'll ignore the first octet because those are special and rarely used.  So we'll just talk about 600, 660 755 type permissions.

The first octet (or byte) denotes the permissions of the OWNER of the file.  And you gotta do a little binary math when computing these.

0 bit (value 1) - file can be executed.
1 bit (value 2) - file can be written to.
3 bit (value 4) - file can be read from.

Add them together and that's the permission level.

So 6 (4+2) is reading and writing.  7 (4+2+1) is read, write, execute.  1 is just execute (never seen that used).

The second number is the group access and the third number is "everybody" access.

So, 664 means the owner can read/write, the group can read/write and "everybody" can read. 

775 means the owner can read/write/execute, the group can read/write/execute and "everybody" can read/execute the program/script/whatever.  This is what you'll want most of your CGI scripts at.  755 is also an acceptable permissions level.

When you ask for an "ls -l" of a file in *nix it'll show you permissions broken down much like the octets that describe it.  Basically rwxrwxrwx is the pattern.  The first "rwx" describes the owner's read/write/execute permissions, the second for the group, and the last one for "everybody".

When you deal with the fourth octet and setuid/setgid/etc permissions I found it so confusing that I actually once modified GNU fileutils to just output the damned octet value instead of rwSrwsrwt or whatever the frick it does once the upper octet gets changed. 

How do I turn off telnet, block all ssh connections but my own workstation, otherwise disable things that might be turned on by default, and otherwise not do stupid things security-wise?

Not familiar with Redhat (been a Debian/Ubuntu guy for a decade) but telnet SHOULD be off by default.  Not much need to restrict ssh access by IP.  It's sorta built by paranoid whackjobs that have a special place in my heart.  If you do want to get slightly restrictive just modify the ssh server config to only allow connection with a key file, not just relying on a password.  I can't remember the exact lines need to do this but it's an easy change.  I've got an Amazon EC2 VM that runs this way.  Not my choice, just how they set it up by default I ran with it.

zahc

  • friend
  • Senior Member
  • ***
  • Posts: 5,803
Re: Unix system administration
« Reply #7 on: December 05, 2013, 09:11:55 PM »
I know how to do what I want. I just don't know what I want.

I found this article which is pretty much answers my question about permissions

http://drupal.stackexchange.com/questions/52695/what-are-the-most-appropriate-users-and-permission-levels-for-drupal-sites-on-sh

Quote
Before I go on to discuss specific settings, it may be helpful to list the conditions we want to satisfy:

For a web-site to be operational, the web server must have read access to all the files that make up the site, and access directory access to all the directories that make up the site.
For secure operation, web server must not have write access to any of the files it handles.
For secure operation, a web script run by a rogue user must not have read access to the files owned by another user.
For the owner to work on his own site using the CLI, the user must have read and write access to his own files.
To protect the files from being accessed by other users using the CLI, the "other" block should have no permissions set.
Unfortunately, on a shared host, you can only have 4 out of 5. I know of no way you can satisfy all five conditions on a shared host
Maybe a rare occurence, but then you only have to get murdered once to ruin your whole day.
--Tallpine

RevDisk

  • friend
  • Senior Member
  • ***
  • Posts: 12,633
    • RevDisk.net
Re: Unix system administration
« Reply #8 on: December 05, 2013, 09:40:33 PM »
The webserver bit is important, because it was not set up at all. Why is the document root at /var/www and not /srv/www? I thought that was what /srv is there for. I think it's easy to change by editing httpd.conf.

Once I have my webserver, I'm not sure how to set up the file groups/permissions in the document root. I think I should create a group "web", add my normal user to "web", and have the files in /whatever/www be owned by root but with the group "web" and setgid the www directory, and generally give html files 765 permissions. Sound reasonable? It's this policy stuff that gets me.

How do I turn off telnet, block all ssh connections but my own workstation, otherwise disable things that might be turned on by default, and otherwise not do stupid things security-wise?

Ah... Wow.

You can change the document root path. It's a bad idea, but it's your server. Akin to saving your documents and music in the system32 folder in your Windows install. You want to use apache:apache, but you can use whatever permissions ya like.

Telnet is off unless you enabled it. Blocking all ssh connections except for the static IP of your workstation is a bad idea, but possible. Google iptables for examples.

The script I gave you is a secure install. Just remember to run yum update every so often.
"Rev, your picture is in my King James Bible, where Paul talks about "inventors of evil."  Yes, I know you'll take that as a compliment."  - Fistful, possibly highest compliment I've ever received.

lee n. field

  • friend
  • Senior Member
  • ***
  • Posts: 13,611
  • tinpot megalomaniac, Paulbot, hardware goon
Re: Unix system administration
« Reply #9 on: December 05, 2013, 10:11:28 PM »
Quote
Now, I just said they've got four octets (0755, 4755, 1600 are examples) but we'll ignore the first octet because those are special and rarely used.  So we'll just talk about 600, 660 755 type permissions.

The first octet (or byte) denotes the permissions of the OWNER of the file.  And you gotta do a little binary math when computing these.

0 bit (value 1) - file can be executed.
1 bit (value 2) - file can be written to.
3 bit (value 4) - file can be read from.

Add them together and that's the permission level.

So 6 (4+2) is reading and writing.  7 (4+2+1) is read, write, execute.  1 is just execute (never seen that used).

It's actually easier for me to work with the numbers than the other way ( "chmod +x somefile").
In thy presence is fulness of joy.
At thy right hand pleasures for evermore.

GigaBuist

  • friends
  • Senior Member
  • ***
  • Posts: 4,345
    • http://www.justinbuist.org/blog/
Re: Unix system administration
« Reply #10 on: December 06, 2013, 09:16:27 PM »
It's actually easier for me to work with the numbers than the other way ( "chmod +x somefile").

Same here.  As I noted before I once hacked up a GNU fileutils package that had a -O option to output the permissions in octal format.

Not sure why I never submitted that to be an actual patch.  I think it'd be useful and it didn't conflict with anything else.

But that was like 13 years ago.  Maybe it's been done and accepted by somebody else.  If not perhaps I should dust off my C and do it, see if the idea sticks.

lee n. field

  • friend
  • Senior Member
  • ***
  • Posts: 13,611
  • tinpot megalomaniac, Paulbot, hardware goon
Re: Unix system administration
« Reply #11 on: December 07, 2013, 09:53:05 AM »
I'm familiar with being a user on Linux systems. My dreamhost server has me as a user, and at my old job I was a user on a Suse webserver for years. In both cases I had my own websites and that's no problem.

At my new job, my "I need a server" request was fulfilled by spawning a virgin Red Hat VM and handing it over. This is terrifying. I'm able to log in, but there isn't even a home directory for me, and I can't create one because I don't have permission. So I changed my password, logged out, and decided I need to read a book on server administration or something. Anyone recommend me a short but good one? Is there a classic? I'm mostly concerned with how to create user and group policies that make sense, along with taking care of the security stuff. It's all insulated from the wild wild Internets, but that's no excuse.

I think I need to su, create a root user and password, then create a home directory for my normal user.

BTW, webmin might be useful for you.  http://webmin.com/.  Web based front end for a lot of admin tasks.
In thy presence is fulness of joy.
At thy right hand pleasures for evermore.