====== eisfair ====== ===== Allgemeine ToDos ===== * rsync angehen: Tom, Marcus Herleb und dev-ML kontaktieren, Peter wg. HowTo Sa|22:15:32 <@LanSpezi> dickes fettes Danke - das funzt 1a Sa|22:15:59 <@LanSpezi> rsync -vrlcogt --iconv=ISO8859-1,UTF-8 * root@filesrv-e2:/ * checken ob Shell-Builtins //true// und //false// spezifisch für Bash sind oder POSIX-Standard ===== Notizen zu eigenen Paketen ===== * rechte setzen im install-skript geht sicher eleganter.. * statt absoluter pfad PATH am anfang vom skript * link auf den package server auf meine seite packen * config files von serverdiensten auf 600? * **deinstall soll rechte 700 haben** * ''/etc/init.d/eisconfig'' --> eisfair-2 mount /home ===== Potentielle Bugs ===== * trac: * installieren, projekt nicht aktivieren -> fehler * bonding vs. samba * packagedevelopment svn version (auf welchen Unterordner wird das angewendet?) ===== Rückmeldungen ===== Stehen alle im Wiki vom trac: http://www.lespocky.de/eisfair/trac/wiki/packages ===== Notizen zu anderen Paketen und Changesets ===== * [[https://eisler.nettworks.org/t-team_eis/trac/eis/changeset/14085|r14085]]: Jens verwirft eislib/mecho zugunsten einheitlicher Darstellung unter eisfair-1/eisfair-2 – Erweiterung der eislib für solche Spielchen? Mit allgemeinen Funktionen für //[ ok ]// und //[ fail ]// am Ende der Zeilen! * check der build skripte gegen //svn:mime-type// verbessern 20:39:18 < StarWarsFan> check-files-new.sh ab zeile 122 20:40:59 < StarWarsFan> und in create-list-new.sh ab zeile 146 * [[https://eisler.nettworks.org/t-team_eis/trac/eis/changeset/14548|r14548]]: Jürgen baut einen zusätzlichen Check ins Mail-Paket ein, hauptsache man kann dann auch noch Mails verschicken ;-) * [[https://eisler.nettworks.org/t-team_eis/trac/eis/changeset/15028|r15028]]: Holger benutzt ein externes Tool um XML ohne Newlines wieder ins Eisfair-Format zu übersetzen – besser wäre natürlich eine Umstellung auf echte XML-Files und ein echter XML-Parser ===== Developer ===== ==== mklib.sh ==== Fr|09:49:04 < schlotze> ok. MINI-HOWTO: Fr|09:49:17 < schlotze> 1) Aufruf im Ordner ..../_ADMIN Fr|09:49:28 < schlotze> (Es gibt keine Parameter) Fr|09:49:52 < schlotze> 2) Es werden im Ordner .../output/lib/ die Pakete erzeugt Fr|10:07:34 < schlotze> 3) die Definition, welche Lib Pakete erzeugt werden sollen, erfolgt in ubuntuLibPackages*.txt Fr|10:07:49 < schlotze> sry. mehr zeit hab ich gerade nicht. Ansonsten frag einfach Fr|10:07:58 < schlotze> ach ja: Es werden immer alle Libs erzeugt ==== signierte Pakete ==== Mo|01:24:08 < LeSpocky> _Tux_: wozu ist bei Debian die GnuPG-Signierung der Pakete gut? Also wieso wird das gemacht? Mo|01:24:45 <@_Tux_> Authenzifizierung. Mo|01:25:07 < LeSpocky> wer authentifiziert wen? Mo|01:25:11 <@_Tux_> Die Signatur muss von einem Debian-Entwickler kommen und jeder Debian-Entwickler muss seinen Key von einem anderen Debian-Entwickler signieren lassen. Mo|01:25:33 <@_Tux_> Im prinzip gibt es zwischen je zwei Debian-Entwicklern immer eine Kette von Leuten, die sich schonmal gesehen und bestaetigt haben. Mo|01:25:36 < LeSpocky> das ist bekannt Mo|01:25:52 <@_Tux_> und nur pakete mit einer gueltigen Debian-Signatur werden ueberhaupt vom Server ausgeliefert und vom Installer akzeptiert. Mo|01:26:05 < LeSpocky> wieso werden die Pakete überhaupt signiert? also was hat der installer und der nutzer davon? Mo|01:26:22 <@_Tux_> Das stellt sicher, dass nur Debian-Entwickler Pakete bereitstellen. Qualitaetssicherung sozusagen. Mo|01:26:40 <@_Tux_> Debian-Entwickler wird man nicht so ohne Weiteres und niemand riskiert diese Mitgliedschaft fuer schlechte Pakete. Mo|01:26:59 <@_Tux_> Und man kann dem Nutzer keine gefaelschten Pakete unterschieben. Mo|01:27:38 < LeSpocky> ich kann aber auch andere pakete installieren, die zwar signiert sind, aber nicht in der kette auftauchen, werde dann aber von apt oder dpkg gefragt, ob ich das will Mo|01:27:55 < LeSpocky> hmm, also die integrität ließe sich auch mit einem hash prüfen Mo|01:32:09 <@_Tux_> aber nicht, ob das paket von einem Debian-Entwickler kommt Mo|01:32:18 <@_Tux_> das prueft ja auch der paket-server Mo|01:33:14 <@_Tux_> letztendlich werden auch die hashes signiert Mo|01:33:26 <@_Tux_> jedenfalls bei den Paketlisten Mo|01:34:07 <@_Tux_> Wenn die Integritaet nicht stimmt, kannst Du gar nicht installieren. Wenn der GPG-Key nicht von einem Debian-Entwickler kommt, wirst du gewarnt Mo|01:34:27 < LeSpocky> ok Mo|01:34:46 < LeSpocky> ich hab halt grad überlegt, ob signierte Pakete für eisfair sinnvoll wären Mo|01:37:26 <@_Tux_> ich halte signierte pakete in jedem system fuer sinnvoll Mo|01:37:31 < LeSpocky> ich hab's mal als Notiz im internen Wiki zum neuen Paket Installer vermerkt Mo|01:37:41 <@_Tux_> dann kann man auch viel besser proxies und mirrors anbieten. weil die naemlich die pakete nicht aendern koennen Mo|01:37:49 <@_Tux_> sonst entsteht ja das vertrauen nur durch den ausliefernden server Mo|01:38:23 < LeSpocky> interessanter Punkt ==== pkgdev vs. alte Pakete ==== Di|04:13:03 <@StarWarsFan|NB> eieiei Di|04:13:09 <@StarWarsFan|NB> auf der ml gehts ja wieder mal rund... Di|04:15:41 <@StarWarsFan|NB> @all: natürlich ist pkgdev so designed, dass es mit dem alten und neuen system klarkommt Di|04:16:05 <@StarWarsFan|NB> man kann ein paket vom alten system auch problemlos mit pkgdev bauen Di|04:16:14 <@StarWarsFan|NB> und auch die migration ist kein problem Di|04:16:52 <@StarWarsFan|NB> ich hab' auch ein script geschrieben, mit dem man "alte" pakete ggf. in die "neue" struktur überführen kann Di|04:16:55 <@StarWarsFan|NB> incl. history Di|04:17:08 <@StarWarsFan|NB> also um es auf den punkt zu bringen: Di|04:17:21 <@StarWarsFan|NB> es ist _KEIN_ problem, das alte und neue system zusammen laufen zu lassen Di|04:17:27 <@StarWarsFan|NB> siehe nfsserver und nfsclient Di|04:17:33 <@StarWarsFan|NB> die liegen beide im svn Di|04:17:52 <@StarWarsFan|NB> und das eis1-paket wird (noch) von den alten scripten gebaut, das eis2-paket aber schon von den neuen scripten Di|04:19:08 <@StarWarsFan|NB> zum migrationsscript: Di|04:19:13 <@StarWarsFan|NB> zu finden hier: Di|04:19:50 <@StarWarsFan|NB> https://eisler.nettworks.org/developer/projects/eis/browser/trunk/_ADMIN/migrate-package-svn-structure.sh Di|04:20:26 <@StarWarsFan|NB> das ist nicht im paket pkgdev drin, da das paket als solches die "alte" struktur gar nicht kennt Di|04:20:47 <@StarWarsFan|NB> bei einer eisler-workingcopy ist es aber ganz normal dabei Di|04:22:04 <@StarWarsFan|NB> das script ist dafür gedacht, den momentanen inhalt des paketordners im repo in den ordner .../common/... zu verschieben Di|04:22:13 <@StarWarsFan|NB> und die notwendigen setting-files anzulegen Di|04:22:14 <@StarWarsFan|NB> sprich Di|04:23:05 <@StarWarsFan|NB> wenn es im fiktiven ordner trunk/
/foo die ordner "var", "usr" und "etc" gibt, Di|04:23:25 <@StarWarsFan|NB> dann werden diese in den ordner trunk/
/foo/common/ verschoben Di|04:23:58 <@StarWarsFan|NB> und danach die settings angelegt Di|04:24:15 <@StarWarsFan|NB> wie bspw. foo/_ADMIN/foo-global-settings.txt etc. pp. Di|04:32:34 <@StarWarsFan|NB> achso: LeSpocky|afk : falls du das log nicht sowieso liest, du solltest mal ein wenig zurückblättern Di|04:32:49 <@StarWarsFan|NB> ab 21:13 Di|04:33:09 <@StarWarsFan|NB> ups, in D also ab 04:13 Di|04:33:12 <@StarWarsFan|NB> :-) Di|04:34:11 <@StarWarsFan|NB> sodele, /me ist dann wieder off Di|04:34:19 <@StarWarsFan|NB> bis die tage... :-) ==== Vim auf eisfair-2 ==== * benötigt die Pakete [[http://packages.ubuntu.com/hardy-updates/vim-runtime|vim-runtime]] und [[http://packages.ubuntu.com/hardy-updates/vim|vim]] * benötigt auch [[http://packages.ubuntu.com/hardy-updates/python2.5|python2.5]] – Python gibt es noch nicht für eisfair-2, bei eisXen hingegen sind einige Pakete dabei, weil Xen das braucht ===== Testteam ===== ==== aktuelle ISOs ==== * https://eisler.nettworks.org/t-team_eis/iso/ ==== ToDo ==== * für eisfair-2 ''/usr/share'' durchsuchen [[https://eisler.nettworks.org/cgi-bin/mailman/private/eisfair-testteam/2008-January/002799.html]] * LeSpocky: mach mal ''ln -s /usr/lib/gcc/i486-linux-gcc/4.2/cc1 /usr/bin/cc1'' und probier dann noch mal ein configure * https://eisler.nettworks.org/~schlotze/ – RC4 iso mit non-pae Kernel ===== Doku ===== ==== ToDo ==== * Überblick verschaffen * mit MiKTeX und den bei Ubuntu und Sid mitgelieferten Distris kompilieren * HowTo Doku mit in die Entwicklerdoku aufnehmen ==== verteilte Doku-Schnipsel ==== * [[https://eisler.nettworks.org/t-team_eis/trac/eis/browser/trunk/_ADMIN/create-check-mktarball-info.txt|create-check-mktarball-info.txt]]: da steht, welche Flags es für die filelist der Pakete gibt ===== IRC ===== [[irc://main.freechat-network.de|main.freechat-network.de]] ===== Mail-Umzug-HowTo ===== ==== HowTo von Peter Schauder ==== HowTo zum Umziehen eines Mail Servers auf eine neue Hardware: * Anlegen aller Systemuser für welche Mailordner übernommen werden sollen. Diese sollten mit möglichst gleicher UID/GID angelegt werden. Das funktioniert, wenn noch keiner der User angelegt wurde mit den UID Nummern 2000 aufwärts, wenn es hier keine Deckung gibt, können die User auch direkt mit einer passenden UID und GID angelegt werden. Dabei muss aber auch ein entsprechendes Homeverzeichnis angelegt werden. useradd -g 100 -m -u 2001 * Diese User können, soweit nicht anders benötigt, vom Logon ausgeschlossen werden. 5 User Admin 6 Invalidate User Username und 2 * Enter * Überprüfen, dass auf beiden Systemen die gleiche Version der folgenden Packete eingespielt ist: | Mail | 1.8.1 | x | | | antispam | 1.6.11 | x | | | base | 1.5.6 | x | | | clamav | 1.2.6 | x | | | webmail | 1.5.12 | x | | | shareutil | 1.0.1 | x | | | antispam-razor | — | | | | certs | 1.0.15 | x | da gibts ein conig problem, nochmal nachschaun !!!!!!!!!! | | archimap | — | | | * Mailserverconfig von 'abholen und löschen' auf 'abholen und drauflassen' ändern … nur für den Fall der Fälle FETCHMAIL_x_KEEP='yes' * Mail, webmail und Antispam stoppen (auf beiden Maschinen) * Kopieren folgender Dateien per TAR/SSH /etc/config.d/antispam /antispam_razor /archimap /certs /mail /clamav /webmail /home/user/.imapmail/* # alternativ das ganze userverzeichnis /.forward /.mailboxlist /.archimap /var/spool/mail/* /var/certs/ssl/certs/* /var/antispam kopieren mit: tar -czpf - /home/xxx/.yyy | ssh services tar -xzf - -C / dann sollten auch die Berechtigungen und User/Groupzuordnungen mitkopiert werden. * Ins Verzeichnis ''/var/certs/ssl/certs/'' mit den Certifikaten wechseln und ''/usr/bin/ssl/c_rehash'' starten * Konfigurationen von Mail, Certs, Antispam und gegebenenfalls antispam-razor öffnen und speichern, damit dir Konfigdaten prozessiert werden. * Mailservice und Antispam starten * DNS aufs neue System zeigen lassen * ausprobieren ==== Ergebnis ==== * http://www.lespocky.de/eisfair/trac/wiki/HowTo/MailUmzug ===== Spaßiges und interessantes ===== svn log https://eisler.nettworks.org/svn/eis/ | grep '^r[0-9]\+[ ][|]' | cut -d '|' -f 2 | sort -b | uniq -c | sort -b -n -r