Shell Programming and Scripting

We should not assume a certain scenario.
Many years ago I had to administer a booking system, where people had to register their project before using the application. It was not safe, but worked quite okay. The users were in the same company, and nobody wanted to boykott the company goals.

OK, so here we go again:

We have already established that there is always the problem that a user with sufficient privileges can undo what you do. This is especially true for the root user, who can modify any and every log/file/list/whatever there is on a system. There is only one solution to this dilemma: store a log offsite. That means, specifically: store a log file not on the system you want the auditing taking place but on another system. On this other system none of the people you want to be audited (especially the ones who can become root on your "normal" production systems) should have any rights - ideally not even to log on.

This is the reason why syslog has not only files as possible targets for the logs it creates but also "network", where the log updates are sent over the network to a target system. Modern syslogd replacements (i.e syslog-ng, rsyslogd, etc..) even refine this concept and you can send different facilities and different criticalities to different destinations, etc..

So, to get what you want you should investigate how to create the respective syslog-messages and how you configure the syslog-daemon of your choice to relay these to some destination.

Don't! If anything you don't come across as a professional software developer and therefore it is doubtful that you would be able to finish such a project successfully - let alone in the production quality offered by the projects i have just named (and perhaps a few more i don't even know of).

Look: this is a (badly performing) workaround for some workaround covering a conceptual flaw in badly thought out plan. As a rule of thumb: reasonable plans don't need workarounds and quickfixes, so if you ever notice yourself looking out for exactly these - understand that your plan is most probably flawed in first place and it would be better to fix the conceptual flaws than to patch a non-workable plan into working somehow.

This is how i do it too. There is no shame in formulating a bad plan and - upon recognizing that it is bad - rethinking it until one gets to something better. But holding onto a bad plan because with a vast amount of quickfixes it might sometimes work is asking for troubles (usually very successfully so).

Don't! First, it is my right as a user to modify my profile so that i can configure my environment to my likings. I suppose you have your own desk and let us assume that you are used to have your coffee cup on the left side of the keyboard. Would you appreciate a "company policy" of having it on the right side? The only thing you can achieve with such a ridiculous rule is to frustrate users because the environment they use doesn't "feel right" any more. One prefers i.e. a command prompt like this, the other wants to have it different - of course you can cksum (and this way make effectively read-only) the profile, but one of these two people will be disappointed in the end.

Instead, do something like what i suggested: it is not intrusive, it doesn't pester users and whats more it is efficient and relies on standard methods and procedures.

So, there. Instead of creating these enormously complex apparitions sit down, learn the UNIX facilities and what they can do for you. You will never be disappointed.

I hope this helps.

bakunin