2014-02-07
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.
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.)