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:/
/etc/init.d/eisconfig –> eisfair-2 mount /home
Stehen alle im Wiki vom trac: http://www.lespocky.de/eisfair/trac/wiki/packages
20:39:18 < StarWarsFan> check-files-new.sh ab zeile 122 20:40:59 < StarWarsFan> und in create-list-new.sh ab zeile 146
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
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
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/<section>/foo die ordner "var",
"usr" und "etc" gibt,
Di|04:23:25 <@StarWarsFan|NB> dann werden diese in den ordner trunk/<section>/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... :-)
/usr/share durchsuchen https://eisler.nettworks.org/cgi-bin/mailman/private/eisfair-testteam/2008-January/002799.html
ln -s /usr/lib/gcc/i486-linux-gcc/4.2/cc1 /usr/bin/cc1 und probier dann noch mal ein configure
HowTo zum Umziehen eines Mail Servers auf eine neue Hardware:
useradd -g 100 -m -u 2001
5 User Admin
6 Invalidate User
Username und 2 * Enter
| 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 | — |
FETCHMAIL_x_KEEP='yes'
/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.
/var/certs/ssl/certs/ mit den Certifikaten wechseln und /usr/bin/ssl/c_rehash starten
svn log https://eisler.nettworks.org/svn/eis/ | grep '^r[0-9]\+[ ][|]' | cut -d '|' -f 2 | sort -b | uniq -c | sort -b -n -r