Linux

I hope this is the right forum to post this.

I need a little advice on something.

I want to create a daemon to run on a Linux server and this daemon should:
1. capture the `./configure` command so that it knows where a program installed via source would store it's binaries and, most importantly, configuration files.
2. somehow capture package manager activity so that it knows where the programs binaries and configuration files are.
3. detect when a service is started or stopped or restarted...basically, detect the change in status of a service. How does Linux know when a service is triggered? Is a /proc file or something like that triggered?

Would a daemon coded in Python work here? Also, what are the best options to capture a commands activity? strace? gdb?

For #1, I thought of just having my program read the bottom of the man's to get the location of the config files but a lot of programs don't have such details man's on Linux :/

My aim is to basically make a little program that self documents so that, for example, if an admin decides to install the latest PHP on a web server, compiled from source since the package manager doesn't have the latest version, my program should save that information to a file somewhere.

Any ideas?

Depends on your package manager. Linux often tracks services through PID files. When a program is run it creates a file contaning its integer PID; when it quits or dies, it deletes this file. Further details depends on what startup manager you're using. strace works, but has a high performance cost. gdb might be cudgeled into working but isn't really suited to it, and would have an even higher performance cost. I think you need to rethink your system here. If you don't want admins installing things or starting/stopping services without supervision, why are they admins? Instead of writing a giant omniscient daemon with its tentacles hacked into every aspect of the system, just restrict them from doing things you don't want in the first place. You can use sudo to grant admin access for only very specific things in very specific ways, so that to install something or stop a service, they have to run your program instead of the system one...

I should mention that this isn't something I'm doing for a particular set of people.
I just have a lot of time on my hands these days and a friend and I wanted to write a program that documents things for an admin automatically. I do a bit of freelance sys admin work from time to time and a lot of servers are either not documented at all or badly documented. I know this sounds a little ambitious but maybe I can start with something very small and build it up over a couple years.



Yeah, you're definitely right about configure being very customizable...but I don't know how to work around this.
You said configure is usually told where to install things. What tells it where to install things? Better yet, can you tell me where I can read more about building an installable source for Linux so that I understand what exactly goes on during the 'configure', 'make' and 'make install' process?



Regarding tracking services, watching /var/run is a reliable way to determine if a service was started, right? Or does this path also depend on what starup manager I'm using?

Thanks.

What files and programs are installed is usually tracked by the package manager, eg for Debian and derivates:

Code:

# aptitude search ~i #Shows installed packages
# dpkg -L make # Show files installed by "make" package

And honestly, an admin that didn't do proper documentation from the beginning probably won't start all of a sudden (and probably isn't very good at his/her job anyways)

If you want to understand 'configure', download the source of any program, and build it yourself. If you want to understand it very well, take a look at it's source (it's usually just a shell script). If you want to understand it, and the whole build process, very, very well, take a look at Linux from Scratch.

/var/run has some information about a service. If that service decides it wants to share that information in just that directory. Better would be to run the init script with the 'status' parameter (if supported) or check if the process turns up in ps -ef.

By the way, there's only one startup manager, /sbin/init, and it works the same on any Linux distribution, and most SystemV UNIXes.

...nnnnnnnot quite the right word. You want to hack linux to the very core to make it do something you could've done with very basic privilege management. Even if you do pull it off it'll self-destruct the next time autoconf breaks compatibility with itself(i.e. very frequently), probably insecure, and god help you should you ever need to upgrade. Try ./configure --help for basic info on how to use it. More generally, these things are autogenerated by the GNU tools autoconf, automake, and libtool. Be prepared for lots and lots of fun if you insist on hacking these things.