Friday, February 27, 2015

sol10 decides to have a filesystem error

or does it?
 oh wow. my sol box's local filesystem isn't mounting and is in maintenance mode.  
 what in the wide world of sports is a-goin' on here?  
 Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@0,0:a File and args:   
 SunOS Release 5.11 Version 11.0 64-bit  
 Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.  
 Hostname: flocked  
 svc:/system/filesystem/local:default: WARNING: /usr/sbin/mountall -l failed: exit status 1  
 Feb 27 10:44:14 svc.startd[11]: svc:/system/filesystem/local:default: Method "/lib/svc/method/fs-local" failed with exit status 95.  
 Feb 27 10:44:14 svc.startd[11]: system/filesystem/local:default failed fatally: transitioned to maintenance (see 'svcs -xv' for details)  
 $ cat /var/svc/log/system-filesystem-local:default.log  
 look for "ERROR"  
 see the error?  
 go to /etc/vfstab and comment that crap out.  
 #svcadm -v clear svc:/system/filesystem/local:default  
 #svcadm -v enable svc:/system/filesystem/local:default  
 time to go back to sleep.  

Wednesday, February 25, 2015

autostart sonarqube on ubuntu 10.04 x64

 # rc file for SonarQube  
 # chkconfig: 345 96 10  
 # description: SonarQube system (  
 # Provides: sonar  
 # Required-Start: $network  
 # Required-Stop: $network  
 # Default-Start: 3 4 5  
 # Default-Stop: 0 1 2 6  
 # Short-Description: SonarQube system (  
 # Description: SonarQube system (  
 /usr/bin/sonar $*  
 custom install here:  
 # ln -s /opt/sonarqube-4.4.1/bin/linux-x86-64/ /usr/bin/sonar  
 # chmod 755 /etc/init.d/sonar   
 # update-rc.d sonar defaults  
 # sysv-rc-conf   

adding pubkeys all over the place

security is good. let's just repeat that. disabling strict host key checking is bad. repeat that, too.
let's pretend you need to put pubkeys all over the place so that you can run a script all over the place.
let's say that you want to keep on doing your host key checking because, well, it is a good thing. but you are in a rush.
and you have like a zillion servers to check.

here's what you do:

user = fluffybunny
pass = likes.carrots
for ip_addr in $(cat nodes) ; do  
ping -q -c 1 $ip_addr &&  
expect -c "  
spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -l $user $ip_addr  
expect \"?assword:*\"  
send -- \"$pass\r\"  
expect "~"  
send -- \"mkdir .ssh\r\"  
expect "~"  
send -- \"chmod 700 .ssh\r\"  
send \"exit\r\"  
spawn scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no authorized_keys2 $user@$ip_addr:/home/$user/.ssh/authorized_keys2  
expect \"?assword:*\"  
send -- \"$pass\r\"  
expect eof  
nb: you have a standard account across all systems. it is called "fluffybunny" the password is "likes.carrots". nodes is a file with all the nodes you need to pubkey.

Friday, February 6, 2015

adding a lansweeper user on a standalone linux box

let's pretend you're in a shop where everyone has their own linux box and for whatever reason they're not using central authentication, just because. and say you want to inventory them and you're using something like lansweeper, because you're that sort of person. just because.

lansweeper is totally cool with windows audits. and for linux/solaris/mac audits you have to have ssh enabled and the auditing user with a password. o k a y. pubkeys would be waay better, but i digress. given the task at hand, you still need to create a user on each and every one of those boxes. and because you're cool, you have ssh and pubkey access. cool.
From a management host:
# scp ~/lansweeper/skel/.* root@host:/etc/skel
# ssh -l root host 'bash -s' <

oh, and you have some special skel files, too.  because you're awesome.

# lansweeperscript
mkdir /opt/lansweeper ; useradd lansweeper -g users -d /opt/lansweeper
echo -e "silly\!pass\nsilly\!pass" | passwd lansweeper
cp /etc/skel/.bashrc /etc/skel/.profile /opt/lansweeper/
chown -R lansweeper.users /opt/lansweeper
cp /etc/sudoers /etc/sudoers.$(date +%Y%m%d%k%M)
sed -i -r -e 's/Defaults\s+(.*)requiretty(.*)/\1\2/' /etc/sudoers
echo 'lansweeper ALL=(ALL:ALL) ALL' >> /etc/sudoers

You get bonus points if you're on a standalone box that doesn't do LDAP auth, but happens to have directories mounted and the like...

a. have an LDAP server and have created the user lansweeper and taken note of the uid (say 15349) .

b. created a home directory on your NFS-accessible fileserver (say, a NetApp) and have exported the volume as /home.

c. edited the passwd file on your NFS-accessible NetApp and have put  in the username, uid & gid ; say:

d.  and mount /home via fstab or something on your machine.  say, you have this line:
netapp:/home          /home           nfs     rsize=8192,wsize=8192   0 0

e. you change that first command to:
useradd lansweeper -u 15349 -g users -d /home/lansweeper

But if you're awesome and are on an LDAP'd system, you really only need to:

# lansweeperscript
cp /etc/sudoers /etc/sudoers.$(date +%Y%m%d%k%M)
sed -i -r -e 's/Defaults\s+(.*)requiretty(.*)/\1\2/' /etc/sudoers
echo 'lansweeper ALL=(ALL:ALL) ALL' >> /etc/sudoers

g. if you're totally lazy and not on a centos or redhat box you can forget the tty nonsense and issue this from your management system shell:

echo 'lansweeper ALL=(ALL:ALL) ALL' | ssh root@host "cat >> /etc/sudoers"
NB:  sometimes you'll find that there's something funny going on with sudoers and tty; that's why i've removed the requiretty line from /etc/sudoers.
But a backup is always good in case we do something "wrong".