Quote:
Originally Posted by sb008
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.
sb008:
Thanks for the suggestion. I feel the same way.
Quote:
Originally Posted by vbe
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...
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.