Parameter to avoid file being deleted by SAM

Good afternoon.

I am a newbie.

We just had a potentially big problem (negated to having good backups).

Basically, there is an option in SAM, to delete all the data from the system that a user ever created.

Lo and behold, silly me, I choose that option, and all sorts of needed files get deleted.

Luckily, we have a good backup.

Unfortunately, I would like to avoid this situation in the future.

Is there a way to choose which directories are *blocked* from being cleared by SAM?

I noticed , from checking thesam_remove.log that the "/var" directory was blocked, for example, but I want the same exclusion for other directories. Is that possible?

Thanks!

To avoid this and unexpected results from other commands or options in SAM I suggest you take a Unix course.

Unless you prefer to turn a Unix box into a Windows box.

Im not a SAM fan (for I find its a lot fast by command line...but of course you need to know what you are doing...) so I dont see what you are talking about unless of the option when you remove a user, in this case ther is also an option to "give" the ownership of those files to someone else ( by far the safest).
these options were for ease of human beings users administration not for removing application/software users id far more delicate...

sb008:

Thanks for the suggestion. I feel the same way.

vbe:

Neither am I. I would prefer command line. (If I knew what I was doing.)

Fortunately, I feel that this particular mistake is one that you only make once. Unfortunately, I see myself making this type of mistake in the future, unless I get some self-training going, as I doubt the company is going to pay for it ... far cheaper to them to send people into the fire, and hope they're smart enough (or, in this case, the backups are good enough) to keep things going without any formal training. I hate it where my first exposure to a systems administration task comes from following some script of screenshots, when I don't really know what is going on in the background.

In this particular case, I realized that certain users who were deleted used to have development functions, and the files were created by the developers. Unfortunately, when I chose this option (actually, I was just following a screenshot in the documentation ... no thought processes going on) I had no idea that certain parts of the application were developed/modified by users, thus, those users owned those items, and, when the users were removed, all of the stuff was deleted, too.

At any rate, good backups saved the day. My manager complained that the developers shouldn't have owned any files. I was like, but, hey, this is how it works in a standard manner, you create the file, you own it, nothing wrong with that to me. I told him that I chose the wrong option, and, yeah, maybe a periodic re-owning of the files would help, but I told him that if you chose that same option (to remove all files owned by the user) on this other admin/restricted user account that owned the files, you would have the same problem again (praying for good backups).

Therefore, I thought a good overall solution would be to have the certain directories barred from being deleted by sam, such that this type of problem couldn't happen again (even IF someone chose the wrong option).

But, yeah, I agree with you two both, I'm a newb, and newbs shouldn't be running systems. I just hope that something detrimental to the business (as this incident potentially could have been, as this system houses our ERP) doesn't happen before the company realizes that.

The last 'NIX I touched before working on these systems at work was back during my Army AIT in the year 2000. Everything since that time has been mostly Windows, and a bit of Cisco, but no UNIX at all, until the admin leaves for an Air Force job, and we choose to not hire a new person, but instead have the old guy come in for a few hours (when he can, depending on his commitments to his other job/home).

Oh well, you live and you learn.

I now question my judgment in taking this job (Though, in my defense, it did change a lot from when I was hired until now ... you know the story, ever increasing responsibilities, without any corresponding increase in pay.)

OK, I'm ranting, and this serves no one any aid.

Overall, thanks for your tips. I take them to heart.

Welcome to the club...
I started as a developper but shortly was thrown as a sysadmin because thas is what they needed but didnt have the job except a developpers job on unix/oracle...(far long ago...).
I know how it is and think you are lucky, you have this forum and Internet, what I didnt when I started...
Lesson one: You learn by mistakes! (By far the most efficient since you rarely do the same silly mistake twice)
Lesson Two: Sometime you have no other choice than to go ahead...and produce a catastrophy, so before: Check you have a good backup! when it comes to system be sure you have a recent make_recovery tape or image to restore the OS (good practice...) look at the mans:
man make_recovery, vgdisplay lvdisplay etc...
About the developpers :You are right developpers ARE NOT to be owners of applications, only of what they in development/test, that is once in production applicatopn_owner is owner of all files...So Im not the one going to blame you but the chief of dev team.
Be free to ask anyhing here especially if you are unsure of possible consequences.
We will be just to glad to help you
Till nest
Best regards

One tip is to lock the account rather than delete the account until you can find a new owner for the files. If the account is deleted the files will just have a numeric owner.