A million little bugs - hashcat dev

The past days were kind of a journey for me. I had installed a new storage backend at our hoster wich consists of two drbd-mirrored server with the openfiler distri. On major feature wich i evaluated previosly was quota support. But as usual things changed. Instead of normal quota support i faced the problem that i've to set quota remotely over an nfs share and as you can except openfiler doesn't support it by default. One alternative was to install some perl modules on the filers, but i didn't want to polute it so much.
So...i had to dig very deep in the rpath infrastructure to extract a few usefull lines at the end. The whole action took me 6 days, the first half to trace the problem down, 2.5 days for research, a few hours to make it but the major part of the last step was to get a appropriate testmachine.

!!! Caution !!!
Keep in mind that this is a 'hack'. If you use this, it's on you on your own risk.
If you update your installation, this changes may be overwritten and you will have to do this again.

In first place you have to setup a development environment, or in other words install exactly the same system in a local vm.

Then you have to install two dev packages:
conary update rmake conary-build

The cvc command should now be available, if not the python script is located under /usr/lib/python2.4/site-packages/conary

Now install the following packages, wich are requiered to build quota:
conary update binutils:devellib debugcedit:runtime e2fsprogs:devel elfutils:runtime gcc:devel gcc:devellib gcc:lib gcc:runtime gettext:runtime glibc:devel glibc:devellib libgcc:devellib patch:runtime tcp_wrappers:devel

If you got that, add a new user for the compile action or just give the user rmake a shell, su into the user and check out quota:
cvc checkout quota

Now open the recipe and add the following to configure: --enable-rpcsetquota=yes
Finally start the cooking:
cvc cook quota/quota.recipe

If no error appears you should get the build under: /srv/rmake/conary/builds/quota/

Test it and make your it has the -S option avaiable, then you can copy it to your production system.

The past days, i had been in struggle with the integration of the Reporting Services (SQL 2008) in Sharepoint 2007. I have setup a multi tier sharepoint environment with the spoken integration.
The first steps of the installation went as excepted. After the basic setup on two nodes, one for the SQL 2008, one for the MOSS 2007 (both on Windows Server 2008), i had to upgrade the SQL node to a web frontend of the sharepointfarm.
Everything was looking perfect at this time, then i had to install the Reporting Services Add-In on the Sharepoint node. The installation went through and at the and it told me that something bad happened. After hours of retrying and deep research if discovered the following error in the installation logfile (C:\Users\administrator.BGH\AppData\Local\Temp\RS_SP_??.log):
******* User does not have permission to add feature to site collection: http://sharepointserver1:3170

I had to dig very deep and at the end a mix of the following steps helped me trough:
- given rights to all kind of system users, since the setup only ran as user SYSTEM
- debugging the web.config of the central administration virtual host since there were error in the eventlog that some controls couldn't be loaded
- create a site collection (i have tried hours without one, since i had realised that the setup will add the feature in the created site collection when it has approriate rights, i was sure that there was a issue with privilegs)
- disable IE-autologon and log back in the central administration with an enterprise admin account
- install the cumulative update for SQL 2008 (http://support.microsoft.com/kb/956717)

Now i got the Reporting Services configuration section in my central administration but when i try to connect it to database ("Grant Database Access") it tells "Unable to connect to the Report Server WMI provider."

Update:
I have figured out that there was a problem with the service account, he couldn't use keberos against the domain. To solve the last issue you have to set the SPN on a DC and set the Authenticationprovider to NTLM on the Reportserver.
DC:
setspn.exe -a http/IIS_computer's_NetBIOS_name DomainName\UserName

setspn.exe -a http/IIS_computer's_FQDN DomainName\UserName

Reportserver:
cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"

Now you are able to auth on your Reportserver on any URL not only at localhost.

Update2:
To go more in detail, you need to add the spn for both servers (the sharepoint frontend and the reporting server backend). Then your authentication should work.