Well, it seems to be getting a “trend” for me, to integrate stuff into our Active Directory. Now that I know why, and how easy that is, I expect to add more stuff. The good thing about the integration is, that you only need to maintain a single source for authorization.
The bad thing about that is, that stuff becomes dependant on the Active Directory (we do have four domain controllers, so that should be fine).
Now, here’s the ssl-(only) apache2 configuration file for my vhost:
<VirtualHost *:80>
## mod_core
DocumentRoot "/usr/share/nagios"
ServerName nagios.barfoo.org
ServerAlias nagios3.barfoo.org
ServerAdmin nagiosadmin@barfoo.org
## mod_rewrite
RewriteEngine On
RewriteRule ^/(.*) https://nagios.barfoo.org/$1 [L,R]
</VirtualHost>
<VirtualHost *:443>
## mod_core
DocumentRoot "/usr/share/nagios"
ServerName nagios.barfoo.org
ServerAdmin nagiosadmin@barfoo.org
ScriptAlias /nagios/cgi-bin /usr/lib/nagios/cgi
Alias /nagios /usr/share/nagios
Alias /pnp /usr/share/nagios/html/pnp4nagios
<DirectoryMatch "/usr/(share/nagios|lib/nagios/cgi)">
AllowOverride None
Order deny,allow
Deny from all
Allow from 10.0.0.
Options None
# Authorization
AuthType Basic
AuthName "Nagios Barfoo"
# The authentification provider is mod_ldap
AuthBasicProvider ldap
# mod_ldap is our *only* authentification provider for this!
AuthzLDAPAuthoritative on
# Redirect the userfile requests to /dev/null
AuthUserFile /dev/null
# AD requires an authentication DN to access any records
AuthLDAPBindDN "BARFOO\\ldap_nagios"
AuthLDAPBindPassword "somethingrandom"
# The URL to search in
AuthLDAPURL "ldap://dc0.barfoo.org dc1.barfoo.org dc2.barfoo.org dc3.barfoo.org/OU=Users,dc=barfoo,dc=org?sAMAccountName?sub?(objectClass=*)"
# Search the group membership in the specified group, otherwise it's gonna
# get searched at the binding DN's location
AuthLDAPGroupAttributeIsDN on
Require ldap-group CN=gr_nagios,OU=Groups,DC=barfoo,DC=org
</DirectoryMatch>
## mod_log
ErrorLog /var/log/apache2/nagios.barfoo.org.error_log
TransferLog /var/log/apache2/nagios.barfoo.org.access_log
CustomLog /var/log/apache2/nagios.barfoo.org.ssl_request_log ssl_combined
## mod_ssl
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl.crt/nagios.barfoo.org.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/nagios.barfoo.org.key
<Files ~ "\.(cgi|shtml|phtml|php3|php?)$">
SSLOptions +StdEnvVars
</Files>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>As you can see, AuthLDAPUrl holds the four LDAP servers separated by spaces (that’s what the Apache2 documentation says about that), and that actually works.
The only additional thing I had to change from the nagios part is in /etc/nagios/cgi.cfg to allow everyone to issue system commands. Also, if you ever stumble upon extranous chars in the check_nrpe output, update to a newer NRPE version, that fixed it for me (that is on the receiver side - as in the box running the NRPE agent).
Tags:
Active Directory,
Nagios,
SLES10,
Work
Today I did something horrible. I yet again noticed that I bought the wrong CPU’s (basically I bought Xeon DP’s with four cores). Those have apparently a feature called SSSE3, which makes VMotion with our old Xeon DP’s (dual cores) fail before even trying.
But as we had a cooling outage today (basically ’cause it broke), I needed to turn off some ESX servers. Thus leaving me with the new ones and one of the old ones. *yuck*
So after a bit of googling, I found this VMware KB entry, which luckily lists the registers (on level 1) you need to zero out.
1
2
| ecx ---- ---- ---- -0-- ---- --0- ---0 -0--
edx ---- ---- ---- --0- ---- ---- ---- ---- |
Only problem after that was that it still wasn’t enough. So back to the drawing board. The final solution came rather quick and looks like this:
1
2
3
| eax ---- ---- ---- ---- ---- 0--0 ---- ----
ecx ---- ---- ---- -0-- ---- --0- ---0 -0--
edx ---- ---- ---- --0- ---- ---- ---- ---- |
The only stupid thing about this is, that
- it ain’t supported by VMware (as in if you’re having trouble with your ESX/VC and you have a VM running with this, you’re shit outta luck!)
- you have to define this on a *per VM basis*, which really is a pain in the ass for larger installations
True, I just should’ve bought VMotion compatible CPU’s, that would have spared me the hassle … but it’s too late now, I have to live with those ones.
Tags:
cpu mask,
VMotion,
VMware ESX,
VMware Infrastructure
Recently I got the task, to implement unixODBC/freetds on one (well, it’s really three) of our web servers, as someone wanted to use Microsoft SQL Server 2005 with PHP (without using the MSSQL functions, which PHP provides soo nicely; don’t ask me why).
With that I also got a set of “instructions” on how to install freetds from source (remember, I was a Gentoo dev, so I know my way around, when it comes to building from source), as well as a small set of instructions on how to create the connection.
Well, after trying to figure out why the hell the connection ain’t working with unixODBC’s tsql and PHP’s odbc functions, and yet the plain connection using telnet works … *shrug* turns out it was a simple mistake …
The “howto” said something like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| [FreeTDS]
Description = FreeTDS unixODBC Driver
Driver = /usr/lib64/libtdsodbc.so
Setup = /usr/lib64/libtdsodbc.so
[ODBC Data Sources]
mssql = Microsoft SQL Server 2005
[mssql]
Driver = /usr/lib64/libtdsodbc.so
Description = MSSQLServer
Trace = No
Database = Database
TraceFile = /var/log/freetdssql-foobar.log
Servername = sql.foobar.org
Port = 2433
TDS_Version = 8.0
[Default]
Driver = /usr/lib64/libtdsodbc.so |
While it should have been this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| [FreeTDS]
Description = FreeTDS unixODBC Driver
Driver = /usr/lib64/libtdsodbc.so
Setup = /usr/lib64/libtdsodbc.so
[ODBC Data Sources]
mssql = Microsoft SQL Server 2005
[mssql]
Driver = /usr/lib64/libtdsodbc.so
Description = MSSQLServer
Trace = No
Database = Database
TraceFile = /var/log/freetdssql-foobar.log
Server = sql.foobar.org
Port = 2433
TDS_Version = 8.0
[Default]
Driver = /usr/lib64/libtdsodbc.so |
See the difference ? If not, I’ll show you a diff:
1
2
3
4
5
6
7
8
9
10
| --- odbc.ini.orig
+++ odbc.ini
@@ -12,7 +12,7 @@
Trace = No
Database = Database
TraceFile = /var/log/freetdssql-foobar.log
-Servername = sql.barfoo.org
+Server = sql.barfoo.org
Port = 2433
TDS_Version = 8.0 |
Something as simple as adding another part of a word (as in “name“) to Server, makes the whole thing go wonko. Well, it ain’t going wonko per se, as Servername is different from the meaning of Server, at least when it comes to freetds.
Servername is the SQL-Server Instance name, while Server is the DNS name .. figures.
Tags:
freetds,
SLES10,
unixODBC,
Work