Wandering Thoughts archives


A followup to what sudo emails to ignore and not ignore

So I wrote this entry on what sudo emails to ignore and not ignore the other day. Today we got some email from sudo, reporting:

appsN : Feb  7 12:36:24 : <redacted> : 3 incorrect password attempts ; TTY=pts/NN ; PWD=/h/<redacted> ; USER=root ; COMMAND=/bin/echo great post Chris!

I've got to award this a special bonus prize for probably the most amusing and clever blog feedback I've ever gotten. It certainly made me (and my co-workers) laugh. Well done!

(And yes, because I'm a cautious sysadmin I did indeed check our logs to see if the account might have been compromised and then just to be sure I also verified that the IP the user had logged in from had been used to request URLs here. I was pretty sure even before I started, but after recent events I'm just a little bit jumpy about ignoring things that I think have to be harmless.)

PS: For the record, I'm also pleased that at least one of our users finds my blog interesting enough to read. And I'm happy to take requests for bits of our infrastructure to write up here, if they (or other people) are curious. Email, Twitter, whatever.

sysadmin/SudoWhatNotToIgnoreII written at 13:58:15; Add Comment

A surprise with OmniOS disk sizing: the rpool/dump ZVOL

Until recently, all of my work installing and reinstalling OmniOS has been in a virtual machine, which had a modest configuration. Recently I started doing test installs on our real fileserver hardware, which resulted in a disk sizing surprise in the default OmniOS install.

Our fileserver hardware has 64 GB of RAM and an 80 GB SSD system disk (well, two of them but they're mirrored). On this hardware the OmniOS installer set up a dedicated 32 GB chunk of space for kernel dumps (the rpool/dump ZFS volume). On the one hand, this is very much not what I wanted; I definitely don't want half of a quite limited amount of disk space to disappear to something which I expect to never use. On the other hand you can argue that this is at least half rational as an OmniOS default, since OmniOS itself needs almost no disk space. If you probably need 32 GB of kernel dump space for safety and the disk space is there, you might as well use it for something.

(I call this only half rational because I'm not sure there's enough space left in /var to write out a kernel dump that actually needs all of that 32 GB of dump ZVOL, since both OmniOS itself and the swap ZVOL use of some of the remaining space.)

The normal installer image doesn't give you a convenient way to customize this, so my workaround is to simply delete the dump ZVOL after installation:

dumpadm -d none
zfs destroy rpool/dump

If our OmniOS systems ever start crashing in a situation where a crash dump might be useful, we can revisit this and perhaps recreate a rpool/dump ZVOL of some suitable size.

(The OmniOS installer also defaulted to a 4 GB swap ZVOL. On the one hand this strikes me as excessive; on the other hand it's only 4 GB and swapping to and from a SSD is going to be a bunch faster than a traditional hard disk swap so having to go to swap might be quite as terrible as it used to be. We're leaving the swap ZVOL alone for now.)

solaris/OmniOSDiskSizing written at 01:04:16; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.