You are currently browsing the category archive for the 'Howto' category.
I have some installations of Fedora Directory Server (FDS) running as the user nobody. It is generally preferred that services like FDS run under a dedicated user and certainly not the nobody account. The user is configured during an initial scripted interactive setup but I wanted to change the user for the existing installations. I could not find a how-to for doing this (though did not look very hard) so I did a new installation on a beater box and during setup configured it to run as user ldapperuser and group ldappergroup. I used this installation to experiment with reconfiguring the user.
I shutdown the slapd service and changed ownership of the files owned by ldapperuser and/or ldappergroup.
find /opt/fedora-ds -user ldapperuser | xargs chown ldap find /opt/fedora-ds -group ldappergroup | xargs chgrp ldap
By grep’ing for the silly user and group names I found these text files needed to be edited to change the user and/or group.
/opt/fedora-ds/admin-serv/config/console.conf /opt/fedora-ds/shared/config/ssusers.conf /opt/fedora-ds/slapd-pepper/config/dse.ldif
I restarted the slapd process and confirmed in a process list that it was running as the new user.
Finally, I exported the entire directory to an ldif file and grep’ed it for the user and group names. There I found that I needed to change the nsSuiteSpotUser attribute in "cn=slapd-pepper, cn=Fedora Directory Server, cn=Server Group, cn=pepper.crashingdaily.com, ou=crashingdaily.com, o=NetscapeRoot"
I made this change to nsSuiteSpotUser via the Admin console.
There may very well be an official way to change the user for an installed FDS but this brute force method is simple enough.
Lifehacker a nice write up on Firefox web browsing with SOCKS proxies. The tip about network.proxy.socks_remote_dns was new to me and I will have to play with that sometime. Safari, my primary browser, seems to resolve DNS requests at the proxy by default so that saves me the hassle in the meantime.
One of the take home messages of the Lifehacker entry is that you can run “ssh -D 1080 server.remotehost.com” on your workstation, then configure Firefox (as well as most other browsers) to use a SOCKS proxy at localhost port 1080. This provides encrypted communications between your workstation and server (great when your workstation is on an untrusted wireless network) and for masquerading as the server (useful when accessing websites that are behind a firewall or that restrict access by IP address).
Very simple, extremely handy. But what if you want to use remote server that is behind a firewall and only accessible via a gateway machine?
---------------- ------------- ------------- | workstation | | | | server | | | --------------| gateway | ------- | | |(web browser) | | | | (SOCKS) | ---------------- ------------- -------------
In that case you have to tunnel through the gateway to get to the SOCKS server running on the server. In this post I’m going to walk though building up the ssh command that will achieve such a tunnel. I will then present an alternate, more generic method.
I do not have a root password for many of the servers I interact with so I can not SSH directly in as the root user. Also, the ssh daemons are wisely configured with ‘PermitRootLogin’ set to ‘no’ so a password would be moot anyway. I do have sudo permissions on the servers so I can connect under my username and sudo the privileged commands as needed. Glazed-eye screen-staring started when I needed to rsync a remote directory that was read-only for root. How do I get rsync to run under sudo on the remote server? I did some searching and here are some options I found.
Option 1. Set NOPASSWD in the /etc/sudoers file.
crashingdaily ALL= NOPASSWD:/usr/bin/rsync
Then use the --rsync-path option to specify the sudo wrapper.
rsync -a -e "ssh" --rsync-path="sudo rsync" crashingdaily@server.remotehost.com:/u02/data_pump_dir/ /archive
Option 2. For interactive usage, I can pre-activate sudo and then run rsync as in Option 1.
stty -echo; ssh server.remotehost.com sudo -v; stty echo
rsync -a -e "ssh" --rsync-path="sudo rsync" crashingdaily@server.remotehost.com:/u02/data_pump_dir/ /archive
The “stty -echo” and “stty echo” is used to temporarily disable the display of the keyboard input to prevent the sudo password from being displayed.
Credits: Wayne Davison and Julian Cowley
Option 3. If sudo is not available, there is possibly an option to use “su”. I was unable to get this to work. su seems to insist on a tty - I get the error ’standard in must be a tty’. (In this case I do have a root password to use with su, so that’s not an issue).
Create a wrapper script, /usr/local/bin/su-rsync, on the remote server and make it executable.
#!/bin/sh
su - -c "rsync $*"
su - -c "rsync $*"
Then call that script with the --rsync-path option.
rsync -a -e "ssh" --rsync-path=/usr/local/bin/su-rsync crashingdaily@other.remotehost.com:/u02/data_pump_dir/ /archive
Credit: Wayne Davison
Option 4. Set ‘PermitRootLogin’ to ‘yes’ on the remote server and use SSH key authentication to login directly as the root user. This isn’t really an option for me but I throw it out there for sake of completeness.
Related:
If you don’t know where you are going, any road will take you there.
- Lewis Carroll
My production servers reside behind a perimeter firewall in a data center. A minimal set of ports are open to the world, notably port 22 for sshd and port 80 for the Apache webservers which proxy requests to one of several Tomcat instances. The Tomcat ports are blocked at the data center’s perimeter firewall which means no direct access to Tomcat’s manager interfaces. But that’s OK, there are several options for reaching the Tomcat manager from outside the data center. I’ll glance over three options and then delve into a fourth option that is the gooey center of this posting.
I have a shell script to manage and report on my Tomcat instances. I wanted the ’status’ portion of the script to report on instance uptime (which, by the way, has improved significantly since switching to JRockit). The script was already reporting the PID of the parent tomcat process so I shoved in this one-liner that takes that PID and gets the elapsed time from ps. I filter the result through grep and sed to get a clean human-readable output.
uptime = `ps -o etime $PID |grep -v ELAPSED | sed ’s/\s*//g’ | sed “s/\(.*\)-\(.*\):\(.*\):\(.*\)/\1d \2h/; s/\(.*\):\(.*\):\(.*\)/\1h \2m/; s/\(.*\):\(.*\)/\1m \2s/”`
echo $uptime
The output is formated as one of days&hours, hours&minutes, minutes&seconds.
6d 08h
03h 23m
20m 56s
03h 23m
20m 56s
Anyone got a better or different way?
ls -d /usr/local/tomcat_instances/{InstanceA, InstanceB, InstanceC, InstanceD}/conf/Catalina/localhost | xargs -i{} cp /usr/local/tomcat_instances/Instance_Template/conf/Catalina/localhost/ROOT.xml {}
rsync -a -e “ssh gateway.remotenet.org ssh server.remotenet.org” :/logs /sync/logs
That is all.
sshfs is wickedly handy for mounting remote directories on your local filesystem. Recently I needed to mount the /logs directory off a remote server so a program on my workstation could process log files in /logs.
The textbook command to do that would be:
[me@workstation]$ sshfs server.remotenet.org:/logs /mnt/svrlogs
The tricky part in this particular case is that the server is on a private network so my workstation can not directly access it. I’m required to first ssh to a gateway machine and then ssh to the server.
---------------- ------------- ------------- |workstation | | | | server | | | --------------| gateway | ------- | | |/mnt/svrlogs | | | | /logs | ---------------- ------------- -------------
I found three ways to work with this scenario. I’d love to hear of more ways and get feedback on these.
