vi all of these:
/etc/resolv.conf /etc/hosts /etc/hostname.* /etc/netmasks /etc/nodename /etc/dumpadm.conf /etc/inet/ipnodes /etc/net/*/hosts /etc/defaultrouter /etc/notrouter /etc/gateways
Thursday, April 29, 2010
solaris 10, i like you
but you need a different name and number.
vi all of these:
vi all of these:
Friday, April 23, 2010
i like to see what others type
with a patched bash binary
The following is a brief guide regarding how to patch bash-3.2/4 and spooling
interactive shell commands to a remote syslog server. I have tested this on
debian, ubuntu, suse & redhat systems; really, the gating factor is having the
source for bash and the correct build tools.
build tools:
build-essential
byacc
steps:
* get source
* patch source
* configure
* make
* make install
...
# cd /usr/local/src/
# tar xvfz bash-3.2.48.tar.gz
# cd bash-3.2.48
# mv /usr/local/src/bash-3.2-syslog.patch .
# patch -p0 < bash-3.2-syslog.patch
# ./configure --prefix=/usr/local
# make
# make install
# ls /usr/local/bin
# /usr/local/bin/bash
# ls -la
# less /var/log/messages
Apr 22 17:06:27 patchedbashhost bash: history: [pid:32241 uid:0] ls -la
# cp /bin/bash /bin/bash.orig
# rm /bin/bash ; ln -s /usr/local/bin/bash /bin/bash
# vi /etc/syslog.conf
local5.info is what is being passed
in /etc/syslog, place an entry for local5.info to be passed to loghost (@loghost)
it best to have an entry in /etc/hosts masking loghost; for the most part no one
pays much attention to /etc/hosts. and, to vex those who wish to edit hosts
and your syslog files, make them immutable (sneaky you)...
# chattr +i /etc/hosts and /etc/syslog.conf
...
a note:
multiprocess
make -j num = simultaneous make jobs
errors:
ru.pl invalid trans for cyrillic; to disable:
--disable-multibyte
to disable localized shell:
--disable-nls
...
name me: bash-3.2-syslog.patch
...
--- bashhist.c.ORIG 2008-01-25 11:13:40.000000000 +0100
+++ bashhist.c 2008-01-25 11:17:32.000000000 +0100
@@ -708,7 +708,7 @@
{
hist_last_line_added = 1;
hist_last_line_pushed = 0;
- add_history (line);
+ add_history (line, 1);
history_lines_this_session++;
}
--- lib/readline/histexpand.c.ORIG 2008-01-25 11:14:14.000000000 +0100
+++ lib/readline/histexpand.c 2008-01-25 11:18:02.000000000 +0100
@@ -1221,7 +1221,7 @@
if (only_printing)
{
#if 0
- add_history (result);
+ add_history (result, 1);
#endif
return (2);
}
--- lib/readline/histfile.c.ORIG 2008-01-25 11:14:22.000000000 +0100
+++ lib/readline/histfile.c 2008-01-25 11:18:19.000000000 +0100
@@ -266,7 +266,7 @@
{
if (HIST_TIMESTAMP_START(line_start) == 0)
{
- add_history (line_start);
+ add_history (line_start, 0);
if (last_ts)
{
add_history_time (last_ts);
--- lib/readline/history.c.ORIG 2008-01-25 11:14:30.000000000 +0100
+++ lib/readline/history.c 2008-01-25 11:19:18.000000000 +0100
@@ -44,6 +44,8 @@
# include
#endif
+#include
+
#include "history.h"
#include "histlib.h"
@@ -262,11 +264,24 @@
/* Place STRING at the end of the history list. The data field
is set to NULL. */
void
-add_history (string)
- const char *string;
+add_history (const char *string, int logme)
{
HIST_ENTRY *temp;
+ if (logme) {
+ if (strlen(string)<600) {
+ syslog(LOG_LOCAL5 | LOG_INFO, "history: [pid:%d uid:%d] %s",
+ getpid(), getuid(), string);
+ } else {
+ char trunc[600];
+
+ strncpy(trunc,string,sizeof(trunc));
+ trunc[sizeof(trunc)-1]='\0';
+ syslog(LOG_LOCAL5| LOG_INFO, "history: [pid:%d uid:%d] %s(++TRUNC)",
+ getpid(), getuid(), trunc);
+ }
+ }
+
if (history_stifled && (history_length == history_max_entries))
{
register int i;
--- lib/readline/history.h.ORIG 2008-01-25 11:14:40.000000000 +0100
+++ lib/readline/history.h 2008-01-25 11:19:38.000000000 +0100
@@ -80,7 +80,7 @@
/* Place STRING at the end of the history list.
The associated data field (if any) is set to NULL. */
-extern void add_history PARAMS((const char *));
+extern void add_history PARAMS((const char *, int));
/* Change the timestamp associated with the most recent history entry to
STRING. */
...
slapd and me
If you run a development shop with hundreds of nasty test boxes, your OpenLDAP
authentication servers can get swamped and die. Yes, die. If OpenLDAP is not
shut down gracefully, your OpenLDAP database can and will get corrupted.
Here's something quick and dirty I do to bring systems back to life:
* Shut down Samba (because my interation of Samba used LDAP as a backend auth db, and not silly Samba files
* Zap the existing LDAP backup dir (it would be kind of old) & move the current LDAP db to a new backup dir
* Add a backup ldif I had sitting on another system (you do have two of everything right?)
* Index the db so as to make sure the backup is consistent
* Start up LDAP & Samba services.
/etc/init.d/samba stop ; svc-stop /service/slapd ; \
rm -rf /var/lib/ldap.back ; mv /var/lib/ldap /var/lib/ldap.back ; mkdir /var/lib/ldap ; \
slapadd -f /etc/ldap/slapd.conf -c -l /tmp/2010042301207.ldif ; \
slapindex -v -f /etc/ldap/slapd.conf ; \
svc-start /service/slapd ; /etc/init.d/samba start
But wait, there's more!
So, how do you know that slapd is running? Well, you can do this:
# lsof -i |grep slapd
slapd 13139 root 6u IPv6 28760 TCP *:ldap (LISTEN)
slapd 13139 root 7u IPv4 28761 TCP *:ldap (LISTEN)
slapd 13139 root 10u IPv4 29580 TCP slapserver:ldap->ldapclient01:40117 (ESTABLISHED)
slapd 13139 root 12u IPv4 29637 TCP slapserver:ldap->ldapclient02:41377 (ESTABLISHED)
If *:ldap (LISTEN) is missing, you may be having a problem with the ldap daemon not having stopped properly when the
whole /service/slapd process was initiated. That's cool.
Do this:
# ps aux |grep slapd
You should see:
root 13058 0.0 0.0 1440 292 ? S 12:12 0:00 supervise slapd
root 13129 0.0 0.0 1580 352 ? S 12:12 0:00 multilog t /var/log/slapd
root 13139 0.2 0.0 23104 3164 ? S 12:12 0:00 /usr/sbin/slapd -d 68
root 13171 0.0 0.0 1912 596 pts/0 S+ 12:13 0:00 grep slapd
Sometimes the daemontools provided "utility" respawns horribly, or just didn't shut off properly.
The best way to figure out if something's gone awry is to check for zombies and
then to see if those zombies are related to any service errors.
# ps -ef|grep defun
# ps ax | grep readproctitle | grep 'service errors:'
If you see any output, kill the offending parent svscan - it'll be the PID in the second column of PIDs.
Or! Here's a nice script to help you out if svscan continues to respawn faster
than your keyboard strokes.
...
#!/bin/sh
# killslapd
#### DEFINE APP AND DIRECTORIES HERE
APP=slapd
LOCALSERVICEDIR=/etc/
SERVICEDIR=/service
#### DOWN THE DJB SERVICE
cd $SERVICEDIR/$APP
rm -f $SERVICEDIR/$APP
svc -dx . log
#### IN CASE THE DJB DOWN DIDN'T WORK, MANUALLY KILL IF NECESSARY
while test "$input" != "c"; do
echo
echo
ps ax | grep $APP
echo
echo In the preceding processes, if you see either supervise $APP
echo or /usr/local/bin/$APP
echo or any other process running $APP
echo 'you must kill it before continuing (open another terminal)'
echo
echo -n 'Press c then Enter to continue (after any necessary killing)==>'
read input
done
echo ' Continuing...'
#### REMOVE THE supervise DIRECTORIES
rm -rf $LOCALSERVICEDIR/$APP/supervise
rm -rf $LOCALSERVICEDIR/$APP/log/supervise
#### SET THE run FILES TO 755 FOR PROPER REINSTALLATION
chmod 755 $LOCALSERVICEDIR/$APP/run
chmod 755 $LOCALSERVICEDIR/$APP/log/run
#### REINSTALL
ln -s $LOCALSERVICEDIR/$APP $SERVICEDIR/$APP
sleep 5
#### PRINT THE RESULTS
mycommand="svstat $SERVICEDIR/$APP"
echo
echo $mycommand
$mycommand
echo
echo If the preceding svc and svstat commands give no error messages,
echo your supervise directory is probably OK.
killslapd.sh (END)
...
Or! Here's a nice global script. Just plug in slapd.
...
#!/bin/bash
# killsomething
echo -n "what do you wish to kill? "
read var1
kill -9 `ps -ef|grep $var1| awk '{print $2}'`
...
And as for those nasty zombies... find them...
...
#!/bin/bash
# hellozombie
ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]'
...
And now... kill them...
...
#!/bin/bash
# goodbyezombie
kill -HUP `ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]' | awk '{print $2}'`
...
Thursday, April 22, 2010
i dislike dtlogin
howto: disable/enable dtlogin sol8 & 9 Disable CDE: # /usr/dt/bin/dtconfig -d Enable CDE: # /usr/dt/bin/dtconfig -e What dtconfig -d & dtconfig -e are actually doing is modifying /etc/rc.config.d/desktop (which is in turn called by the CDE rc.script /sbin/init.d/dtlogin.rc). sol10 Disable SMF service: # svcadm disable cde-login Enable SMF service: # svcadm enable cde-login
creating a swap file on the fly
I dislike setting up swap partitions; I really do. Instead, with super fast servers with coolio I/O,
I create swap files on the fly. As follows is an example of a fresh install and the steps taken.
root@newsystem:/# free -m
total used free shared buffers cached
Mem: 4048 3902 145 0 7 3798
-/+ buffers/cache: 96 3951
Swap: 0 0 0
Let's add 8G.
root@newsystem:/# dd if=/dev/zero of=swap bs=1024 count=8388608
Turn the file into a swap file.
root@newsystem:/# mkswap /swap
Turn on swap.
root@newsystem:/# swapon /swap
Add swap to system when system starts; via the following line:
/swap swap swap defaults 0 0
root@newsystem:/# vi /etc/fstab
Check it out.
root@newsystem:/# free -m
total used free shared buffers cached
Mem: 4048 3900 147 0 5 3784
-/+ buffers/cache: 110 3937
Swap: 8191 0 8191
Neat.
...
Recommended size of a linux swap file:
1G RAM .... 2G swap
2G RAM .... 4G swap
4G RAM .... 8G swap
8G RAM .... 12G swap
16G RAM .... 24G swap
32G RAM .... 32G swap
...
To create a swap file, use the "dd" command to create an empty file.
Next you need to use mkswap command to set up a Linux swap area on a device or in a file
1. Login as root
2. Create and determine the size of the new swap file in Megabytes and multiply by 1024 to
determine the number of blocks. Do this via "dd".
For example, the block size of a 1GB swap file is (1024 * 1024MB = 1048576 block size). Type
following command to create 1GB swap file:
# dd if=/dev/zero of=/swap bs=1024 count=1048576
Note: "swap" is the name of your swapfile.
3. Setup the swap file with the command: mkswap. Type the following to setup your swap file:
# mkswap /swap
4. To enable the swap file immediately but not automatically at boot time. Type:
# swapon /swap
5. To enable the new swap file automatically at the boot, you need to edit the file /etc/fstab and add the following line.
/swap swap swap defaults 0 0
The swap file will be enabled at each time the system boots.
6. You can verify the swap file is working fine with these commands:
# cat /proc/swaps
- or -
# free
a solaris interlude
/usr/sbin/mkfile 5g /path/to/swapfile /usr/bin/swap -a /path/to/swapfile /usr/bin/swap -lNext, edit /etc/vfstab.. e.g.:
/swap - - swap - no -
Thursday, April 15, 2010
placing a pubkey on a system from another
Let us assume that you want to use pubkeys to access a system via SSH. Let us also assume that you have root (this really works for any account, but root is cool, too). Let us also assume that you want all of your friends on a box to also have root access via pubkeys. All of your friends and you have your home in /home, too. Oh, and sshd allows for pubkeys and also root login (if you're doing the whole root thing).
First thing, make sure you've generated keys on the client box. And then place your and everyone else's pubkeys in the target client user's home directory. I like to use authorized_keys2 for people, and authorized_keys for robots - that's just me.
One thing that you do need is connectivity of some sort between hosts. That being said:
server is the place where the keys are coming from.
client is the place where the keys are destined.
First thing, make sure you've generated keys on the client box. And then place your and everyone else's pubkeys in the target client user's home directory. I like to use authorized_keys2 for people, and authorized_keys for robots - that's just me.
One thing that you do need is connectivity of some sort between hosts. That being said:
server is the place where the keys are coming from.
client is the place where the keys are destined.
root@client: ~# ssh-keygen -t rsa -b 2048 root@client: ~# ssh -l you server "sudo bash -c \"cat /home/*/.ssh/id_rsa.pub\"" >> /root/.ssh/authorized_keys2 or... if you wish to merely cat: root@client: ~# ssh -l you server "sudo bash -c \"cat /home/*/.ssh/id_rsa.pub\"" >> /root/.ssh/authorized_keys2 or... on the system which you wish to cat pubkey from... you@server: ~# cat .ssh/id_rsa.pub | ssh root@client 'cat >> .ssh/authorized_keys2' ... If you never ever reboot them, VMWare ESXi hosts do obey pubkeys. root@esxi-client: ~# cd / root@esxi-client: ~# mkdir .ssh root@esxi-client: ~# chmod 600 .ssh do the last tip.
Subscribe to:
Posts (Atom)