Es folgt ein recht alter Hut. Mir ist nur gerade mal aufgefallen, das ich den folgenden Weg MySQL Zugänge anzulegen, wenn man die Zugangsdaten eines MySQL Servers vergessen oder versehentlich gelöscht hat, noch nie hier niedergeschrieben habe.

Es geht im großenn und ganzen darum, das man zunächst den MySQL Daemon beendet, ohne Zugangstabellen zu laden wieder startet, den gewünschten Zugang anlegt und nach einem Neustart des Daemons, dieses Mal mit Zugangstabellen, diesen User dann für die weiteren Schritte verwenden kann.

Zunächst ein kurzer Sicherheitshinweis: Für die folgenden Schritte empfiehlt es sich den MySQL Daemon nur von localhost/127.0.0.1 erreichbar zu machen, da für einen kurzen Zeitraum jedermann ohne Passwort administrativ auf den Server connecten kann. Um ganz sicher zu gehen, kann man auch noch einen anderen Port wählen um lokalen Schabernack zu unterbinden.

Das Vorgehen ist wie folgt:

1. Beenden des MySQL Daemons
2. Starten des MySQL Daemons ohne Zugriffstabellen:
   mysqld_safe --skip-grant-tables &
3. Nun kann sich root ohne Passwort in die Datenbank "mysql" einloggen:
   mysql -uroot mysql
4. Passwort neu setzen:
   UPDATE user SET password=PASSWORD("abcd") WHERE user="root";
   Das neue Passwort wäre nun "abcd". Es kann natürlich gesetzt werden wie immer es sein soll.
5. (Optional) Zugriffsrechte neu einlesen:
   FLUSH PRIVILEGES;
6. Da man sich immernoch ohne Passwort einloggen kann, sind alle mysql Prozesse zu beenden; notfalls zu killen (nur, wenn das init Script es per "stop" nicht schafft alles was MySQL ist zu beenden). Besonders gilt das für die mysql_safe Instanz (prüfen ob noch was läuft per "ps waux | grep -i mysql").
7. Abschliessend MySQL wieder ganz normal starten.

Man hat so das Passwort des Users "root" wieder auf den in Punkt 4 verwendeten Wert gesetzt. Da dieses ja _der_ administrative User ist, können alle weiteren Korrekturen im ganz normalen, sicherem MySQL Kontext behoben werden.
Wenn man einen anderen User als "root" für seine administrativen Arbeiten verwendet, muss man selbstverständlich diesen in Punkt 3 und 4 statt "root" verwenden.

Ich hatte heute auf einem MySQL Slave Server den folgenden Fehler bei der Replikation von einem Master MySQL Server:

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: www.xxx.yyy.zzz
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: db.002174
Read_Master_Log_Pos: 342719703
Relay_Log_File: mysqld-relay-bin.000003
Relay_Log_Pos: 6458545
Relay_Master_Log_File: db.002170
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1005
Last_Error: Error 'Can't create table '/tmp/#sql7c49_2f_0' (errno: -1)' on query. Default database: 'live'. Query: 'create temporary table tmp_gen_table like tmp_to_gen_neu'
Skip_Counter: 0
Exec_Master_Log_Pos: 620120976
Relay_Log_Space: 4109869668
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
1 row in set (0.09 sec)

