stable/updates

stable/updates - debian (37 Beiträge, 547 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi,

was bedeutet eigentlich das stable/updates in der sources.list?
deb http://security.debian.org/ stable/updates main contrib non-free

Was ist der Unterschied zu:
deb http://ftp.de.debian.org/debian/ stable main contrib non-free

könnte ich auch
deb http://ftp.de.debian.org/debian/ stable/updates main contrib non-free

angeben?

gibts das stable/updates nur für den security Pfad?

23.04.2012, 20:29 Uhr - Editiert von User64693, alte Version: hier

Das ist einfach der Pfad:

ftp://security.debian.org/debian-security/dists/stable
( deb ftp://security.debian.org/   stable/updates main contrib non-free )
vs.

ftp://ftp.de.debian.org/debian/dists/squeeze-updates/
( deb ftp://ftp.de.debian.org/debian  squeeze-updates main contrib non-free )

ftp://ftp.de.debian.org/debian/dists/squeeze/
( deb ftp://ftp.de.debian.org/debian  squeeze main contrib non-free )

oder

ftp://ftp.de.debian.org/debian-security/dists/stable
( deb ftp://ftp.de.debian.org/debian-security  stable/updates main contrib non-free )

Was es auf welchem Server für welches Archiv gibt, kann ich nicht so genau sagen. Ich schätze mal, dass häufig einfach viele Kombinationen zur Verfügung gestellt werden (mit Symlinks) damit man nicht so lange herumprobieren muss.

ACTA wird Menschen töten | wikileaks.geizhals.org

„Ich habe den Verdacht, dass sich alle Terrorismen, egal, ob die deutsche RAF, die italienischen Brigate Rosse, die Franzosen, Iren, Spanier oder Araber, in ihrer Menschenverachtung wenig nehmen. Sie werden übertroffen von bestimmten Formen von Staatsterrorismus“ (Helmut Schmidt)

"Ermittlungen in großen Wirtschaftsstrafsachen unterliegen wegen der Berichtspflichten der Ermittler zum Innen- und Justizministerium vollends dem politischen Würgegriff" (N. Haslhofer, ehem. StA)

24.04.2012, 00:23 Uhr - Editiert von mjy@geizhals.at, alte Version: hier

danke - find die logik irgenwie verwirrend

Logik hat bei den ganzen permanenten Provisorien in der Linux-Welt schon lange nichts mehr verloren. Konfigurationsdateien, commandline-Optionen, sonstige Konventionen sind ein völlig inkonsistentes, benutzerunfreundliches Mischmasch, absolut hoffnungslos.

damit lieferst du schon einen hauptgrund, warum man das nicht einsetzen will

mein alltime-favorite ist immer noch samba. deren dokumentation bestand bei vielen parametern einfach darin auf den sourcecode zu verweisen. als ob man nichts besseres zu tun hätte als c code zu lesen.

Kennst Du auch die anderen Möglichkeiten ? Die sind nämlich noch g*PIEP*er.

Ob's jetzt Registry, ODM oder sonstirgendwie heißt, alles was ich nur mit Drittprogramme lesen kann suckt.

Einzig was praktisch wäre, wäre wenn sich die Leute mal XML als Config anschaun bzw. umbasteln würden.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

24.04.2012, 16:12 Uhr - Editiert von A national Acrobat, alte Version: hier

wenn sich die Leute mal XML als Config anschaun bzw. umbasteln würden.

wuaaah... geh weg mit dem Dreck. XML ist jetzt ca. 16 Jahre alt und noch immer gibt es haufenweise kaputte Parser.

Es gibt bereits außerordentlich gute und lesbare Alternativen wie YAML oder gar JSON(!).

Grad deshalb XML

. xmlint z.B. ist ein hervorragendes Teil zum Checken von Configs (nutze ich bei unseren JBOSS-App-Servern).

Was ist an XML nicht wirklich lesbar ?

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Ein generischer (wenn auch validierender) Parser ist da imho so gut wie wertlos. Mag ja sein, dass ich damit meine Config bequem auf syntaktische Korrektheit und passende Typen pruefen kann - aber das macht das Syntax Highlightning meines Editors eigentlich genau so gut.

In Wahrheit ist es doch so, dass die Konfiguration eines komplexen Dienstes viel subtiler falsch sein kann, als mir eine DTD (oder halt ein Relax-NG Schema oder was immer es heute gibt - XML ist schon eine Weile nicht mehr so hip, dass ich da auf Stand zu sein behaupte

) das zu pruefen oder zu formulieren ermoeglicht. Insofern sind fall- und anwendungsspezifische Tools wie z. B. `apachectl -S`, die die Konfiguration des Dienstes, mit dem sie mitgeliefert werden, in gewissem Masze auch "verstehen", bewerten und deren Auswirkungen verstaendlich darstellen bzw. aufbereiten koennen, einem einfachen lint-Programm (auch wenn ein XML-Parser klarerweise technisch nicht gar so einfach ist

) die viel sinnvollere Loesung.

Klar KOENNTE man das auch mit irgendeiner XML-Serialisierung der Konfigurationsdaten machen, und man wuerde sich ein bisschen Aufwand sparen, den Lexer/Parser/Validator/Interpreter fuer das "eigene" Dateiformat zu implementieren, aber einen wirklich substantiellen Vorteil hat das alles aus meiner Sicht nicht. Ich bin jedenfalls jedes Mal heilfroh, wenn mir beim Oeffnen einer Konfigurationsdatei in vim kein XML entgegenkrabbelt - pfui!

Ein generischer (wenn auch validierender) Parser ist da imho so gut wie
wertlos. Mag ja sein, dass ich damit meine Config bequem auf syntaktische
Korrektheit und passende Typen pruefen kann - aber das macht das Syntax
Highlightning meines Editors eigentlich genau so gut.

Es geht in meinem Anwendungsfall auch um mitgelieferte Konfigurationsdateien, und bei Hot-Deployment hat man da schon üble Überraschungen erlebt. Deshalb wird das Zeugs jetzt zumindestens soweit gecheckt als das man sagt "ok, XML Syntax passt, auch wenn Müll drinsteht".

Klar ist sowas wie apachectl optimal, aber Apache ist ja auch für den HA Einsatz ausgelegt da darf einfach kein grober Fehler sein. Ich seh da immer den bei uns oft eingesetzten JBoss, das ist für uns Admins nicht zu kontrollieren was da reinkommt oder was draußen bleiben muß - wir gehen stur nach dem mitgelieferten Dokument und da sind generische Parser schon eine Hilfe - sowas wie apachectl natürlich explizit gut, da er ja auch sowas wie doppelt vergebene vhost-Namen checkt.

Also ich bin mit XML immer ganz gut gefahren (auch wenn ich jetzt bei meinem privaten Projekt ein XML-Problem hab

), es ist halt sehr generisch, da liegt sein großer Vorteil aber auch sein großer Nachteil drin.

Von Admin-Seite aus sind mir persönlich CSV ähnliche Configfiles wie passwd z.b. am liebsten, das kannst mit einem einfachen awk schnell parsen und mußt ned viel nachdenken

.

lg.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Was ist an XML nicht wirklich lesbar ?

Also wir verwenden hier 2 verschiedene XML-Parser nur um die Chancen zu erhöhen, dass wir mit den kaputten XML-Formaten, die in der Branche verwendet werden (Preislisten), klar zu kommen.

Das glaub ich Dir schon das es übelst formatierte XML Dateien gibt, liegt aber nicht unbedingt am XML Format itself, sondern an denen die die Datei erstellen

.

Wenn man halbwegs sauber arbeitet ist XML wirklich ein Format das so ziemlich alle Daten speichern kann.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Beides kann man allerdings ueber jedes beliebige Dateiformat sagen, gell?

Stimmt schon, aber bei XML kannst halt durch Parser schon paar Fehler abfangen, aber ich glaub GH bräuchte mehr als 2 Parser wenn die Dateien in .ini Style kommen würden

.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

XML wirklich ein Format das so ziemlich alle Daten speichern kann.

if all you have is a hammer ...

XML ist fuer sowas grundsaetzlich einfaches wie preislisten kein sinnvolles format.

streng nach spec gibt's keine fehlertoleranz, z.b. kaputtes encoding. ein falsches zeichen und es duerfte nach spec komplett nicht geparst werden. das ist praktisch total egal, eine zeichenkraxn in ein paar 1.000 (oder hier auch in ein paar millionen) eintraegen ist belanglos, und jedenfalls weit weniger schlimm als veraltete information weil die aktuelle liste nicht geparst werden kann.

dazu kommt unnoetiger overhead durch das markup (MOAR BYTES!) und das aufwaendigere parsen (RAM, CPU, fehleranfaelligere software).

XML ist fuer sowas grundsaetzlich einfaches wie preislisten kein sinnvolles
format.

Dazu kenn ich zuwenig die Specs die ihr da übermittelts (oder übermittelt bekommts).

streng nach spec gibt's keine fehlertoleranz, z.b. kaputtes encoding. ein
falsches zeichen und es duerfte nach spec komplett nicht geparst werden. das
ist praktisch total egal, eine zeichenkraxn in ein paar 1.000 (oder hier auch
in ein paar millionen) eintraegen ist belanglos, und jedenfalls weit weniger
schlimm als veraltete information weil die aktuelle liste nicht geparst werden
kann.

Da frag ich mich aber wie die Listen generiert werden. Weil "normal" - wenn das alles maschinell passiert - dürfts garkeine Fehler geben. Aus vielen DBs kann man AFAIK schon direkt in XML die Ausgabe erstellen etc. Wie gesagt für euren Fall weiß ich nicht wirklich was ihr da übermittelts bzw. wie das auszusehen hat.

Aber das hättest ja ebenso bei anderen Formaten. Wenn (ich geh jetztmal von dem worst-case .ini Beispiel aus) dort eine Section falsch formattiert ist, stimmen ebensowenig die unteren Einträge und einen Parser wirds ebenso aufklatschen.

dazu kommt unnoetiger overhead durch das markup (MOAR BYTES!) und das
aufwaendigere parsen (RAM, CPU, fehleranfaelligere software).

Gut Overhead.. naja ist sicherlich ebenso zu berücksichtigen, da hab ich aber ned wirklich viele Beispiele oder Daten im Kopf wie sehr der Overhead zum "Kropf" hier wird.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Weil "normal" - wenn das alles maschinell passiert - dürfts garkeine Fehler geben.

beruehmte letzte worte.

XML geht wenn alle beteiligten wissen was sie tun und dabei keine fehler machen. schoenes konzept, aber ausgesprochen praxisfern.

Aber das hättest ja ebenso bei anderen Formaten. Wenn (ich geh jetztmal von dem worst-case .ini Beispiel aus) dort eine Section falsch formattiert ist, stimmen ebensowenig die unteren Einträge und einen Parser wirds ebenso aufklatschen.

man kann fuer vieles fehlertolerante parser schreiben. bei XML ist halt laut spec fehlertoleranz ausgeschlossen, das macht es fuer sachen, bei denen es nicht noetig ist dass immer alles fehlerfrei funktioniert nicht wirklich brauchbar. in der praxis kann man bei den meisten XML parsern gewisse toleranzen einschalten, dann stellt sich halt wieder die frage "warum dann ueberhaupt XML"?

Gut Overhead.. naja ist sicherlich ebenso zu berücksichtigen, da hab ich aber ned wirklich viele Beispiele oder Daten im Kopf wie sehr der Overhead zum "Kropf" hier wird.

je nach phantasie bei markup kann die datei schon mal doppelt so gross werden. DOM parser lesen die dateien vollstaendig ein und baun den parse tree draus, RAM ohne ende (gegenueber kaum RAM bei z.b. CSV). das kann man mit SAX parsern umgehen, die sind aber wieder umstaendlich zu handhaben.

beruehmte letzte worte.

XML geht wenn alle beteiligten wissen was sie tun und dabei keine fehler
machen. schoenes konzept, aber ausgesprochen praxisfern.

hehe

.

Mir prinzipiell aber unklar wo da soviel Fehler entstehen können ehrlich gesagt. XML ist doch recht verständlich aufgebaut.

man kann fuer vieles fehlertolerante parser schreiben. bei XML ist halt laut
spec fehlertoleranz ausgeschlossen, das macht es fuer sachen, bei denen es
nicht noetig ist dass immer alles fehlerfrei funktioniert nicht wirklich
brauchbar. in der praxis kann man bei den meisten XML parsern gewisse
toleranzen einschalten, dann stellt sich halt wieder die frage "warum dann
ueberhaupt XML"?

Warum XML ist prinzipiell eine gute Frage. Warum nicht Datenbankdumps durch die Gegend schicken, die würden ja prinzipiell immer stimmen, warum kein Excelfile parsen ? Das was ich jetzt aus der Praxis kenne - und da nutze ich XML sicher nicht so intensiv, bzw. sind die XML alle aus einer Quelle bzw. von einem Programm generiert, ist es einfach am praktischsten. Unsere Infrastruktur arbeitet sehr viel mit einem SOAP-ähnlichen Messageprotokoll. Da ist XML einfach unglaublich praktisch, egal was als Response daherkommt, ich kanns gut verpacken und weiterverarbeiten und auch nocht so, das wenn Fehler auftreten man den Fehler auch als Mensch sehen und untersuchen kann.

je nach phantasie bei markup kann die datei schon mal doppelt so gross werden.
DOM parser lesen die dateien vollstaendig ein und baun den parse tree draus,
RAM ohne ende (gegenueber kaum RAM bei z.b. CSV). das kann man mit SAX parsern
umgehen, die sind aber wieder umstaendlich zu handhaben

DOM nutze ich weder priv. noch beruflich, ist zwar sehr praktisch, aber nach etwas Übung mit einem SAX Parser bekommt man das auch gut hin.

Wie ich weiter oben schon schrieb: Von Sysadminseite aus ist mir CSV eh am liebsten, es ist einfach am praktischen auf unixoiden diese weiter zu verarbeiten.

lg.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Mir prinzipiell aber unklar wo da soviel Fehler entstehen können ehrlich gesagt. XML ist doch recht verständlich aufgebaut.

die haeufigsten probleme: encoding, entities, falsche interpretation davon was wie in CDATA stehen darf. well-formed schaffen die meisten, mehr aber nicht mehr.

man muss sich halt vor augen halten dass wir hier das ergebnis von zig (wenn nicht hunderten) verschiedenen shopsystemen verarbeiten, die qualitativ und groessenordnungsmaessig von hersteller "enterprise" bis "minderjaehriger cousin eines bekannten" reichen. dementsprechend fluktuiert der output.

[..] SOAP-ähnlichen Messageprotokoll.

ja, dafuer ist XML auch recht gut geeignet.

CSV eh am liebsten

zum uebertragen einfacher preislisten ist es auch bestens geeignet. wenig overhead, gut und einfach parsbar ohne besonders viel resourcen zu brauchen, auch fuer grosse dateien, ausreichend fehlertolerant, parser sind einfach parametrisierbar, usw.

Gab es doch schon alles - Stichwort "Elektra"; das Projekt war iirc sogar von Oesterreichern initiiert. Hat sich aber nicht durchgesetzt, u. a. wohl deshalb, weil die Idee stark behaemmert ist.

Es ist zwar nicht optimal, dass fast jedes kleine Programm und Utility seine eigene Aufruf- und Konfigurationssyntax und -grammatik mitbringt, aber das ist mir immer noch WESENTLICH lieber als irgendein win32 Registry Hive. Plaintextkonfiguration ist Koenig, koennte man sagen. Sprechende Bezeichner gibt es ja auch hier. Und nichts hindert dich daran, fuer ein solches Backend ein brauchbares GUI- oder TUI-Konfigurationstool zu entwerfen; KDE z. B. macht das sehr schoen vor.

Es ist zwar nicht optimal, dass fast jedes kleine Programm und Utility seine
eigene Aufruf- und Konfigurationssyntax und -grammatik mitbringt, aber das ist
mir immer noch WESENTLICH lieber als irgendein win32 Registry Hive.

Nicht nur Registry - die ich persönlich für einen absoluten Designfehler halte - es gibt ja auch auf properitären Unixen nicht lesbare Datenbanken, wo man dann den Hersteller bitten darf einem den Key zu sagen, weil sonst diverse virtualisierte Gschichtln ned gehn.

Was ich persönlich an Windows garned mag ist das es teilweise sehr sehr unsauber mit Pfaden umgeht (im gröberen Sinne). Dieses jedes Programm bringt seine eigenen Libs mit, die wiederrum in "irgendwelchen" Verzeichnissen rumkugeln ärgert mich gewaltig. Grad bei einem properitären System kann ich die Drittanbieter zwingen in die Verzeichnisse zu installieren die ich will.

Plaintextkonfiguration ist Koenig, koennte man sagen.

Es ist lustigerweise das was sich bis jetzt am längsten hält (obwohls wie mjy schon sagte eine Sauwirtschaft ist

).

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

http://wiki.debian.org/StableUpdates

ich meinte nicht stable-updates sondern stable/updates im security-Pfad...

Das ist einfach nur der Pfadname im Security-Archiv. Der liegt offenbar darin begruendet, dass es, wuerde das Repo einfach nur "squeeze" heiszen, es Probleme bei der Verzeichnisstruktur geben wuerde, wenn ein FTP-Mirror (FTP kann kein Name-based Virtual Hosting) sowohl das Squeeze-Repo als auch das Squeeze-Security-Repo vorhalten soll.

ja, aber warum heißt das nur im security-archiv stable/updates und nicht auch hier deb http://ftp.de.debian.org/debian/ stable main contrib non-free ?

Ich fuerchte, ich verstehe die Frage nicht...

"stable" ist nur ein Alias fuer die aktuell "stabile" Suite - momentan eben squeeze. Es klingt nicht so, als ob man dir erklaeren muesste, dass man einfach "stable" eintragen kann, und dann halt den "Vorteil" genieszt, beim dist-upgrade automatisch wheezy-Pakete installiert zu bekommen. Wenn man das nicht will, bleibt man eben beim Codename der Suite.

Inwiefern ergibt sich daraus in deinen Augen ein Widerspruch zur bzw. ein Problem mit der de-facto-Benamsung der security-Verzeichnisstrukturen?

dass stable derzeit das gleiche ist wie squeeze ist mir klar...

was ich nicht ganz verstehe ist warum einerseits stable/updates verwendet wird:

"deb _http://security.debian.org/ stable/updates main contrib non-free"

und andererseits nur stable:

"deb _http://ftp.de.debian.org/debian/ stable" main contrib non-free"

dieses stable/updates gibts ja nur im secuirty.debian.org-pfad oder?

24.04.2012, 20:40 Uhr - Editiert von User64693, alte Version: hier

Ich hab eigentlich versucht, genau diese Frage mit meinem vorletzten Posting in diesem Subthread zu beantworten

Die einzig rationale Begruendung ist die, dass man somit auf dem selben FTP-Server _sowohl_ das Debian stable "main" repository, _als auch_ das Debian stable security repository hosten kann. Wuerde man das top-level-dir fuer letzteres nicht in stable/updates verlegen, wuerde es da zu Ueberschneidungen der Verzeichnisnamen und damit auch -inhalte zwischen den Repositories kommen.

ok - ich glaub jetzt hab ichs verstanden...

dank dir für die Erklärung!

derzeit wird stable/updates aber nur auf dem http://security.debian.org Server gehostet - oder?

Achtung, tw. unverifiziertes Halbwissen folgt:

"security" hat afaik eine eigene Mirror-Policy (kuerzere Zyklen) und deshalb einen eigenen Hostnamen bzw. DNS-RR. Das muessen deshalb (auf IP-Ebene) nicht zwingend andere Server sein als jene, auf denen auch die "main"-Repos und Konsorten liegen - via HTTP (dank VHost-Support) ist das ja ohne Probleme moeglich. Nur im Falle des Bezugs der Archivdaten ueber FTP (soll ja immer noch Leute geben, die diesen verkrusteten Schund verwenden...) kann es zum vorhin beschriebenen Problem kommen, da du ueber dieses Protokoll immer im selben "Namespace" landest.

echt super support hier im forum

danke nochmals...

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung