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.
Friday, February 27, 2015
sol10 decides to have a filesystem error
or does it?
Wednesday, February 25, 2015
autostart sonarqube on ubuntu 10.04 x64
#!/bin/sh
#
# rc file for SonarQube
#
# chkconfig: 345 96 10
# description: SonarQube system (www.sonarsource.org)
#
### BEGIN INIT INFO
# Provides: sonar
# Required-Start: $network
# Required-Stop: $network
# Default-Start: 3 4 5
# Default-Stop: 0 1 2 6
# Short-Description: SonarQube system (www.sonarsource.org)
# Description: SonarQube system (www.sonarsource.org)
### END INIT INFO
/usr/bin/sonar $*
...
custom install here:
/opt/sonarqube-4.4.1/
# ln -s /opt/sonarqube-4.4.1/bin/linux-x86-64/sonar.sh /usr/bin/sonar
# chmod 755 /etc/init.d/sonar
# update-rc.d sonar defaults
double-check:
# sysv-rc-conf
yep.
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:
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:
#!/bin/bash
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
"
done
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.
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' < lansweeperscript.sh oh, and you have some special skel files, too. because you're awesome. .... #!/bin/bash # 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: lansweeper::15349:100::/: 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: #!/bin/bash # 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".
Subscribe to:
Posts (Atom)