- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- greatest blunders
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:02 AM
12-04-2002 01:02 AM
Please post the greatest blunders you think you have done in the life as a system administrator.
regards,
U.SivaKumar
"Best Men are moulded out of Faults - Shakesphere "
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:07 AM
12-04-2002 01:07 AM
Solution1) creating a filesystem on a database raw log location (that's was the last time I used SAM for any LVM-type work).
2) Believing what I was told when someone said that we could remove a FS from a system as the database that was using it had moved to another machine. Apparently, Ingres is a little picky when you take one of its data locations away, even if it's not being used. That led to an inconsistent database, and several days of tension while it was fixed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:11 AM
12-04-2002 01:11 AM
Re: greatest blunders
Using a lan console, then telnet on another lan console to do a CTRL-B RS. Guess which machine has rebooted ...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:15 AM
12-04-2002 01:15 AM
Re: greatest blunders
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:22 AM
12-04-2002 01:22 AM
Re: greatest blunders
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:25 AM
12-04-2002 01:25 AM
Re: greatest blunders
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:29 AM
12-04-2002 01:29 AM
Re: greatest blunders
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:36 AM
12-04-2002 01:36 AM
Re: greatest blunders
Regards,
Tomek
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:38 AM
12-04-2002 01:38 AM
Re: greatest blunders
Forgetting how links work. Copied what I thought was a file to a file, but ended up overwriting a linked .profile - oops.
Good job we had a backup :-)
Hilary
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:39 AM
12-04-2002 01:39 AM
Re: greatest blunders
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 01:53 AM
12-04-2002 01:53 AM
Re: greatest blunders
However I saw a good one the other day, one administrator, rebooted the wrong machine.... where's that egg?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 02:00 AM
12-04-2002 02:00 AM
Re: greatest blunders
echo "/dev/vg00/lvol6 /tmp vxfs delaylog 0 2" > /etc/fstab
reboot!!
Other good ones:
mv /dev/ /Dev
(try it - and don't ask why!!)
Later,
Bill
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 02:01 AM
12-04-2002 02:01 AM
Re: greatest blunders
ls /somedir
#oh that's rubbish
rm -r *
# removed all in current directory
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 02:29 AM
12-04-2002 02:29 AM
Re: greatest blunders
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 02:41 AM
12-04-2002 02:41 AM
Re: greatest blunders
Your case is common in racked servers. Sun uses
a locator to locate the server in the rack before giving reboot.
HP has anything like that , I doubt
regards,
U.SivaKumar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 02:53 AM
12-04-2002 02:53 AM
Re: greatest blunders
As a newby in UNIX I had an Oracle Testinstallion on a production system
productiv directory: /u01/...
test directory: /test/u01/...
deleting the test installation:
cd /test
rm /u01
OOPS ...
After several bdf commands I noticed that the wrong lvol shrinks and stops the delete command with Ctrl'C
The database still worked without the most binaries and libraries and after a restore from tape without stopping and starting the database all was ok.
I love oracle ;-)
Chris
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 02:58 AM
12-04-2002 02:58 AM
Re: greatest blunders
Develop a script in order to change the permits for all the files and subdirectories under the actual and when run change all the permits in the system.
Regards,
Justo.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 03:07 AM
12-04-2002 03:07 AM
Re: greatest blunders
cd /usr/bin
rm -f remsh : mv remsh.org remsh
=
remsh was rappidly restored ; i overlooked the disappearence of mv. It took 1 week for someone to notice it (only cron jobs were affected ; the other jobs used /sbin/mv).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 03:09 AM
12-04-2002 03:09 AM
Re: greatest blunders
Pete
Pete
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 03:17 AM
12-04-2002 03:17 AM
Re: greatest blunders
Cheers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 04:18 AM
12-04-2002 04:18 AM
Re: greatest blunders
Learning hpux? Naw, that's not it....maybe it was learning to spell aix?? sco?? osf?? Nope, none of those.
The biggest blunder:
One morning I came in at my usual time of 6am, and had an operator ask me what was wrong with one of our production servers (servicing 6 banks). Well nothing worked at the console (it was already logged in as root). Even a "cat *" produced nothing but another shell prompt. I stopped and restarted the machine and when it attempted to come back up it didn't have any OS to run. Major issue, but we got our backup tapes from that night and restored the machine back to normal. I was clueless (sort of like today)
The next morning, the same operator caught me again, and this time I was getting angry (imagine that). Same crap, different day. Nothing was on any disk. This of course was before we had raid availble (not that that would have helped). So we restored the system from that nights backups and by 8am the banks have their systems up.
So now I have to fix this issue, but where the hell to start? I knew that production batch processing was done by 9PM, and that the backups started right after that. The backups completed around 1am, which were good backups, because we never lost a single transaction. But around 6am the stuff hit the fan. So I had a time frame: 1am-6am, something was clobbering the system. I went though the crons, but nothing really stood out, so I had to really dive into them. This is the code (well almost) I found in the script:
cd /tmp/uniplex/trash/garbage
rm -rf *
As soon as I saw those two lines, I realized that I was the one that had caused the system to crap out every morning. See, I needed some disk space, and I was doing some house cleaning, and I deleted the sub-directory "garbage" from the /tmp/uniplex/trash" directory. Of course the script is run by root, which attempted to "CD" to a non-existent directory, which failed, and cron was still cd'd to "/", it then proceeded to "rm -rf *" my system!
live free or die
harry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 04:33 AM
12-04-2002 04:33 AM
Re: greatest blunders
Installed the switch, tested connectivity from both servers, cloned the production database's volume group onto another volume group, exported the volume group, imported onto the development server, started bringing up the development DB - trashed the production DB. I'd grabbed the wrong map file and imported the wrong VG.
But this wasn't my greatest blunder!! We coincidentally had some hardware problems with the FC60 and I mistakenly blamed the DB issues on them. Once we got the hardware all straightened out, I proceeded to do the same thing all over again, blindly believing that vgchange would protect me because vgchange supposedly won't let both systems activate the same VG - NOT!!
The good thing about this whole scenario is that we got really good at restoring the production DB - we've got the procedure down pat now.
Pete
P.S. We do share the FC60 to this day - we're just a lot more careful about which VG we're actually dealing with from which server.
Pete
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 04:40 AM
12-04-2002 04:40 AM
Re: greatest blunders
live free or die
harry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 04:41 AM
12-04-2002 04:41 AM
Re: greatest blunders
I'm a slower learner, I guess. Mine was this past summer.
;^)
Pete
Pete
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-04-2002 04:41 AM
12-04-2002 04:41 AM
Re: greatest blunders
Unfortunately the operator somehow got the wrong idea and managed to kick off a BCV restore, which as anyone who knows anything about EMC commands will realise is a completely different thing.
Anyway the long and short of it was that the system which runs an extremely busy large Oracle database was taken back to its state of 2 days previous, this then took about one and a half days to recover rolling forwards on the redo logs.