Ich musste recht lange suchen. Die o.g. Datei (/tmp/#sql7c49_2f_0.ibd) wurde zwar von mysql:mysql angelegt, jedoch war sie 0 byte groß. Im MySQL - Log fand ich nur den o.g. Fehler wieder. Also schaute ich im syslog und wurde fündig:

Jan 28 12:55:22 db kernel: [495131.291630] audit(1264679722.493:141): type=1503 operation="file_lock" requested_mask="wk::" denied_mask="k::" name="/tmp/#sql7c49_2f_0.ibd" pid=7924 profile="/usr/sbin/mysqld" namespace="default"

Das kenne ich inzwischen: Eine Zeile mit so komischen "requested_mask="wk::"" - Rechten kommt meistens, wenn eine Applikation an apparmor scheitert. Ich habe also der Datei /etc/apparmor.d/usr.sbin.mysqld die folgenden Zeilen hinzugefügt:

/usr/sbin/mysqld {
...
/tmp/ r,
/tmp/** rwk,
}

Schon geht's!
Ich fand es sehr überraschend, das das /tmp - Verzeichnis (in meinem Oldschool-Linux-Hinterkopf immer als das "jeder darf - Verzeichnis" abgelegt) ebenfalls einer eigenen Zeile in der apparmor-Konfiguration bedarf. Noch verwunderlicher finde ich, das dieses unter Ubuntu (8.04 - Hardy Heron) nicht standardmäßig dort aufgenommen wurde. Immerhin ist tmpdir=/tmp die Standardeinstellung unter dieser Ubuntu-Version.

Ich hatte heute den Fall auf der Arbeit, das ich auf eine an einem unserer Suse Linux Server angeschlossene USB 2.0 Festplatte mehrere Gibibyte an Daten kopieren musste.

Das dauerte .... und dauerte .... schliesslich fiel mir auf, das die Daten mit nur 160 KB/s kopiert wurden. Das kam mir komisch vor, schliesslich sollten die Datenraten von USB 2.0 doch deutlich höher liegen. In diesem Wiki-Artikel fand ich schliesslich heraus, das es (laut Spezifikation) 480 Mbit/s hätten sein sollen; also ca. 60 MebiByte pro Sekunde.
Das hat mich dann schon sehr gewundert, schliesslich ist das nur ca. 1/384tel Bruchteil der Transferkapazität des Buses.

Eine erste Recherche heute auf der Arbeit förderte diesen Foreneintrag von Dezember 2007 zu Tage, in dem der Hinweis gegeben wird, das dieses Problem verschwindet, wenn die mount-Option "sync" weggelassen wird. Als ich es ebenfalls probiert habe ohne "sync" zu mounten, war es auch schlagartig schneller.

Inzwischen habe ich etwas genauer nachrecherchiert:
Bei dem ganzen handelt es sich um einen zumindest bei Novell (Suse) bekannten Bug (siehe Novell Bugzilla Database #105871). Ob er nun nur bei Suse Linux auftritt oder ob es ein genereller Linux Bug ist, das weiss ich nicht. Und ehrlich gesagt bin ich jetzt auch zu faul den ganzen Bug zu lesen. Wer mag, kann das gerne nachholen.

Unter'm Strich bleibt zumindest für Suse Linux in der Version 10.x folgende Lösung: USB Laufwerke nicht mit der mountoption "sync" mounten!
(Ob andere Suse Linux Versionen oder gar andere Distributionen betroffen sind weiss ich nicht; einfach ausprobieren!).

Für per "subfs" gemountete Dateisysteme gibt es einen weiterführenden Workarround um sicher zu stellen, das diese Dateisysteme nicht mit "sync" gemounted werden:

1. mkdir -p /usr/share/hal/fdi/policy/95userpolicy
2. Eine Datei namens "nosync.fdi" darin erzeugen (vi /usr/share/hal/fdi/policy/95userpolicy/nosync.fdi) und darin folgenden Inhalt anlegen:
   <?xml version="1.0" encoding="UTF-8"?>
   <deviceinfo version="0.2">
   <device>
   <!-- disable sync for mount -->
   <match key="block.is_volume" bool="true">
   <match key="volume.fsusage" string="filesystem">
   <match key="volume.uuid" string="==UUID==">
   <merge key="volume.policy.mount_option.sync"
   type="bool">false</merge>
   </match>
   </match>
   </match>
   </device>
   </deviceinfo>
3. Ausführen von "lshal". Die Passage im unter Punkt 2. aufgeführten Text die hier temporär mit "==UUID==" befüllt ist, mit der Ausgabe dieses Befehls ersetzen.
4. HAL Daemon neu starten (rhal restart)

Ich hoffe dieses hilft einigen von Euch :)

Wie immer würde ich mich freuen, wenn ihr einen kurzen Kommentar eintragen würdet!

Achja, wie immer der Hinweis: Wer sich über diese "merkwürdigen" Bezeichnungen wie "MebiByte", GibiByte", etc. wundert, dem sein mein Artikel über Binärpräfixe als Lektüre ans Herz gelegt :)

Sowas habe ich echt noch nicht erlebt:

Auf unserem Server für Webseiten-Statistiken liegt ein Programm namens "fastlogres" im Ordner /usr/bin . Es handelt sich dabei um ein SUSE Linux System. Ein "rpm -qal | grep fastlogres" zeigt mir, das das Programm aus keinem RPM Paket stammt.
Normalerweise legen wir selbst kompilierte Sourcen in einem bestimmten Unterverzeichnis ab, für genau so einen Fall. Jedoch ist das in diesem Fall nicht passiert.

Eine Suchmaschienen-Recherche bringt mir leider keinen Erfolg. In keiner einzigen (!) Suchmaschiene finde ich etwas, das auf dieses Programm hinweist.

Es gibt leider keinen Switch bei dem Programm und keine Manpage, in der eine URL steht. Es gibt lediglich den switch -v zur Ausgabe der Version. Und diese Ausgabe lautet lediglich:

fastlogres 0.2.0

Das Programm löst IPs aus Apache Logfiles zu DNS Namen auf. Dieses tut es deutlich schneller als es der in AWstats eingebaute DNS Resolve Mechanismus tut. Ein Referenzlogfile eines Monats von einer unserer Seiten wird von AWstats in 57 minuten und 39 Sekunden ausgewertet. Dem gegenüber steht fastlogres mit nur 25 minuten und 53 Sekunden; also mehr als doppelt so schnell!

Genau das ist mein Ziel: Diesen Flaschenhals etwas zu "dehnen".

Bevor ich dieses Programm gefunden habe, bin ich auf "adnslogres", als Teil der GNU adns Bibliothek aufmerksam geworden. Diese benötigt für dasselbe Logfile

Daher: Bis jetzt ist fastlogres mit abstand das schnellste Programm!

Nur finde ich es nirgendwo im Netz :(
Es kann doch nicht sein, das auf unserem Server ein Programm läuft und derart super funktioniert, ohne das man im Internet auch nur einen Hinweis darauf findet.

Wenn jemand dieses Tool kennt, wäre ich höchst dankbar, wenn er mir hier einen Hinweis geben könnte.

Auch Alternativen, die die beschriebene Aufgabe erfüllen können, sind sehr gerne gesehen! :)

Mal wieder: Wir brauchen mod_auth_mysql , haben den apache2.2.8 auf dem Server laufen, und kriegen diesen tollen Fehler:

# /server/service/www/apache2/bin/apxs -c -L/usr/lib/mysql -I/usr/include/mysql -lmysqlclient -lm -lz mod_auth_mysql.c
/server/service/www/apache2/build/libtool --silent --mode=compile gcc -prefer-pic -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -pthread -I/server/service/www/apache2/include -I/server/service/www/apache2/include -I/server/service/www/apache2/include -I/usr/include/mysql -c -o mod_auth_mysql.lo mod_auth_mysql.c && touch mod_auth_mysql.slo
mod_auth_mysql.c:591: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:591: warning: cast to pointer from integer of different size
mod_auth_mysql.c:591: error: initializer element is not constant
mod_auth_mysql.c:591: error: (near initialization for ‘mysql_auth_cmds[0].cmd_data’)
mod_auth_mysql.c:595: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:595: warning: cast to pointer from integer of different size
mod_auth_mysql.c:595: error: initializer element is not constant
mod_auth_mysql.c:595: error: (near initialization for ‘mysql_auth_cmds[1].cmd_data’)
mod_auth_mysql.c:599: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:599: warning: cast to pointer from integer of different size
mod_auth_mysql.c:599: error: initializer element is not constant
mod_auth_mysql.c:599: error: (near initialization for ‘mysql_auth_cmds[2].cmd_data’)
mod_auth_mysql.c:603: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:603: warning: cast to pointer from integer of different size
mod_auth_mysql.c:603: error: initializer element is not constant
mod_auth_mysql.c:603: error: (near initialization for ‘mysql_auth_cmds[3].cmd_data’)
mod_auth_mysql.c:607: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:607: warning: cast to pointer from integer of different size
mod_auth_mysql.c:607: error: initializer element is not constant
mod_auth_mysql.c:607: error: (near initialization for ‘mysql_auth_cmds[4].cmd_data’)
mod_auth_mysql.c:611: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:611: warning: cast to pointer from integer of different size
mod_auth_mysql.c:611: error: initializer element is not constant
mod_auth_mysql.c:611: error: (near initialization for ‘mysql_auth_cmds[5].cmd_data’)
mod_auth_mysql.c:615: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:615: warning: cast to pointer from integer of different size
mod_auth_mysql.c:615: error: initializer element is not constant
mod_auth_mysql.c:615: error: (near initialization for ‘mysql_auth_cmds[6].cmd_data’)
mod_auth_mysql.c:619: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:619: warning: cast to pointer from integer of different size
mod_auth_mysql.c:619: error: initializer element is not constant
mod_auth_mysql.c:619: error: (near initialization for ‘mysql_auth_cmds[7].cmd_data’)
mod_auth_mysql.c:623: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:623: warning: cast to pointer from integer of different size
mod_auth_mysql.c:623: error: initializer element is not constant
mod_auth_mysql.c:623: error: (near initialization for ‘mysql_auth_cmds[8].cmd_data’)
mod_auth_mysql.c:627: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:627: warning: cast to pointer from integer of different size
mod_auth_mysql.c:627: error: initializer element is not constant
mod_auth_mysql.c:627: error: (near initialization for ‘mysql_auth_cmds[9].cmd_data’)
mod_auth_mysql.c:631: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:631: warning: cast to pointer from integer of different size
mod_auth_mysql.c:631: error: initializer element is not constant
mod_auth_mysql.c:631: error: (near initialization for ‘mysql_auth_cmds[10].cmd_data’)
mod_auth_mysql.c:635: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:635: warning: cast to pointer from integer of different size
mod_auth_mysql.c:635: error: initializer element is not constant
mod_auth_mysql.c:635: error: (near initialization for ‘mysql_auth_cmds[11].cmd_data’)
mod_auth_mysql.c:639: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:639: warning: cast to pointer from integer of different size
mod_auth_mysql.c:639: error: initializer element is not constant
mod_auth_mysql.c:639: error: (near initialization for ‘mysql_auth_cmds[12].cmd_data’)
mod_auth_mysql.c:643: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:643: warning: cast to pointer from integer of different size
mod_auth_mysql.c:643: error: initializer element is not constant
mod_auth_mysql.c:643: error: (near initialization for ‘mysql_auth_cmds[13].cmd_data’)
mod_auth_mysql.c:651: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:651: warning: cast to pointer from integer of different size
mod_auth_mysql.c:651: error: initializer element is not constant
mod_auth_mysql.c:651: error: (near initialization for ‘mysql_auth_cmds[14].cmd_data’)
mod_auth_mysql.c:655: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:655: warning: cast to pointer from integer of different size
mod_auth_mysql.c:655: error: initializer element is not constant
mod_auth_mysql.c:655: error: (near initialization for ‘mysql_auth_cmds[15].cmd_data’)
mod_auth_mysql.c:659: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:659: warning: cast to pointer from integer of different size
mod_auth_mysql.c:659: error: initializer element is not constant
mod_auth_mysql.c:659: error: (near initialization for ‘mysql_auth_cmds[16].cmd_data’)
mod_auth_mysql.c:663: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:663: warning: cast to pointer from integer of different size
mod_auth_mysql.c:663: error: initializer element is not constant
mod_auth_mysql.c:663: error: (near initialization for ‘mysql_auth_cmds[17].cmd_data’)
mod_auth_mysql.c:667: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:667: warning: cast to pointer from integer of different size
mod_auth_mysql.c:667: error: initializer element is not constant
mod_auth_mysql.c:667: error: (near initialization for ‘mysql_auth_cmds[18].cmd_data’)
mod_auth_mysql.c:671: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:671: warning: cast to pointer from integer of different size
mod_auth_mysql.c:671: error: initializer element is not constant
mod_auth_mysql.c:671: error: (near initialization for ‘mysql_auth_cmds[19].cmd_data’)
mod_auth_mysql.c: In function ‘format_request’:
mod_auth_mysql.c:947: warning: pointer/integer type mismatch in conditional expression
apxs:Error: Command failed with rc=65536

Woran liegt's? Zunächst: Keine Ahnung.

Irgendwann findet man aber raus, das man diesen Patch anwenden muss. Dann geht's problemlos.

Das geht wie folgt:

1. Am besten das mod_auth_mysql - Quellenverzeichnis nochmal löschen und das TAR neu entpacken.
2. Wechsel in das Quellenverzeichnis mod_auth_mysql-3.0.0.
3. Ausführen von "patch < ../mod_auth_mysql-3.0.0-apache-2.2.patch" (ich gehe davon aus, das der Patch ein Verzeichnis höher liegt; sonst bitte entsprechend anpassen).

Das sollte es gewesen sein. Als Resultat bekommt man:

patching file mod_auth_mysql.c

Anschließend sollte sich das Modul wie beschrieben per apxs kompilieren lassen.

Neeeee - was ärgert mich sowas:

Ich bin seit 2 Stunden dran um einen Fehler bei der mod_auth_mysql Authentifikation des Apache2 Webservers zu finden, und die einzige Webresource in der ich fündig werde (nach 2 Stunden, wohlgemerkt) ist ein italienisches Privatblog.

Ich hatte das Problem, das nach der Umstellung nur noch folgender Fehler in Logfile geschrieben wurde:

(9)Bad file descriptor: Could not open password file: (null)

Mich hatte es zwar schon stutzig gemacht, das da etwas von einer Passwort Datei stand, aber kapiert habe ich es soweit erstmal nicht, da ich nicht wusste ob die MySQL Tabelle evtl. aus Sicht des Servers tatsächlich eine Art "Passwortdatei" ist.

Auf jeden Fall lag es letzten endes daran, das Apache2 authz_user standardmäßig aktiviert, was der Apache1 nicht tut. Also erwartet er auch die Übergabe einer Passwortdatei. Diese war nicht definiert, also spuckt er die obige Fehlermeldung aus.

Behoben werden kann es ganz einfach, indem in der Apache2 Server-Config (httpd.conf, .htaccess, etc.) die folgende Einstellung gesetzt wird:

AuthBasicAuthoritative Off

Das war's! :)

(01.09.2008)
PS:

Nach der oben beschriebenen Methode kann man sich zwar wieder über niedriger priorisierte Authentifikationsmodule wie z.B. mod_auth_mysql anmelden, es erscheint im error-log jedoch nach wie vor die Meldung

(9)Bad file descriptor: Could not open * file: (null)

Dieses kann man beheben, indem man zusätzlich zu "AuthBasicAuthoritative Off" die folgenden zwei Einstellungen setzt:

AuthUserFile /dev/null
AuthGroupFile /dev/null

War mir irgendwie erst heute aufgefallen, das das nach wie vor geschrieben wird ... \~:)

Ich habe nun fast einen monat herumprobiert, ehe ich aufgegeben habe und alle Samba Datenbanken wieder gelöscht habe um von vorne anfangen zu können. Was immer ich beim ersten Durchlauf falsch gemacht habe: Nun habe ich diesen Schritt offenbar weggelassen :)

Damit auch andere von meinen Erfahrungen profitieren können, schreibe ich mein Vorgehen hier auf:

Eine kurze Übersicht über die Namen der Rechner und der User vorweg:

• linhir: Domänenmitgliedsserver, der User die sich verbinden wollen am PDC anfragen soll
• mrdomtest: User, der auf einefreigegebene Ressource auf linhir zugreifen können soll
• mordor: Der NetBIOS Name des PDC
• MFC: Name der Testdomäne

Ich bin dabei nach der offiziellen Dokumentation der Samba Foundation vorgegangen. Jedoch habe ich vorher ein paar weitere Schritte gemacht um sicher zu stellen, das mir kein Fehlerhafter Datenbankeintrag den Erfolg verwehrt:

1. Samba Server auf dem Mitgliedsserver beendet (Daemons smb, nmb, winbind)
2. Alle Dateien die dem Schema *.tdb entsprechen im Verzeichnis /etc/samba/ und /var/lib/samba/, sowie in deren Unterverzeichnissen, gelöscht.
3. Den Useraccount linhir\$ auf dem PDC aus der Unix Benutzerdatenbank (passwd/shadow/group) entfernt (userdel -r linhir\$)
4. Maschienenaccount von linhir (linhir\$) aus der Samba Nutzerdatenbank des PDCs entfernt (pdbedit -x -u linhir\$)

Nun sollte alles wieder auf Ausgangsposition sein.Hier meine smb.conf des Domänenmitgliedservers linhir:

[global]
workgroup = mfc
security = domain
password server = mordor

netbios name = linhir
server string = MFC Fileserver (%h) running Samba version %v

passdb backend = tdbsam
unix extensions = no
encrypt passwords = yes
wins server = mordor
name resolve order = wins lmhosts host bcast

log file = /server/logs/smb/samba/%m.log

[jukebox]
comment = jukebox
path = /server/data/samba/jukebox
valid users = MFC\mrdomtest
create mask = 0664
directory mask = 0775
browseable = yes
read only = no

So, wenn ich nichts vergessen habe ist das System nun wieder "nackt".

Der Vollständigkeit halber hier auch nochmal meine PDC Konfiguration (mordor)

[global]
workgroup = mfc
netbios name = mordor
server string = MFC PDC (%h) running Samba version %v

logon script = netlogon.cmd
logon path = \\%h\profiles\%U\%a.msprofile
logon home = \\%h\%u
logon drive = Z:
domain logons = Yes
os level = 190
preferred master = Yes
domain master = Yes
local master = Yes
wins support = Yes
passdb backend = tdbsam
unix extensions = no

security = user

encrypt passwords = yes

name resolve order = lmhosts host wins bcast

time server = Yes
log file = /server/logs/smb/samba/%m.log
log level = 1

add user script = /usr/sbin/useradd -c "Samba Useraccount (auto - add user script)" -g samba -s /bin/false "%u"
add machine script = /usr/sbin/useradd -c "Samba Maschinenenaccount (auto - add machine script)" -g machines -s /bin/false "%u"

delete user script = /usr/sbin/userdel "%u"
add group script = /usr/sbin/groupadd "%g"
delete group script = /usr/sbin/groupdel "%g"
add user to group script = /usr/sbin/groupmod -A "%u" "%g"
delete user from group script = /usr/sbin/groupmod -R "%u" "%g"
set primary group script = /usr/sbin/usermod -g "%g" "%u"

[homes]
comment = Home Directory von %u
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes

[netlogon]
path = /server/service/smb/samba/netlogon/
read only = yes
browseable = no

[profiles]
comment = Network Profiles Service
path = /server/data/smb/samba/ntprofile/
read only = no
browseable = no
create mask = 0660
directory mask = 0770

Ab hier folge ich also der o.g. Doku der Samba Foundation.

Wie ihr anhand der "add user|machine script"e sehen könnt, verwende ich die Methode "On-the-Fly Creation of Machine Trust Accounts", wie sie in der Doku genannt wird.

Weiter steht darin in kürze, das man auf dem Domänenmitgliedsserver nur folgende Werte ändern braucht:

security = domain
workgroup = %DOMAINNAME
password server = %PDC_NETBIOS_NAME

Ich setze "password server = mordor", um den Wildcard - zweifel zu beseitigen (Ob der Server das richtig auflösen kann, etc).

Ich starte nun Samba (smb und nmb) auf linhir.

Die *.tdb Datenbankdateien wurden wieder angelegt, was richtig ist.

Die Doku fährt nun wie folgt fort:

net rpc join -S DOMPDC -UAdministrator%password

Auf meine Domäne umgeschlagen entspricht das:

net rpc join -S mordor -U root

Also gebe ich folgendes auf der Shell ein und erhalte folgende Ausgabe:

linhir:/etc/samba # net rpc join -S mordor -U root
Password:
Joined domain MFC.
linhir:/etc/samba #

Hat also alles geklappt.
Der User wurde auf mordor auch gescheit in die passwd, samba Datenbank, usw eingetragen.

Nächstes laut Doku: Samba Daemons neu starten. OK, also auf linhir UND mordor nmb und smb neu starten.

Done :)

Nun folgt auch der Hinweis weswegen ich der Meinung bin ich brauche einen Winbind daemon:

Please refer to Winbind: Use of Domain Accounts, for information on a system to automatically assign UNIX UIDs and GIDs to Windows NT domain users and groups.

Aber OK - bleiben wir zunächst bei der Handarbeit.
Zumal der Punkt "Sharing User ID Mappings between Samba Domain Members" mal wieder nur eine Methode per LDAP berücksichtigt..

Das wär's dann auch. Mehr ist laut diesem hochoffiziellen Guide nicht zu tun.
Ausser dieses hier:

Currently, domain security in Samba does not free you from having to create local UNIX users to represent the users attaching to your server. This means that if domain user DOM\fred attaches to your domain security Samba server, there needs to be a local UNIX user fred to represent that user in the UNIX file system.

Mein Testuser heisst "mrdomtest". Das sich dieser User am PDC authentifizieren kann, teste ich zunächst indem ich einen zur selben Domäne hinzugefügten Windows XP Professional Rechner nehme und mich dort als "mrdomtest" anmelde ... Klappt!

Jetzt ändere ich den Punkt "valid users" des shares "jukebox" auf linhir wie im Howto als Beispiel für fred angegeben: MFC\mrdomtest .

Damit Samba auch auf den gleich heissenden Unix User im Filesystem referieren kann, checke ich ab das es auch diesen gibt, sowie das es keinen solchen in der Samba Datenbank gibt:

linhir:/etc/samba # grep mrdomtest /etc/passwd
mrdomtest:x:9031:100::/home/mrdomtest:/bin/false
linhir:/etc/samba # pdbedit -L
linhir:/etc/samba #

Nun teste ich mich mit dem Windows XP Domänenrechner mit eingeloggedem User mrdomtest auf das Share "jukebox" des Servers "linhir" zu verbinden: Klappt!

Der User "mrdomtest" ist laut Ausgabe des Befehls "pdbedit -L" auf linhir nach wie vor nicht in der Samba Userdatenbank zu finden. Also hat alles funktioniert :)

Ich hoffe dieser Beitrag ist dem einen oder anderem eine kleine Hilfe.

Ich freue mich stets über Feedback :)