[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[ITT] po4a://ladder/fr.po



Le samedi 09 juin 2012 à 15:29 -0400, David Prévot a écrit :
> Salut,
> 
> Le 01/06/2012 16:22, David Prévot a écrit :
> > Le 05/05/2012 20:33, Jacques Charles a écrit :
> >> Le samedi 5 mai 2012, David Prévot a écrit :
> 
> >> La documentation de ladder [0] n'est pas encore traduite en français.
> > 
> >>        0 : http://www.debian.org/international/l10n/po4a/pot#ladder
> 
> Sans nouvelles de Jacques, la personne volontaire pour s'occuper de
> cette traduction peut commencer par répondre au message avec le sujet
> (sans Re:) :
> 
> 	[ITT] po4a://ladder/fr.po
> 
> >> Comment procéder pour traduire :
> > 
> >> - éditer et traduire le fichier disponible à l'URL précédente
> > [...]
> >> - envoyer le fichier ici pour relecture avec le sujet
> > 
> >>        [RFR] po4a://ladder/fr.po
> 
> [ Cf. [MAJ] <4FA527B3.6010809@tilapin.org> initial ou en ligne [1] pour
> le reste des instructions. ]
> 
> Amicalement
> 
> David
> 
> 	1 : http://www.debian.org/international/french/traduire
> 
> 
J'ai trouvé ce fichier POT à l'adresse citée ; est-ce bien la dernière
version ?

JC
# SOME DESCRIPTIVE TITLE
# Copyright (C) YEAR Free Software Foundation, Inc.
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2012-03-12 21:53+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"

#. type: =head1
#: ladder:374
msgid "NAME"
msgstr ""

#. type: textblock
#: ladder:376
msgid "Ladder - creates migration repositories for software release sets"
msgstr ""

#. type: =head1
#: ladder:378
msgid "Description"
msgstr ""

#. type: textblock
#: ladder:380
msgid ""
"Ladder creates a SecureApt repository to migrate production devices from one "
"release milestone to the next. The repository contains all binary packages "
"which would be installed to upgrade the target package of the specified "
"release, including base packages. Source packages are not included as this "
"would make the final tarball much larger than necessary. Sources should "
"remain available via the main repositories."
msgstr ""

#. type: textblock
#: ladder:387
msgid ""
"For the purposes of C<ladder>, the bare installation / rootfs should be "
"considered to always precede the first software release. Subsequent steps "
"can then be based on the tarball of the previous milestone."
msgstr ""

#. type: textblock
#: ladder:391
msgid ""
"Note that if using C<multistrap> or a foreign architecture C<debootstrap>, "
"ensure that the rootfs inside the tarball is B<configured> and repacked "
"before being used with C<ladder>. i.e.  use the production tarball rather "
"than the build system tarball."
msgstr ""

#. type: textblock
#: ladder:396
msgid ""
"Ladder checks the installed package list from the production tarball for "
"that release, calculates the packages needed to migrate to the specified "
"milestone and prepares a repository containing those packages, including all "
"dependencies."
msgstr ""

#. type: textblock
#: ladder:401
msgid ""
"If the specified package list and the specified milestone are B<NOT> "
"contiguous, errors can result if some of the contained packages need to "
"migrate between data formats. For most cases, create a ladder step for each "
"software release and upgrade devices in the same sequence.  C<ladder> steps "
"can be chained by modifying the update scripts."
msgstr ""

#. type: =head1
#: ladder:407
msgid "Config files"
msgstr ""

#. type: textblock
#: ladder:409
msgid ""
"Ladder configuration files live in F</etc/ladder.d/> and need to be named "
"after the release described. e.g. F</etc/ladder.d/internal.conf>."
msgstr ""

#. type: textblock
#: ladder:412
msgid "A minimal file to upgrade to Debian sid could look like:"
msgstr ""

#. type: verbatim
#: ladder:414
#, no-wrap
msgid ""
" [sid]\n"
" suite=unstable\n"
" location=http://ftp.uk.debian.org/debian\n";
" targetpackage=apt\n"
"\n"
msgstr ""

#. type: textblock
#: ladder:419
msgid "A more comprehensive config file could look like:"
msgstr ""

#. type: verbatim
#: ladder:421
#, no-wrap
msgid ""
" [internal]\n"
" suite=interim\n"
" codename=milestone\n"
" branch=software_release_4\n"
" key=0xDEADBEEF\n"
" keyringdir=keys\n"
" location=copy:///srv/repo\n"
" rootpackage=libfoo3\n"
" targetpackage=metapackage\n"
" extrapackages=bar baz other\n"
" updatescript=true\n"
" mountpoint=/media/ladder\n"
"\n"
msgstr ""

#. type: textblock
#: ladder:434
msgid ""
"(It is possible to list more than one package, as a space separated list.  "
"Commas or other markers will not be parsed by apt.)"
msgstr ""

#. type: textblock
#: ladder:437
msgid ""
"The section name (e.g. internal in the example above) is used as the "
"milestone name, which can differ from the suite name and the branch name."
msgstr ""

#. type: textblock
#: ladder:441
msgid ""
"For more information on the key and keyringdir options, see the section on "
"SecureApt below."
msgstr ""

#. type: =head1
#: ladder:444
msgid "Requirements"
msgstr ""

#. type: textblock
#: ladder:446
msgid ""
"The rootfs is expected to carry some existing apt sources, the location "
"specified in the config file should be the one additional source which "
"provides the updated packages and the expectation is that this will have a "
"different suite name to the suite configured in the rootfs. If the location "
"and suite are the same, C<apt> will print messages about duplicate source "
"lists but these messages can be ignored."
msgstr ""

#. type: textblock
#: ladder:453
msgid ""
"In order for apt to calculate the packages needed for the update, B<all> "
"repositories which are enabled in the rootfs tarball B<including> the "
"location specified in the config file B<must be accessible> on the machine "
"running C<ladder>."
msgstr ""

#. type: =head1
#: ladder:458
msgid "Deployment of ladder tarballs"
msgstr ""

#. type: textblock
#: ladder:460
msgid ""
"The final tarball contains an example apt source showing the syntax which "
"would be suitable for use with the packaged repository. The full path will "
"need to be specified in the final sources list file.  e.g."
msgstr ""

#. type: verbatim
#: ladder:465
#, no-wrap
msgid ""
" deb copy:///milestone suite main\n"
" \n"
msgstr ""

#. type: textblock
#: ladder:467
msgid "May need to be modified to:"
msgstr ""

#. type: verbatim
#: ladder:469
#, no-wrap
msgid ""
" deb copy:///media/usb0/milestone suite main \n"
"\n"
msgstr ""

#. type: textblock
#: ladder:471
msgid "The example source is packaged as F<ladder.list> in the tarball."
msgstr ""

#. type: textblock
#: ladder:473
msgid ""
"The key should normally already be part of a keyring package and installed "
"on the devices. If not, an exported copy of the public key is also included "
"in the tarball which can be included into the device keyring using "
"C<apt-key> (which needs to be run as root):"
msgstr ""

#. type: verbatim
#: ladder:478
#, no-wrap
msgid ""
" apt-key add /path/milestone/ladder.gpg\n"
"\n"
msgstr ""

#. type: textblock
#: ladder:480
msgid ""
"Some scripting / programming support will be needed to make this process "
"seamless on-device, in particular to provide the knowledge of the actual "
"sequence of milestone names, but this is beyond the scope of C<ladder>, if "
"only because the ladder tarball needs to be unpacked first."
msgstr ""

#. type: textblock
#: ladder:486
msgid ""
"If the system is set with some standard apt sources already, the upgrade "
"will need to only allow C<apt-get> to see the ladder repository (because the "
"normal network connection isn't available, so the update would fail).  To do "
"this, use apt command line options to reset the location of the SourceList "
"and SourceParts:"
msgstr ""

#. type: verbatim
#: ladder:492
#, no-wrap
msgid ""
" apt-get -o Dir::Etc::SourceList=ladder.list -o Dir::Etc::SourceParts=./dir/ "
"update\n"
"\n"
msgstr ""

#. type: textblock
#: ladder:494
msgid ""
"(F<./dir/> should be an empty directory - or a directory containing empty "
"F<.list> files and nothing else.)"
msgstr ""

#. type: textblock
#: ladder:497
msgid ""
"The only requirements to use the ladder tarball are to create the relevant "
"source list file, ensure the key is available and then call apt-get update; "
"apt-get upgrade. There is no need for perl, reprepro or anything else used "
"by C<ladder> itself."
msgstr ""

#. type: =head1
#: ladder:502
msgid "Example update script"
msgstr ""

#. type: textblock
#: ladder:504
msgid ""
"If the configuration file includes the C<updatescript> option an example "
"script will be included, listing the value of the C<rootpackage> option to "
"be removed. If the C<mountpoint> option is set, the F<DIR> variable will be "
"set in the example script as well. (You may need to invest time in a C<udev> "
"rule as part of your rootfs to get a known mount point but such rules are "
"beyond the scope of this documentation.)"
msgstr ""

#. type: verbatim
#: ladder:511
#, no-wrap
msgid ""
" #!/bin/sh\n"
" \n"
msgstr ""

#. type: verbatim
#: ladder:513
#, no-wrap
msgid ""
" set -e\n"
" DIR=/media/ladder\n"
" ROOTPKG=\n"
" CONFIG=-y -o Dir::Etc::SourceList=${DIR}/ladder.list -o "
"Dir::Etc::SourceParts=${DIR}/list.d/\n"
" apt-key add ${DIR}/pubkey.asc\n"
" apt-get ${CONFIG} update\n"
" if [ -n \"$ROOTPKG\" ]; then\n"
"    apt-get ${CONFIG} --purge autoremove $ROOTPKG\n"
" fi\n"
" apt-get ${CONFIG} dist-upgrade\n"
" apt-get ${CONFIG} autoclean\n"
"\n"
msgstr ""

#. type: =head1
#: ladder:525
msgid "SecureApt"
msgstr ""

#. type: textblock
#: ladder:527
msgid ""
"Signing a ladder step repository requires that the secret key is usable "
"without a passphrase and that the secret key is accessible to the root user, "
"either directly or via sudo."
msgstr ""

#. type: textblock
#: ladder:531
msgid ""
"As with anything related to GnuPG, protecting the secret key is the sole "
"responsibility of the key owner. It is recommended that ladder steps are "
"only created in a secure environment comparable with that used to generate "
"the keys. The same requirements apply to the machines which use the secret "
"key to sign the internal milestone repositories, so it may be appropriate to "
"create ladder steps on those machines."
msgstr ""

#. type: =item
#: ladder:540
msgid "Specifying a keyring directory and key ID"
msgstr ""

#. type: textblock
#: ladder:542
msgid ""
"If C<keyringdir> is used, the specified directory must contain the public "
"and secret keyrings which contain the specified C<key>. C<ladder> will then "
"make both the secret key and public key accessible to the root user using a "
"temporary keyring in F</var/lib/ladder/keys>. Only the key available in "
"F</var/lib/ladder/keys> will be available to the repository signing "
"process. C<ladder> only needs to be able to read the secret and public "
"keyrings of the F<keyringdir> specified. Ensure that the secret key is "
"available - B<without a passphrase> - or the repository will not be signed."
msgstr ""

#. type: =item
#: ladder:552
msgid "Using just a key ID"
msgstr ""

#. type: textblock
#: ladder:554
msgid ""
"If C<keyringdir> is B<not> used, the user must ensure that the key is "
"available to the root user as ladder requires sudo/root to be able to use "
"apt. Ensure that the specified secret key is available - B<without a "
"passphrase> - to the root user or the repository will not be signed."
msgstr ""

#. type: verbatim
#: ladder:560
#, no-wrap
msgid ""
" sudo gpg --list-secret-key KEYID\n"
"\n"
msgstr ""

#. type: textblock
#: ladder:562
msgid "Using C<keyringdir> is generally the easiest option."
msgstr ""

#. type: textblock
#: ladder:566
msgid ""
"If the key is not available, the repository simply won't be signed and "
"devices would need to pass the AllowUnauthenticated option to C<apt-get> "
"when using the ladder repository. B<ladder does not add the unauthenticated "
"option to generated upgrade scripts!> You can tell a SecureApt repository by "
"the presence of the F<Release.gpg> file."
msgstr ""

#. type: textblock
#: ladder:573
msgid ""
"It is possible to auto-generate GnuPG keys but C<ladder> does not support "
"this currently. The main problem is entropy - generating a new GnuPG (or "
"SSH) key requires a lot of entropy, especially as default key lengths "
"increase. It is a lot easier to ensure high entropy when the key generation "
"process is interactive."
msgstr ""

#. type: =head2
#: ladder:579
msgid "Keyring packages are recommended"
msgstr ""

#. type: textblock
#: ladder:581
msgid ""
"With careful planning, the security of the step upgrades can be much "
"improved by modifying the update scripts to B<not> add the signing key using "
"C<apt-key add> but instead to provide a keyring package in the rootfs itself "
"which contains the public key which will be used to sign the next "
"milestone. This is how Debian arranges keys - the release of milestone A is "
"not made until the key which will be used to sign milestone B has the "
"corresponding public key already included in the keyring package in "
"milestone A."
msgstr ""

#. type: textblock
#: ladder:590
msgid ""
"Such keyring packages themselves need to be in the milestone repository "
"because then the keyring package itself is protected by SecureApt."
msgstr ""

#. type: textblock
#: ladder:593
msgid ""
"Note that keyring packages will make it harder to use the downgrade solution "
"explained below, hence the need for planning."
msgstr ""

#. type: =head2
#: ladder:596
msgid "Key expiries"
msgstr ""

#. type: textblock
#: ladder:598
msgid ""
"Key expiry dates will complicate C<ladder> usage, especially if downgrades "
"are to be available. If a device was released on milestone D and needs to be "
"downgraded to milestone B, you will have problems if the key used to sign "
"milestone B has since expired. Equally, repairing or servicing a device "
"running milestone B becomes problematic if the key for milestone B has "
"expired whilst the device was in use."
msgstr ""

#. type: textblock
#: ladder:605
msgid ""
"Avoid using expiry dates on keys unless you are very, very confident that a "
"particular milestone will not be in use after a certain date."
msgstr ""

#. type: =head2
#: ladder:608
msgid "Key management"
msgstr ""

#. type: textblock
#: ladder:610
msgid ""
"Keys can be revoked but this relies on the devices which need to verify that "
"key being able to download the revocation certificate and then to still have "
"a usable key available for the upgrade. Consider revoking the key for "
"milestone B in the version of the keyring package released with milestone D "
"(milestone C still needs it to be able to upgrade). This allows keys to be "
"revoked on-device but still be usable should it become necessary to repair, "
"service or downgrade."
msgstr ""

#. type: textblock
#: ladder:618
msgid ""
"If a key is compromised, then unless the keyring package in any one "
"milestone still includes a usable key, there may be no way of securely "
"upgrading devices without manually adding a replacement key. Take care of "
"your secret keys."
msgstr ""

#. type: =head1
#: ladder:623
msgid "Steps and milestones"
msgstr ""

#. type: textblock
#: ladder:625
msgid ""
"Ladder - as with Debian - only works forwards. Downgrades are not "
"supported. If the rootfs tarball contains an existing apt source which "
"contains packages B<NEWER> than the requested milestone, then the packages "
"downloaded will be for the existing apt source, not the milestone. Check the "
"output with the C<-n|--dry-run> option."
msgstr ""

#. type: textblock
#: ladder:631
msgid ""
"However, judicious use of the C<rootpackage> option can assist with limited "
"downgrades - especially when the software being downgraded is under your own "
"control. The generated B<updatescript> can use C<apt-get --purge autoremove> "
"on the root package. Specifying a core library or special platform "
"dependency package here can allow the rootfs to be returned to a pristine "
"state. The required milestone can then be installed as if from a clean "
"base. This is not quite the same as an explicit downgrade but is a much more "
"reliable mechanism as it provides the equivalent rootfs to when the original "
"milestone was created."
msgstr ""

#. type: textblock
#: ladder:641
msgid ""
"For these reasons, B<always> keep a copy of the original clean rootfs which "
"has no complicating apt sources."
msgstr ""

#. type: textblock
#: ladder:644
msgid ""
"If your root package is a shared library, you can specify multiple root "
"packages in the config file so that all released SONAME versions are "
"removed. Use only spaces to separate packages in the config file."
msgstr ""

#. type: textblock
#: ladder:648
msgid ""
"If you are using keyring packages, ensure that a suitable keyring package is "
"available to the ladder step which purges the root package.  To be able to "
"upgrade to the end milestone from a purged rootfs, the keyring package first "
"needs to be upgraded to include the key used to sign the end milestone "
"(although the upgraded keyring package is free to include revoked copies of "
"intermediary keys, if appropriate)."
msgstr ""

#. type: =head1
#: ladder:655
msgid "Output"
msgstr ""

#. type: textblock
#: ladder:657
msgid ""
"Ladder works in the F</var/lib/ladder> directory, unpacking the tarball into "
"F<./rootfs> and creating the repository in a directory named after the "
"milestone."
msgstr ""

#. type: textblock
#: ladder:661
msgid "Results will be F</var/lib/ladder/ladder-$name.tgz>"
msgstr ""

#. type: =head1
#: ladder:663
msgid "Support"
msgstr ""

#. type: textblock
#: ladder:665
msgid ""
"C<ladder> was written with a specific purpose in mind but is available in "
"Debian in the hope it will be useful for other situations as well.  If there "
"are specific situations where C<ladder> could be extended to be more useful "
"for others, let me know using the Debian bug tracking system: "
"F<bugs.debian.org/ladder>."
msgstr ""

#. type: textblock
#: ladder:671
msgid ""
"Note that C<reprepro> already has B<snapshot> support which is not the same "
"as a C<ladder> of milestones. Snapshots include full sources and ancillary "
"packages which are not needed on-device and are intended for build systems "
"and developer use - ladder milestones are intended to provide a small "
"repository which can be used on machines after production."
msgstr ""

Reply to: