Results for category "Active Directory / LDAP"

20 Articles

TeamCity: Make the NuGet repository available without authentication

Task for today was making the NuGet repository of TeamCity available in our local network. Sounds easier as it was as our TeamCity instance is available from the Internet but you can only access the rontend with valid domain credentials (LDAP/Active Directory authentication). Enabling the guest account feature in TeamCity would have mean a small security break in our concept.

Here is the success-story how to enable the NuGet repository for local accesss without authentication and without enabling the TeamCity guest account:

Creating a new proxy instance

One of our Apache servers got the order to act as reverse proxy for the NuGet repository. The reverse proxy was running inside an own virtual host (nuget.mydomain.local) and was registered in our local DNS.
The configuration looked like this:


<VirtualHost *:443>
 SSLEngine on
 SSLProxyEngine on

ServerAdmin admin@mydomain.local
 ServerName nuget.mydomain.local
 ServerAlias nuget.mydomain.de

LogLevel warn
 ErrorLog logs/nuget.mydomain.local-error_log
 CustomLog logs/nuget.mydomain.local-access_log combined

# Map other source to FeedService URL
ProxyPass / https://teamcity.mydomain.local:443/guestAuth/app/nuget/v1/FeedService.svc/
ProxyPassReverse / https://teamcity.mydomain.local:443/guestAuth/app/nuget/v1/FeedService.svc/

</VirtualHost>

Adding a domain proxy user

With the configuration above we still have the problem that there is no user who can access the repository without credentials. So we need to add a domain user, let me call it teamcity-nugetfeed-proxy-user. For security reasons this account has a very long random generated password and is only used for providing the NuGet feed.

Using the domain proxy user in our Apache configuration

We have to add a Basic Authorization header in our Apache configuration so that every access between the proxy and TeamCity is authenticated.


RequestHeader set Authorization "Basic <Base64(teamcity-nugetfeed-proxy-user:$password)>"

The phrase <Base64(teamcity-nugetfeed-proxy-user:$password)> must be replaced by an base64-encoded string with format $username:$password.

After restarting the Apache you should be able to use the NuGet stream in Visual Studio. Look at the Apache logs for occuring errors.

TeamCity is failing – NuGet return “File contains corrupted data”

Till yet you are able read the stream but TeamCity will fail downloading your repository files. The reason is easy: The FeedService.svc returns an XML file which contains absolute pathes mapping to teamcity.mydomain.local and not nuget.mydomain.local. So again we have no authorization and the error File contains corrupted data occurs because of the TeamCity login dialogue.

We have to rewrite the content of the FeedService.svc replacing every occurence of teamcity.mydomain… with nuget.mydomain…
At first I tried mod_proxy_html but in the end using mod_substitute was the only solution that worked.


# Rewrite FeedService URL
 Substitute "s|https://teamcity.mydomain.local/guestAuth/app/nuget/v1/FeedService.svc|https://nuget.mydomain.local|i"
# Rewrite repository access
Substitute "s|https://teamcity.mydomain.local/guestAuth/repository|https://nuget.mydomain.local/repository|i"

# Execute every substitution only for XML/HTML
 AddOutputFilterByType SUBSTITUTE text/html
 AddOutputFilterByType SUBSTITUTE text/xml
 AddOutputFilterByType SUBSTITUTE application/atom+xml

# Map local repository path to remote repository
 ProxyPass /repository https://teamcity.mydomain.local:443/guestAuth/repository
 ProxyPassReverse /repository https://teamcity.mydomain.local:443/guestAuth/repository

# Unset gziped accepted encoding
RequestHeader unset Accept-Encoding

After restarting everything should work fine.

The complete configuration is now


<VirtualHost *:443>
 SSLEngine on
 SSLProxyEngine on

ServerAdmin admin@mydomain.local
 ServerName nuget.mydomain.local
 ServerAlias nuget.mydomain.de

LogLevel warn
 ErrorLog logs/nuget.mydomain.local-error_log
 CustomLog logs/nuget.mydomain.local-access_log combined

# Rewrite FeedService URL
 Substitute "s|https://teamcity.mydomain.local/guestAuth/app/nuget/v1/FeedService.svc|https://nuget.mydomain.local|i"
 # Rewrite repository access
 Substitute "s|https://teamcity.mydomain.local/guestAuth/repository|https://nuget.mydomain.local/repository|i"

# Map local repository path to remote repository
 ProxyPass /repository https://teamcity.mydomain.local:443/guestAuth/repository
 ProxyPassReverse /repository https://teamcity.mydomain.local:443/guestAuth/repository
 # Map other source to FeedService URL
 ProxyPass / https://teamcity.mydomain.local:443/guestAuth/app/nuget/v1/FeedService.svc/
 ProxyPassReverse / https://teamcity.mydomain.local:443/guestAuth/app/nuget/v1/FeedService.svc/

# Execute every substitution only for XML/HTML
 AddOutputFilterByType SUBSTITUTE text/html
 AddOutputFilterByType SUBSTITUTE text/xml
 AddOutputFilterByType SUBSTITUTE application/atom+xml

RequestHeader set Authorization "Basic <Base64(teamcity-nugetfeed-proxy-user:$password)>"

 # Unset gziped accepted encoding
 RequestHeader unset Accept-Encoding
</VirtualHost>

Windows Server 2003 as a central Git repository with Apache 2.2

After some years of working with (and fighting against) Subversion I decided to setup a Git repository for our company. Every developer should decide on their own what Version Control System he wants to use.

Jeremy Skinner wrote an excellent article about hosting a Git repository on Windows which was really helpful. Nevertheless I had to do some customizing.

Using ScriptAliasMatch

This drove me crazy: ScriptAliasMatch seemed to work, but the parameter (the repository argument) was not passed to git-http-backend.exe. Instead of this, I saw that Apache/httpd.exe tried to open c:/program files/git/libexec/git-core/git-http-backend.exe/repositoryname.

Solution: You must enable mod_cgi, otherwise the path argument “…exe/$1” can not be resolved.

Using Apache 2.2 + SSL

The git client failed to connect with the virtual host which was secured with SSLv3. I received the error message “error:140920DF:SSL routines:SSL3_GET_SERVER_HELLO:parse tlsext“. Anders Brownworth had this problem too, but I fixed it by disabling SSLv3 – which was at least acceptable in our environment. Use this line in your ssl.conf:

SSLProtocol +SSLv2 +SSLv3

Using a network share as repository

Our Subversion and Git repositories are stored on a network share, primarily for backup reasons. The path of the network share must be entered as “\\srv\share” – the doublequotes are important!
We are using the direct network share path and not a network drive, because after a restart of the machine containing the network share, the network drive will be unavailable. Windows marks it as offline and you can not use it longer until you restart the machine or reconnect the network drive manually. Accessing the network share via full UNC path will work as soon as the share is available again.

Running Apache on Windows 7 / Windows Server 2008

I tested the Git environment on Windows 7 (German) machine, and ran into the problem that the git-http-backend.exe could not be found. My fault was that I used “c:/Programme/Git/libexec/git-core/git-http-backend.exe” and notc:/Program Files“. Apache seems not be able to access the junction “c:/Programme“.

If you are running a x64 operating system, you must use c:/Program Files (x86)/Git/libexec/git-core/git-http-backend.exe.

Error “Client denied by server configuration”

Receiving the error “Client denied by server configuration” while setting up Git means in most cases that the access to the Git directory is denied. Take a look at the Apache Wiki and change your Order directives.

Running Apache under a special service account

If you want to run Apache under a special network service account (e.g. webserver@yourdomain.local), you have to keep this in mind.
The service account must have full access to your network share (\srvshare) and the repositories inside of it. Otherwise you will receive errors inside your Apache log like “error: insufficient permission for adding an object to repository database ./objects“.

Using Active Directory authentication/authorization for your Git repository

Authentication and authorization against the Active Directory/LDAP can be easily done with mod_authnz_ldap (mod_ldap prior to Apache 2.2.x):


	SetEnv GIT_PROJECT_ROOT "\\srv\git_repos"
	SetEnv GIT_HTTP_EXPORT_ALL
	ScriptAliasMatch "(?x)^/git/(.*/(HEAD | info/refs | objects/(info/[^/]+ | [0-9a-f]{2}/[0-9a-f]{38} | pack/pack-[0-9a-f]{40}.(pack|idx)) | git-(upload|receive)-pack))$" "c:/program files/git/libexec/git-core/git-http-backend.exe/$1"

	AuthType Basic
	AuthName "LDAP"
	AuthBasicProvider "ldap"
	AuthzLDAPAuthoritative Off
	require valid-user
	require ldap-group CN=security group,OU=your security group container,DC=domain,DC=local

All bare Git repositories inside of \srvgit_repos are available to http://webserver/git/. Every repository access will be authenticated and authorized against the given ldap-group. Authenticated read-only access can be done with LimitExcept directives.
Please note, that the centryl Git repository on your share must have the “sharedRepository = true” option. The option http.receive-pack is not needed, because every access is already authenticated through mod_authnz_ldap.

A working example without Active Directory authentication

<Directory />
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

<Directory "C:/srv/document_root">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

<Directory "c:/Program Files (x86)/git/libexec/git-core/">
    Order allow,deny
    Allow from all
</Directory>

SetEnv GIT_PROJECT_ROOT "C:/repos_git"
SetEnv GIT_HTTP_EXPORT_ALL

# Using x64 operating system
ScriptAliasMatch "(?x)^/git/(.*/(HEAD | info/refs | objects/(info/[^/]+ | [0-9a-f]{2}/[0-9a-f]{38} | pack/pack-[0-9a-f]{40}.(pack|idx)) | git-(upload|receive)-pack))$" "c:/Program Files (x86)/git/libexec/git-core/git-http-backend.exe/$1"

Global-Bind-User Patch für mod_auth_ldap (Apache 2.0.63) und mod_authnz_ldap (Apache 2.2.18) veröffentlicht

Heute habe ich es endlich geschafft, den Patch für mod_auth_ldap (Apache 2.0.63) und mod_authnz_ldap (Apache 2.2.18) auf Github zu veröffentlichen. Die Version für mod_auth_ldap hatte ich bereits vor zwei Jahren fertig gestellt, aber nie öffentlich zugänglich gemacht. Stattdessen schlummerte Kompilat und Sourcen in unserem Unternehmens-Repository.

Der Patch stellt drei Einstellungen für die Apache-Konfiguration zur Verfügung, die als Default für alle Verzeichnis-Absicherungen über mod_auth_ldap gelten. Damit spart man sich bei komplexen Konfigurationen jede Menge doppelten Code, z.B. wenn man viele Ordner hat, deren Zugriff auf immer verschiedene Active Directory-Gruppen eingeschränkt ist.

Da ich heute Ablenkung von Java brauchte, habe ich den alten Quellcode auf Apache 2.2.18 portiert. Dabei ist mir dann auch folgendes im Zusammenspiel mit der Kompilierung unter Visual Studio 2008 aufgefallen: Ich hatte die Apache.dsw geöffnet, den Patch eingespielt und dann versucht Das Projekt mod_authnz_ldap zu kompilieren. Allerdings brach die Kompilierung immer mit einem “rc.exe meldete Fehler 1” ab.
Nach kurzem Überprüfen der Log-Dateien stellte ich fest, dass die Präprozessordefinitionen für alle notwendigen Projekte (libhttpd, mod_ldap und mod_authnz_ldap) so nicht unterstützt werden. In den Definitionen steht z.B. BIN_NAME=”mod_authnz_ldap.so”, was allerdings auf der Kommandozeile zu … rc.exe /d “BIN_NAME=””mod_authnz_ldap.so”” … wird. Das Quoting ist also falsch. Deshalb musste ich alle Vorkommen der doppelten Anführungszeichen durch einfache Anführungszeichen innerhalb der Projekteigenschaften (Ressourcen > Allgemein > Präprozessordefinition) ersetzen. Danach funktionierte auch die Kompilierung.

Im Github-Repository des Patches liegen neben dem eigentlichen Patch auch die fertig kompilierten Module für Windows bereit, so dass man diese sofort nutzen kann.

Update 2012-01-19: In Version 2.2.21 ist der Fehler immer noch vorhanden.

Additional property page sheet in Active Directory User and Computer MMC

Some time ago I developed ADUaCET, an extension for the Active Directory User and Computer MMC snap-in. Sad to say but the ADUaCET property page is not shown if you are searching for an user. It is only available if you use the procedure right click $USER -> Properties. I struggled the whole day with collecting information about this issue.

My results are the following:

  • It is not possible to use .NET and only Microsoft.Management.Advanced.PropertySheetExtension for having the property page tab after doing an Active Directory search.
  • Active Directory User and Computer MMC delegates the search to dsquery.dll, OpenQueryWindow. OpenQueryWindow uses an out pointer to pass back the Active Directory entries which were found by search query.
  • All default property pages (Member of, Sessions, Organization etc.) are included by MMC as COM objects.
  • All COM objects to be included in the User property page are stored in the Active Directory schema in CN=adminPropertyPages,CN=user-Display,CN=40[7|9],CN=DisplaySpecifiers,CN=Configuration,DC=yourdomain,DC=local. You can use ADSIEdit to change the used COM objects.
  • adminPropertyPages contains 10 GUIDs by default which are references to the registered COM objects. For example %systemroot%system32adprop.dll (GUID {6DFE6488-A212-11D0-BCD5-00C04FD8D5B6}) is one of them.
  • For determining which COM DLLs are used take an entry from adminPropertyPages and search your registry below HKLMSOFTWAREClassesCLSID$GUIDInProcServer32
  • A good example for registrating a new property page sheet COM object can be found at Yusufs.Directory.Blog (German).
  • Microsoft has two pages about Implement the Property Page COM Object and Registering the Property Page COM Object
  • codeproject.com has an example project which is based on .NET/C#. The example publishes a new property page sheet as COM object. Really helpful!

Convert Active Directory schema to XML or JSON

As I mentioned yesterday, Christoph is currently developing the Active Directory Integration WordPress plugin. Today we were talking about the write back of WordPress profile settings to Active Directory. I mentioned it would be helpful to have an abstract definition of available Active Directory attributes which can be dynamically integrated into WordPress.

Suggest that you can select wished Active Directory attributes in WordPress from a list and Active Directory Integration will automatically generate the designated input fields or disable the field if write back is not allowed (e.g. for login time). All information are already existent in Active Directory namely stored in Active Directory Schema Configuration.

Because I had to take a break from preparing my next math exam I fired up Notepad++ and did a quick hack in PHP. The converter transforms a given LDIF input file into XML or JSON which then can be used as template for systems using Active Directory attributes.

How to give users the permission to change their own Active Directory attributes/profile

Christoph was implementing a function into Active Directory Integration (ADI) (a WordPress plugin for Active Directory authentication and authorization) called Sync Back. With this function WordPress users are able to write back their WordPress profile to their Active Directory account.

A problem that occured was that by default Active Directory users belonging to security principal Domain Users are only allowed to read but not to write their own attributes. Christoph implemented a WordPress setting which uses a global Active Directory user who has write permissions to every account – this user (setting is called Global Sync User in ADI) belonged to the security group Domain Adminstrators. You have security considerations? I had.

After a few minutes we modified the security settings in the Active Directory schema so that users are able to change their own Active Directory profile / attributes.

The steps are easy:

  • Start ADSIEdit.msc as a user belonging to security group Domain-Administrators, e.g.
    runas /user:administrator@your-domain.local "adsiedit.msc"
    
  • Connect to your Domain Controller and navigate to the organization unit of your choice in which the users are allowed to change their profile, right click on the OU (e.g. OU=Power User) and select Properties.
  • Select the tab Security and scroll down to the security principal SELF. If it does not exist (which is the default for OUs but not for CNs) click on Add and type SELF into to object name text field.
  • Select SELF and grant the Write permission.

Some remarks:

  • You can grant the Write permission to OUs or CNs. If you grant it to a OU every user below the OU can change their own attributes but not the attributes of other users in the same OU. SELF will be automatically replaced by Active Directory security mechanism by the current logged on user.
  • Users with Write permission can change every own user attribute in Active Directory Users and Computers MMC except for Account supports Kerberos AES-*-Bit encryption and the Member of tab.

Windows 2003 als zentraler Event Log-Server / Freigeben von Event Logs an bestimmte Benutzer

Florian hatte vor einigen Wochen das Tool eventcreatef vorgestellt.  Es dient dazu, dass komplette Log-Dateien und nicht nur einzelne Log-Nachrichten in die Ereignisanzeige von Windows geschrieben werden können. eventcreatef delegiert die Aufrufe an das Microsoft-Tool eventcreate, dass die übergebenen Daten in kleinere Teile an den jeweiligen Server sendet.

Somit kann man mit Hilfe von eventcreatef einen zentralen Log-Server auf Basis von Windows Server 2003 o.ä. aufsetzen, der alle Log-Dateien sammelt, z.B. die, die während eines nächtlichen Backups auftreten.

Leider gibt es für Linux kein Tool, dass direkt in die Ereignisanzeige von Windows Server 2003 schreiben kann. Für unsere heterogene Umgebung war dies ein ungünstiger Sachverhalt. Ich musste also einen generischen Service schreiben, der per SOAP die Log-Daten entgegen nehmen konnte und dann dementsprechend an eventcreatef weiterdelegiert.

Dabei ist das unten angehängte Script namens eventcreateservice.php (ECS)heraus gekommen: Es stellt über das Zend Framework eine SOAP-Schnittstelle bereit, die die einfache Methode create besitzt. Wird das Script über eventcreateservice.php?wsdl aufgerufen, wird die WSDL-Datei ausgegeben, über eventcreateservice.php?bash lässt sich ein Bash-Script downloaden, dass mit Hilfe von curl eine Verbindung mit dem SOAP-Service herstellt. An dem Bash-Script muss nichts weiter angepasst werden, da die URLs automatisch generiert werden. Somit lassen sich nativ auf Linux-Maschinen Einträge in die (native) Ereignisanzeige von Windows-basierten Maschinen schreiben.
Ein Syslog-Server ist also nicht mehr nötig. Das Konzept ist besonders für kleinere Unternehmen interessant, die mehr Windows-Maschinen als Linux-Maschinen besitzen und für die ein zentraler Syslog-Server oversized ist.

Nachdem ich ECS fertig entwickelt hatte, ging es nun darum, dass ich die von mir erstellten Log-Einträge nicht in den Standard-Log-Dateien Applikation, System und Sicherheit schreiben wollte, sondern in eine Extra-Logdatei namens Backups.
Florian stellt in der oben bereits genannten URL ein kleines Tool namens CreateEventLog2 bereit. Über die Aufmachung und Fehlerbehandlung der GUI lässt sich streiten, mir ging es um den Funktionsumfang: CreateEventLog2 erzeugt eine neue Log-Datei, die dann in der Ereignsanzeige der MMC angezeigt werden kann.
Damit hatte ich schon ein Großteil erreicht: Ich konnte nun von Windows-Systemen aus Log-Nachrichten auf unserem Log-Server speichern, die Linux-Systeme konnten über das Bash-Script und den SOAP-Service ebenfalls in die Windows-Ereignisanzeige schreiben und schließlich hatte ich ein weiteres Log neben den Standard-Windows-Logs.

Im letzten Schritt ging es nun darum, das von mir definierte Log einem dedizierten Benutzer zugänglich zu machen. Ich wollte in der Konfigurationsdatei von ECS (logischerschweise) keinen Domänen-Administratoraccount eintragen, sondern einen Benutzer mit beschränkten Rechten. Für dieses Vorhaben muss man zuerst einmal ein paar Sachen wissen: Der Zugriff auf die Log-Dateien eines Systems werden über Registry-Einträge geregelt. Es gibt unter HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLog zu jeder Log-Datei einen Schlüssel, der wiederum diverse Attribute enthält. Wichtig ist das Attribut CustomSD: dieses beschreibt anhand eines SDDLs, ob und wer auf dieses Objekt zugreifen darf. Standardmäßig steht in der CustomSD (in meinem Fall zu finden unter HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLogBackupsCustomSD) ein String der folgenden Art: O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3). Sieht kryptisch aus, ist es aber eigentlich nicht – wenn man weiß, wie die SDDLs aufgebaut sind.
Kurz dazu: Jeder eingeklammerte Eintrag, z.B. (D;;0xf0007;;;AN) definiert eine Zugriffsregel (ACE). Die erste Regel, die vom System gefunden wird und zutrifft, wird benutzt.

Wie dem auch sei: Es gibt glücklicherweise ein Tool namens sddlparse, das die zugegebenermaßen etwas kryptisch anmutende Zeichenkette analysiert und dann wieder in lesbarer Form ausspuckt.
Nachdem ich damit die benötigten Rechte für einen schreibenden Zugriff auf die Ereignisanzeige auslesen konnte (ADS_RIGHT_DELETE, ADS_RIGHT_READ_CONTROL, ADS_RIGHT_WRITE_DAC, ADS_RIGHT_WRITE_OWNER, ADS_RIGHT_DS_CREATE_CHILD, ADS_RIGHT_DS_DELETE_CHILD und ADS_RIGHT_ACTRL_DS_LIST), erstellte ich einen neuen ACE mit eben diesen Rechten. Die ACE muss an erster Stelle eingefügt werden, so dass der Registry Key wie folgt aussieht: O:BAG:SYD:(A;;LCDCCCWOWDSDRC;;;S-1-5-21-xxx-xxx-xxx-xxx)(nächste ACE…). Der Registry Key wird übrigens bei jedem Aufruf der Ereignisanzeige ausgelesen, somit tritt die Änderung sofort in Kraft.
Ich fügte die SID unseres dedizierten Ereignisanzeigen-Benutzer mit Hilfe der obigen ACE hinzu und war in der Lage mit diesem in die Ereignisanzeige zu schreiben.

Während ich mich in SDDLs und ACEs einarbeitete, fiel auch ein kleineres Tool namens ACECreator ab. Es verbindet sich mit dem Active Directory und sucht mit Hilfe von Ambigious Name Resolution (ANR) Objekte heraus. Diesen Objekten lassen sich dann die Einstellungen verpassen, die man braucht, das passende ACE wird automatisch erzeugt.

Alles in allem war dieses Projekt äußerst spannend. Zwar klingt die Durchführung relativ einfach, allerdings gab einige Probleme mit den Rechten bzw. Benutzeraccount, unter dem eventcreatef lief u.s.w.
Lesenswert sind folgende Links, die ich u.a. für den ACECreator als Referenz herangezogen habe:

Angehängte Downloads
[download id=5]
[download id=6]

Rautiges 2009-09-01

Durch das Konzert und Projekte in der Firma bin ich immer noch im Stress, deshalb hier mal wieder etwas Rautiges.

  • Am Freitag den 4. September hat unsere Band – die Rhythmutants – unseren ersten Auftritt. Mittlerweile läuft auch alles so, wie es soll. Ich bin stark gespannt, wie das Konzert dann ablaufen wird. Die Woche ist noch geprägt von jeder Menge Bandproben.
    Den letzten Samstag hat die Band + Support-Crew bis spät in die Nacht geprobt und Party gemacht. War sehr lustig – aber auch anstrengend.
  • Für mod_auth_ldap habe in der vergangenen Woche einen Patch geschrieben, mit dessen Hilfe es möglich ist, für einen (virtuellen) Server einmalig die LDAP-Verbindungseinstellungen zu setzen, die dann für den kompletten (virtuellen) Server gelten. Mich hat es mehr als angepestet, dass ich für jede Ressource die Zugangsdaten (AuthLDAPBindDN, AuthLDAPBindPassword und AuthLDAPURL) immer wieder setzen musste. Nun existieren die Parameter AuthLDAPGlobalURL, AuthLDAPGlobalBindDN und AuthLDAPBindPassword.
  • Unser Haus-internes Kicker-Team, bestehend aus Christoph, Marc, Florian, Mandy, Hendrik und mir, hat am vergangenen Donnerstag den ersten Platz beim 1. IT-Region 38 Kicker-Cups belegt. Es war ein äußerst spannender und unterhaltsamer Abend, den unser ECW-Badabäääm-Team erfolgreich abschließen konnte. Fotos vom Turnier gibt es bei der IT Region 38, Christoph hat weiterhin noch ein kurzes Interview gegeben.
    Nach dem Turnier haben Marc und ich am Klieversberg noch bis in die frühen Morgenstunden unseren grandiosen Sieg gefeiert.
  • Beim Studium habe ich heute den Abschlusstest für Rechnerstrukturen und Betriebssysteme abgelegt – und überraschend nicht bestanden. 2 der Tests wurden meiner Meinung nach vom System falsch ausgewertet, obwohl sie offensichtlich richtig waren, denn es mussten nur die Lösungen aus dem Buch abgeschrieben werden. Ich habe Bianca über diesen Missstand informiert und hoffe auf eine baldige Antwort – mein Tutor ist leider noch bis zum 6. September im Urlaub, so dass mir der richtige Ansprechpartner momentan nicht zur Seite steht. Ist alles sehr ärgerlich.
  • Die Migration unserer virtuellen Maschinen auf den Xen-Server haben wir erfolgreich hinter uns gebracht, auch wenn es einige Probleme gab. Nun läuft aber wieder alles. Damit steht – sobald es Zeittechnisch machbar ist – der Einführung eines Build-Servers nichts mehr im Wege. Erste Tests mit CruiseControl und unserem Deployment-Tool habe in der letzten Woche bereits gemacht.
    Sobald die komplette Infrastruktur steht, werde ich dazu einen ausführlichen Artikel schreiben.
  • Heute ist das erste Treffen zur bevorstehenden Ruderregatta am 12. und  13. September am Allersee. Ich bin sicher, dass die Ruderregatta wie jedes Jahr eine Mordsgaudi wird 😉

How-To: Module des Apache Webservers unter Windows mit Visual Studio kompilieren und debuggen

Aus aktuellem Anlass musste ich mal wieder ein Apache-Modul gerade biegen. Diesmal war es mod_auth_ldap. mod_auth_ldap sollte als Modul zur Authentifizierung und Autorisierung von LDAP-Benutzern (Active Directory, eDirectory, OpenLDAP etc.) vielen Leuten ein Begriff sein.

Diese Anleitung zeigt in wenigen Schritten, wie man aus den Sourcen des Apache Webserver 2.0.63 ein Modul patcht, kompiliert und debuggt. Voraussetzung für die Kompilierung ist ein Visual Studio Express bzw. Visual C++. Ich verwende auf meinem Rechner ein (relativ altes) Visual Studio 2005 Professional.

Auf meinem Arbeitsrechner schaut es so aus, dass ich unter c:ckldevsrvwebapache2.0.63 ($DIR_BIN) die installierte und kompilierte Version des Apache Webservers habe und unter c:ckldevprojectsappapache2.0.63 ($DIR_SRC) die zugehörigen Sourcen liegen.

Zuerst müssen von apache.org die aktuellen Sourcen für Windows heruntergeladen und auf der Festplatte ($DIR_SRC) entpackt werden. Wenn man zusätzlich noch durch die Sourcen des Apache Webservers debuggen will, werden weiterhin die Symbols benötigt. Diese müssen in das Hauptverzeichnis des kompilierten Apache Webservers ($DIR_BIN) entpackt werden.

Die Datei $DIR_SRCApache.dsw enthält alle Teilprojekte des Webservers und muss mit Visual Studio geöffnet werden. Falls beim Öffnen die Frage nach einer Konvertierung der Daten kommt, kann/muss dies mit Ja beantwortet werden.

Ausgehend davon, dass wir nur mod_auth_ldap patchen wollen, muss nun im Solutions Explorer das Teilprojekt mod_auth_ldap ausgewählt und die jeweiligen Änderungen in die mod_auth_ldap.c eingetragen werden. Mit einem Rechtsklick auf mod_auth_ldap > Build wird nun das Modul erstellt. Die .so-Datei lässt sich jetzt unter $DIR_SRCmodulesexperimental[Debug|Release]mod_auth_ldap.so ($MOD_AL) finden. Weiterhin ist die $DIR_SRCmodulesexperimentalDebugmod_auth_ldap.pdb ($DEBUG_AL) wichtig.

