The OkayPlayer Technical Q&A Session - Got problems? Need a new setup? Trying to skip those college textbooks? Read this. [Q]: I'm in the right group setting and all, and the permissions on the file on FTP is rw-rw-r, but I'm getting mad problems still! What's up? [A]: Chmod any files that have the file with "chmod 664", that should fix the current files if group settings are correct. Now, to prevent this from happening again, check the /etc/inetd.conf file. Run "pico /etc/inetd.conf". Look for the following line or something similar to it: ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a Now change it so it looks like this: ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a -u 002 The -u 002 tells the ftp server to make a default umask of 002, which is the equivalent to chmod 664. [Q]: OK, the intern is being upgraded and I want him/her to be able to start ftp'ing stuff... how do I handle adding him/her to the group? [A]: Go to linuxconf by typing in "linuxconf". Following these steps: *use the tab button to navigate from button to button, it is a UI (user interface) without mouse support.* 1. On the menu, go down to "+ User Accounts" and press enter. This will drop the branch for user account configuration. 2. Go to "+ Normal" and press enter. This will drop this branch. Go down to "User Accounts" and press enter. 3. A list of current usernames will be then listed. Don't fret if you see some accounts you didn't add, a few of these are default user/application accounts such as apache, games, gpm, and so forth. 4. Choose the username you are modifying and press enter. 5. Go down to the " Supplementary Group" line and add the group name you want him/her to be part of (it is alright if there are other group names there, just follow the format). [Q]: Charles, that vhost thing you did for sendmail was great (hehe)! Now how would I go on to do that? [A]: Let me elaborate on the situation. We want the server to support more than one domain when it comes to e-mail addresses. Our provider must do all the dns work and assign us all the ip and hostname configuration. Once that is done, we can move on to how to set it up so you don't just have an e-mail on @okayplayer.com, but also on @buttnaked.com (or any other domain that is locally available on the server). 1. Go to /etc directory (cd /etc). 2. Edit the sendmail.cw file on it (pico sendmail.cw). What you need to do with it is basically add whatever new domain you have. If the domain is already in there, then just skip this. What the sendmail.cw should look like: --sendmail.cw sample-- localhost okayplayer.com your-domain-added.com --sendmail.cw end sample-- 3. Go to the mail configuration directory (cd /etc/mail). 4. Edit the virtusertable file (pico virtusertable). It is probably blank at this point unless entries were made earlier. What the virtusertable (edited) should look like: --virtusertable sample-- angie@thebrokediaries.com angie2 @thebrokediaries.com angie2 --virtusertable end sample-- The 'angie@thebrokediaries.com angie2' tells sendmail to send all mail going to angie@thebrokediaries.com to angie2, a local account on the system. The '@thebrokediaries.com angie2' tells the server to send all mail going to thebrokediaries.com domain to angie2. If you ever need to add an entry that forwarded mail somewhere outside the local server, it should look like this: angie_jr@thebrokediaries.com junior@someother-domain.com Not so bad eh? 5. Now, stay in the same directory (/etc/mail). What you now want to do is 'recompile' these entries into the sendmail db format. You may already see virtusertable.db already in there (ls -la). That is ok. We are now just reformating it. Type in: make virtusertable.db If all went well, it will proved by last editing date. You can check that out by running 'ls -la' and looking at the date/time indicated next to the file. We are just about done. 6. Restart sendmail by typing 'killall -HUP sendmail'. Now type in 'ps aux' and if you see sendmail listed, everything should be fine. And with the SIGHUP (-HUP), there is only probably milliseconds worth of disruption to the smtp service. [Q]: Everyone is going buck with the e-mails! I want some R and R from all this. Is there some sort of autoreply I can use while I'm on leave? [A]: Of course! And I'll even show you how to activate and deactivate. The process is simple. 1. First create the .forward in your home directory (pico ~/.forward). In it, you want to put a line like this: "| /usr/bin/autoreply /home/angie/autoreply-message" \angie The /home/angie/autoreply-message indicates the location of the auto message that will be sent those who e-mail you during the time autoreply is enabled. The \angie is just an identification line of the user who is using it. It should be same user that owns the directory where autoreply-message is. 2. Now we want to create the actual autoreply-message file (pico ~/autoreply-message). It should follow this format: --sample autoreply-message-- From: User Name Subject: Don't e-mail me Precendence: some babble Hi. Thanks for e-mailing, but I'd rather you not. Have a great day. Sincerely, NonExistant U. Name --sample end autoreply-message-- Hopefully, the format is pretty standard. The only that I have yet to figure out myself is the need for 'Precendence'. 3. Activation and deactivation is simple. To activate the autoreply, leave .forward just the way it is. To deactivate, change the name of .forward to something like .forward.OFF (mv .forward .forward.OFF). And to re-activate, change the name back to .forward (mv .forward.OFF .forward). [Q]: Something is wrong and I really have no idea what it is... what do I do and where do I start?! [A]: Somebody is always going to ask this one and I needed to be prepared.. so here you go. 1. You want to first start off by looking at the current running processes. Type in 'ps -aux' while still being root. If you don't see the process, it is most definitely down. Now to figure out why. 2. Ask yourself... who logged on last? Who usually uses this process? When was the last reboot? The more questions, the better. If we are talking about FTPd or any other 'public' processes, please take these into consideration. FTPd and HTTPd is available to anyone. Though they might not be able to access them via an official login, you must know that they still have 'access'. They are able to send data and etc. Sometimes because of this, if that visitor is knowledgable to the exploit and DoS world... they can do damage (BTW...a DoS is a denial of service...take that phrase literally). This can be done in many ways, depending on the bug. That is a difficult find unless you have some sort of saavy when it comes to that stuff. But search on sites relating to the service, you may find some sort of advisory on a old/new bug. If so, follow their instructions on patching (check the local version first). Take into consideration that the bug may be that of a local fault. Sometimes programs on linux experience things called segmentation faults or core dumps. This is due to bad coding or invalid input. With a situation like this, you want to look for a 'core' file to verify that this has happened. Most likely, more stable and veteran applications such as Apache and Sendmail will doubtfully ever seg fault... but if so, we must check. Go to the directory of where the application is (use the 'locate whatever_u_r_looking_for' command) and look for a core file. Use 'ls -la' and see how old that core file is. If it was created about the same time the daemon died, you have found your problem. Fixing it is the difficult part. Unless you have a programmer in the house, don't count on a quick solution. Search for a vendor patch or go to message boards with the problem...or even search google.com (good stuff). Just because a program core dumps, it does not always mean a big problem. Usually it is because of one line of code. 3. IF THE PROCESS IS STILL RUNNING.... watch for the network load. Sometimes if there is too much data for it to handle, it will pause for a moment or for a while. We can not really determine that so easily. Nevertheless, you can check if it is because of an overload by typing in 'ps -aux'. Examine this line: root 2566 98.0 4.6 2452 1512 pts/0 S 13:52 0:00 ./something user PID cpu% software I have identified our main focus above. The user is root, the process ID is 2566, the cpu load is at 98%, and the software running is ./something. Wow. 98% of the cpu is being eaten up because of ./something. Even on a web server that serves about 5000-10000 sites a day, the most any single process should take at a time would be 15-20%. If it is of great importance, keep the process running..but restart it. Type in 'killall -9 2566'. Now restart it by executing it again (if you remember where the location of it is). If you don't know the location, type in 'locate something'. It should be pretty precise if the word is an uncommon reference on the server. We can optionally do killall -HUP something, which will automatically reload it after a fast kill...this is usually used for new configuration items though. Now check it again, the process % should be around 0.0.-1.0, if even that high. [Q]: UPGRADING USER 'STATUS'. Angie had upgraded Wreckk as an ftp user.. but he still couldn't log in? Why did that happen Charles? [A]: Well, Wreckk was already an established user for quite some time on the system, but only had e-mail access until now. Angie took the procedure as according to the Systems Administration Scriptures, but forgot one thing and made one mistake. She had put him in the same user her, and Dan already had access to... which was our group 'anissel', which was the one all ftp users had to belong to. That was good. Now comes to the problems. She enabled /bin/bash (I still don't know why?! Hehe..), which of course, should be enabled unless we want the user to have shell access. If it is only FTP access, make sure the user is set to /bin/false. Another thing which was my fault (woop!) was that I forgot to mention that I had added him to the /etc/ftpusers file. This file is used to tell the system which users are not allowed EVER to ftp. Wreckk was one of them. So I simply removed him off the list with 'pico /etc/ftpusers', found his name in it and deleted! Boom bap! Done! So it wasn't a big deal, just a case of misinformation. [Q]: Damn, those logs are pretty long! I don't feel like sorting through them... give me something easier! [A]: Been there and done that. 'su' as root and type in 'okay'. This will sort the most vital parts of our system logs in /var/log/okaylogs/. The logs have been categorized into each different daemon. I have also added a section for login failures to check for intruders and/or problems. These logs are derived from /var/log/messages, which I guess you can say is the centralized logs. But linux has many different log files, /var/log/messages being one of the most important. [Q]: Rackspace is always rebooting and some of the services stop after! WE NEED THOSE, LIKE APACHE!@# How do we start those processes back up? [A]: Let's start out with the basics. Luckily, linux organizes the starting daemons in one directory... /etc/rc.d/init.d/. If you go to any directory such as /etc/rc.d/init.d/rc0.d/ and 'ls -la', you will see a list of daemon names (which are really just shortcuts, like the ones on Windows Desktop. Here is an example of what the contents should look like: [root@server1 rc0.d]# ls -la total 2 drwxr-xr-x 2 root root 1024 Feb 6 16:12 . drwxr-xr-x 10 root root 1024 Feb 6 16:12 .. lrwxrwxrwx 1 root root 19 Dec 27 12:33 K00linuxconf -> ../init.d/linuxconf lrwxrwxrwx 1 root root 18 Feb 18 1997 K05keytable -> ../init.d/keytable lrwxrwxrwx 1 root root 15 Dec 18 18:23 K08iplog -> ../init.d/iplog lrwxrwxrwx 1 root root 13 Feb 18 1997 K15gpm -> ../init.d/gpm lrwxrwxrwx 1 root root 14 Jan 12 22:59 K25sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 18 Feb 18 1997 K30sendmail -> ../init.d/sendmail lrwxrwxrwx 1 root root 20 Jan 12 22:52 K44rawdevices -> ../init.d/rawdevices lrwxrwxrwx 1 root root 15 Feb 18 1997 K45named -> ../init.d/named lrwxrwxrwx 1 root root 14 Feb 18 1997 K50inet -> ../init.d/inet lrwxrwxrwx 1 root root 16 Feb 18 1997 K55routed -> ../init.d/routed lrwxrwxrwx 1 root root 13 Feb 18 1997 K60atd -> ../init.d/atd lrwxrwxrwx 1 root root 15 Feb 18 1997 K60crond -> ../init.d/crond lrwxrwxrwx 1 root root 16 Jan 10 17:03 K65identd -> ../init.d/identd lrwxrwxrwx 1 root root 15 Jan 12 22:52 K75netfs -> ../init.d/netfs lrwxrwxrwx 1 root root 16 Jan 12 22:52 K80random -> ../init.d/random lrwxrwxrwx 1 root root 17 Jan 12 22:52 K90network -> ../init.d/network lrwxrwxrwx 1 root root 16 Jan 25 2000 K96pcmcia -> ../init.d/pcmcia lrwxrwxrwx 1 root root 16 Feb 18 1997 K99syslog -> ../init.d/syslog lrwxrwxrwx 1 root root 17 Jan 12 22:52 S00killall -> ../init.d/killall lrwxrwxrwx 1 root root 14 Jan 12 22:52 S01halt -> ../init.d/halt But in this situation, you can't just can't make a 'symlink' or unix shortcut. You may notice that the shortcuts have a letter and then # in front of the shortcut names. Truthfully, I haven't figured out exactly what the K and S stand for (I did remember way back though..), but the numbers represent the position when the process will be launched. You could pretty much pick any number between 00-99, but I recommend between 20-99. For a new symlink, make it start with a K. Here is an example syntax of how to create a proper symlink so that the process will boot in the beginning. example: ln -s /etc/rc.d/init.d/inet /etc/rc.d/init.d/rc0.d/ If you "ls -la" in /etc/rc.d/init.d/ you will see that there are rc*.d directories. Each directory is specific for what is called the init level. Init levels are predefined lists of what to boot... rc0.d being the one with the least to boot. As the number goes up, the amount of daemons should increase.