Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a linux server (Debian squeeze) set up. It's primary focus is to run LAMP. I also use it for stuff like mumble (voice chat) and minecraft servers.

In the beginning everything was running fine. Then things started to happen. Stuff like java failing to run without headerless mode, and completely losing the ability to resolve hostnames. I fixed the hostname resolving by a reboot - which I've heard isn't really a desired fix on linux systems.

I do have physical access to the server computer (I built it myself), but it's not located in my house. So I use SSH to interact with it. Yesterday I noticed that it doesn't show the path in the ssh client but rather only "-bash-4.1#".

Also after the reboot when I tried starting the mumble server it just says missing file: "/etc/mumble-server.ini"

This server contains vital (and confidential) company information. Should I be worried that some hacker got into it? Did I install some kind of malware on it?(Doubt I did)

EDIT: I cannot seem to access the website it is supposed to be hosting. It is a vital part of the companys web services. This is real bad.

I also now remember mistakenly running something like rm .* in /etc with root a couple weeks ago. It worked fine then so I ignored it. Is there anything I can do to fix this? Did I really screw up?

UPDATE: It seems apache fails to run due to a missing mime.types file. It should be located in /etc. Is there a command to restore it?

UPDATE: Since everything else failed, I am reinstalling the OS and server software. Good thing I have all the vital and confidential info backed up regularly.

share|improve this question

closed as not constructive by ewwhite, Scott Pack, John Gardeniers, Mike Pennington, Lucas Kauffman Jul 25 '12 at 11:16

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

If you remember where in /etc/ you ran that rm command it would help, based off your comments bellow and that you have very little time, a really tacked on temporary solution would be to install the same debian version on a VM, install critical packages and compare what is missing between that VM and your server ( run find /etc on both, diff files ). in etc. It would likely be enough to get apache going. – Pratik Amin Jul 25 '12 at 2:21
Do you have any backups? – jscott Jul 25 '12 at 2:24
When the machine is back up it would be a very good idea to reconsider hosting business services alongside personal ones (MC & mumble). If you ran the rm command the other week then isn't it likely the site has had issues since then... ? Also this seems like more than just apache has been affected due to your mumble issue above. Sounds like the rm was run in the /etc and not /etc/httpd so who knows what else might be broken... Backups or new build time! – Beeblebrox Jul 25 '12 at 2:32
history | grep rm? – Shane Madden Jul 25 '12 at 2:34
I'm not judging, but I find the combination of "vital (and confidential) company information" and Minecraft on the same server quite interesting. – basvdlei Jul 25 '12 at 10:07

Most likely the cause of your problems is the rm command that you ran in /etc. I would suggest reinstalling the OS.

share|improve this answer
Is there ANY other way. This system is NEEDED in 6hours – Akke Jul 25 '12 at 1:45
Atleast get apache up? I can connect to the mysql server. – Akke Jul 25 '12 at 1:46
@AxelLatvala - 6 hours should be plenty of time to get the bare OS installed and restored from backup. – EEAA Jul 25 '12 at 2:07
Try running dpkg-reconfigure apache2 – Pratik Amin Jul 25 '12 at 2:19
If you're missing files from /etc, you need to restore them from your latest, functional, backup. – jscott Jul 25 '12 at 2:35

Your best bet to figure out exactly what you did, and where, is to check your sudo logs. Here's an example entry:

Jul 24 22:38:08 node1 sudo:    scott : TTY=pts/0 ; PWD=/home/scott ; USER=root ; COMMAND=/bin/rm marker_file

So we can see that I issued the command /bin/rm marker_file, with no additional arguments, from the directory /home/scott. So what this tells us is that I deleted the file /home/scott/marker_file.

Extrapolating this out we can figure out exactly what's missing, so you have a better idea which files to pick out of your backup. For instance, if we saw the log message

Jul 12 08:38:08 node1 sudo:    scott : TTY=pts/0 ; PWD=/etc/httpd/modules ; USER=root ; COMMAND=/bin/rm -rf tmpfile *

then we can figure out that you recursively deleted everything starting in the directory /etc/httpd/modules. Since this gives us both the timestamp of the event, as well as the list of affected files, we can pretty easily figure out what needs to be restored.

Additionally, I would make the guess that you were attempting to tab-complete the group of files that started with tmpfile without realizing that only one existed. I jumped to this conclusion based upon the fact that, generally, bash will add a space to the end of a fully matched file when tab-completing. That would be a complete conjecture, however, and only worth mentioning as a potential explanation of the incident.

share|improve this answer
I pretty much do remember the command i ran. It was (in /etc). rm *.* /backups/ – Akke Jul 25 '12 at 3:02
@AxelLatvala - I refer you to Shane Madden's comment on the question: history | grep rm - this will tell you exactly what you ran. – Mark Henderson Jul 25 '12 at 3:04
Ok here they are: rm .* /backup/eResk/ and rm .* /backup/eResk/ Both were ran from /etc – Akke Jul 25 '12 at 3:08
@AxelLatvala: That's actually not too terrible, since I wouldn't expect many dotfiles in /etc. If you got that from history, remember that by default it replaces your history file every time you close your session. So if you have multiple login sessions open at once, then data loss will occur. – Scott Pack Jul 25 '12 at 3:20
@scottpack Ok. Thats good. Now I need to get my apache server to send right mime types. Any idea? – Akke Jul 25 '12 at 3:22

Undoing (most of your) mistakes in Debian, such as deleting vital configuration files from /etc, can be undone by reinstalling all packages. This can be done with the following command:

aptitude reinstall '~i'
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.