Der Apache muss nun als Dienst beendet werden (net stop apache2), danach muss $MOD_AL und $DEBUG_AL nach $DIR_BINmodules kopiert (vorher Sicherung des Originals erstellen!) und Apache auf der Kommandozeile ($DIR_BINbinapache.exe) gestartet werden. Dies ist nötig, damit Visual Studio sich an den Apache-Prozess hängen kann. Wird der Apache als Dienst ausgeführt, ist dies nicht ohne Weiteres möglich.

Sobald der Webserver läuft, kann im Visual Studio unter Debug > Attach to Process die Apache-Prozesse ausgewählt werden. Beim Hit eines Breakpoints in der mod_auth_ldap.c stoppt der Apache die Ausführung.

Hier die Hinweise im Überblick:

  • $DIR_SRCApache.dsw als Projekt öffnen und nicht $DIR_SRCmodulesexperimentalmod_auth_ldap.dsw, da man bei letzterem zu viele Einstellungen ändern muss.
  • Apache.exe als normalen Prozess und nicht als Dienst starten, da sich sonst der Debugger nicht nutzen lässt.
  • Neben der .so-Datei muss auch die zugehörige .pdb-Datei in $DIR_BINmodules kopiert werden.

Rautiges 2009-07-14

Momentan vertreibe ich mir die Zeit mit der Konfiguration des Zotac ION Boards, deshalb hier eine kurze Übersicht über die letzte Woche

  • Empfehlenswerte Websites sind www.faql.de (behandelt Themen zur deutschen Sprache, unter anderem wird erklärt, dass es das Wort “Stati” als Plural von “Status” nicht existiert) und www.encyclopediadramatica.com (über Alltags-Internetsprache).
  • Florian kämpft momentan mit der Konfiguration von MPD und Icecast2. Wir (und andere) haben das Problem, dass mit WinAMP und VLC der OGG-Stream nach Ende eines Tracks oder Wechsel während des Abspielens eines Tracks der komplette Stream abbricht. Sehr ominöses Problem, Foren-Threads deuten darauf hin, dass mit dem Wechsel der OGG-Header zu tun hat.
  • Ich habe die Woche einen Patch für vboxtool eingereicht, so dass die richtigen Maschinen gestartet werden, falls der Benutzer, der vboxtool aufruft, nicht identisch ist, mit dem ggw. Benutzer. Mehr Infos dazu gibt es im Firmen-Entwickler-Blog.
  • Im Trac von VirtualBox habe ich außerdem einen Bug-Eintrag hinterlassen, da bei mir hin und wieder die  SSH-Netzwerkverbindung abbricht.
  • Auf ganzer Linie kämpfe ich mit dem Zotac ION-Board:
    • Die Auflösung auf meinem Fernseher wird falsch dargestellt. Es gibt unsichtbare Bereiche oberhalb und unterhalb des sichtbaren Bereichs. Das Panning funktioniert nicht, ebenso diverse X-Konfigurationseinstellungen. Meine Vermutung ist, dass das DVI-Signal vom HDMI-Eingang des Fernsehers falsch interpretiert wird.
    • Bei Windows Server 2003, das in einer VirtualBox-VM ist,  lassen sich keine Rollen mehr hinzufügen. Gestern wollte ich WINS und DHCP nachinstallieren – dies schlug aber aus unerfindlichen Gründen fehl. Ich habe mir die Install-Logs unter c:windowsdebug angeschaut, konnte aber nicht wirklich die Fehlerursache zu identifizieren. Es läuft wohl darauf hinaus, dass ich Windows Server 2003 neu installieren muss.
    • Winbind und Samba laufen noch nicht rund. Die Authentifizierung von Winbind am Active Directory über Kerberos funktioniert hingegen schon.
    • Audio-Ausgabe über HDMI, Video-Beschleunigung etc. konnte ich noch nicht testen, da o.g. Punkte erst einmal zu fixen sind.