Well, it turns out that building stuff on ppc64 is a *real* pain in the ass, at least on anything SUSE related. I do have to tweak every damn spec to include this:
1
2
3
| %ifarch ppc64
export LDFLAGS="$LDFLAGS -m64"
%endif |
Otherwise, ld is gonna fail when linking, as it’s gonna try linking the generated 64bit code (-m64 is passed on via RPM_OPT_FLAGS to CFLAGS) as 32bit code, which ain’t gonna work at all …
On top of that, stuff ain’t building due to multiple problems (for example nagios and vim, cause ld is unable to find the fitting -lperl (for nagios) and -lXt (for vim)) as well as source errors …
gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I/usr/include -D_FREETDS_LIBRARY_SOURCE -DUNIXODBC -DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG=4 -D_REENTRANT -D_THREAD_SAFE -DDEBUG=1 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long -pthread -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -Wdeclaration-after-statement -MT connectparams.lo -MD -MP -MF .deps/connectparams.Tpo -c connectparams.c -fPIC -DPIC -o .libs/connectparams.o
In file included from connectparams.c:22:
../../include/config.h:375:1: warning: "SIZEOF_LONG" redefined
<command line>:1:1: warning: this is the location of the previous definition
connectparams.c:90: error: static declaration of `SQLGetPrivateProfileString' follows non-static declaration
/usr/include/odbcinst.h:170: error: previous declaration of `SQLGetPrivateProfileString' was here
make[3]: *** [connectparams.lo] Error 1
make[3]: Leaving directory `/srv/BUILD/freetds-0.82/src/odbc'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/srv/BUILD/freetds-0.82/src/odbc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/srv/BUILD/freetds-0.82/src'
make: *** [all-recursive] Error 1
Life
PowerPC, RPM, SLES10
Well, to begin with we had this really weird problem that the thin clients as well as the terminal server would only load user based group policy if you are a member of the group of local administrators. While that’s ok for the thin clients (users can’t actually change something unless they log in as “Administrator” - don’t ask me why), it’s a real no-no on the terminal server.
We tried redoing *everything* (that is, starting with the domain, then terminal server and after that the thin clients) and yet nothing changed, it didn’t work either. That’s what I’ve been doing the last 2 weeks. Up till now, I always thought a user would have access to the ntuser.dat (that is HKEY_CURRENT_USER), if his NTFS permissions would be correct. But nooooooooooooooooooooo, Microsoft had to introduce another layer of permissions.
Old permissions on HKEY_CURRENT_USER
Once you change it to be proper (as in remove the dead user entry and add a group that actually gets you somewhere), it’s all starting to work!
New permissions on HKEY_CURRENT_USER
Life
Group Policy Object, Windows Server 2003, Windows XP Embedded
OK, so about an hour (yeah, yeah; I know .. I shouldn’t be working at that time, but it really gave me sleepless nights) ago, I finally figured out why the hell both my Windows XP Embedded thin clients as well as my Windows Server 2003 systems where showing this real *weird* behaviour when applying group policies, or more precise the user based configuration of a group policy.
The inspiration came to me after reading this and taking a look at regedit myself, where I noticed the entry “Permissions” for the first time ever since I’m using regedit. I also noticed, that the regedit permissions seem to be using the same groups, one would assign to NTFS resources.
That said, it really all boils down to the ntuser.dat (which *IS* HKEY_CURRENT_USER). As I created the profile with a different user than I am using it with (basically, I want ~12.000 users to use this one profile), I needed to change the permissions *INSIDE* regedit to include a group containing all these users. After that, any user could again merge the settings from ntuser.pol into HKEY_CURRENT_USER\Software\Policies, which in return gives you the joy of your fucking policies working again.
TADAAAAAA! About two weeks worth of work spent for such a shitty thing, and noticing it when you’re off work — priceless!
Life
Active Directory, Group Policy Object, Thin Clients, Windows Server 2003, Windows XP Embedded
