ITSA Consulting, LLC

Packt Publishing has sent me a copy of Instant Chef Starter, by John Ewart to review. I should have this review up within the week.

This is a great opportunity as one of the most important tools that any system administrator can learn is configuration management, and Chef is a leader in that space. Chef is unique in that it integrates with major cloud providers and allows management from provisioning to deletion of the virtual server behind the service.

I have had to setup Apache to proxy splunk several times over the past 6 months and keep forgetting the splunk configuration to make this work.

Be sure to set the following in /opt/splunk/etc/system/local/web.conf:

enableSplunkWebSSL = 0
root_endpoint = /splunk
tools.proxy.on = True

This assumes a proxy configuration of the following for apache 2.2:

ProxyPass /splunk http://localhost:8000/splunk
ProxyPassReverse /splunk http://localhost:8000/splunk

Be sure to secure your proxy before enabling!

Restart splunk:

/opt/splunk/bin/splunk stop
/opt/splunk/bin/splunk start

I recently made a mistake and committed an ISO file to git that was 2GB in size. I did not immediately notice this issue and made several local commits without a push to github working properly. I did some research and figured out how to fix this problem.

Note that this might not be a good idea if you’ve successfully pushed to your remote repository and share it with othes.

1. Remove the file from each commit with git filter-branch:

git filter-branch -f --tree-filter 'rm -f $FILENAME' HEAD

2. Remove the references:

git reflog expire --expire=now --all

3. Run garbage collection:

git gc --aggressive --prune=now

That worked for me. Let me know if you have a similar experience at: linux (at) itsecureadmin (dot) com.

I recentlyr an into an issue when setting up a new LDAP directory using OpenLDAP 2.4.23 on Mac OSX. The issue was that I would get the following error when attempting to modify any entry in the directory:

modifying entry "olcDatabase={1}bdb,cn=config"
ldap_modify: Server is unwilling to perform (53)
        additional info: shadow context; no update referral

A few web searches for this error indicated that it might be bad credentials or that the server was setup as a replication consumer which would forced a read only state. I had dumped the directory from another server where it was a MMR member and thought I had removed the required parts to make it work here (olcSyncRepl, olcServerID, etc..).

I confirmed that the credentials were correct by issuing a search using the credentials used in my attempt to modify the directory.

The problem was that I had the oldMirrorMode directive set to FALSE. The fix was to remove this from the LDIF that I was importing with slapadd and re-import.

Note that you could alternately modify olcMirrorMode and set it to TRUE which should resolve this scenario if you are running MMR and require the olcSyncRepl directives.

Command line network configuration for the MAC is quite a bit different when compared to Linux or Unix. The networksetup command is used instead of ifconfig to configure devices.

The first step is to get a list of all network services – these are really physical and virtual devices, VPNs, etc..

networksetup -listallnetworkservices

The next step is to get the current settings for the network service that you might want to configure – the following example is using the service “Ethernet” and is enclosed in quotes as some of the services have spaces in the names:

networksetup -getinfo "Ethernet"

To configure an interface manually, use something like the following:

networksetup -setmanual "Ethernet" 192.168.1.10 255.255.255.0 192.168.1.1

Confirm that the settings are correct by issuing the getinfo command once more:

networksetup -getinfo "Ethernet"

One common task that any system administrator will perform is to add a new user to a system or application. I recently had a need to add a new user to a MAC server over an SSH connection and found it much more difficult than it should have been. I ended up writing a script to perform the task.

The script located here will create a new user, add them to the admin and staff groups, make their primary group id staff (gid 20) and be sure their userid is the next available one, as well as creating the default home directory based on the English.lproj template.

Let me know how it works for you.

I recently had an issue with a customer where I needed to enable remote screen sharing (VNC) on a MAC OSX server from an SSH terminal.

Thanks to this post, I was able to get it started up with this command.

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -restart -agent -privs -all

To connect from a MAC client, open Finder, Go, Connect to Server, and type something like the following:

vnc://x.x.x.x

A common question or issue that I’ve noted when helping customers when using nginx with daemontools is a flood of messages to the error log relating to a failure to bind on port 80 (or whichever port is configured) like the following:

==> logs/error.log <==
2012/09/24 17:41:48 [emerg] 27628#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:49 [emerg] 27637#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:50 [emerg] 27646#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:51 [emerg] 27657#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:52 [emerg] 27671#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:53 [emerg] 27680#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:54 [emerg] 27689#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:55 [emerg] 27699#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:56 [emerg] 27708#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/09/24 17:41:57 [emerg] 27725#0: bind() to 0.0.0.0:80 failed (98: Address already in use)

This is caused by daemontools starting nginx successfully, and then nginx daemonizes, and then daemontools tries to start nginx again, unsuccessfully, logging an error to the log.

The solution to this problem is to disable daemon mode in the main section of the nginx.conf:

daemon off;

Once this addition to the configuration file is made, kill all nginx processes and allow daemontools to restart. The error should no longer be logged.

(Assuming nginx version 1.2.3 for this option.)