[Grml] (grml-)debootstrap network timeout / retry settings?

[adrelanos]

Hi,

is it possible to add apt-like options to (grml-)debootstrap to get
higher timeouts / more retries when network is slow / flaky?

Options comparable to "--option Acquire::http::Timeout=180" or "--option
Acquire::Retries=3"?

Cheers,
adrelanos

[Michael Prokop]

Post by adrelanos
is it possible to add apt-like options to (grml-)debootstrap to get
higher timeouts / more retries when network is slow / flaky?
Options comparable to "--option Acquire::http::Timeout=180" or "--option
Acquire::Retries=3"?

What you're searching for should be possible via
the DPKG_OPTIONS setting.

regards,
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml/attachments/20131005/1b1b56d1/attachment.sig>

[adrelanos]

Post by Michael Prokop

Post by adrelanos
is it possible to add apt-like options to (grml-)debootstrap to get
higher timeouts / more retries when network is slow / flaky?
Options comparable to "--option Acquire::http::Timeout=180" or "--option
Acquire::Retries=3"?

What you're searching for should be possible via
the DPKG_OPTIONS setting.

Thanks for your reply.

I don't think this can work. grml-debootstrap itself (I checked
/usr/sbin/grml-debootstrap) does not use any network on its own? No
wget, no curl, no dpkg, no apt-get as far I can see. That's all
delegated to debootstrap?

I also checked /usr/sbin/debootstrap and
/usr/share/debootstrap/functions. Seems like debootstrap doesn't use
dpkg/apt-get either. The only point where it seems to use code to use
the network seems to be in /usr/share/debootstrap/functions using wget.

Also I couldn't find any documentation about the DPKG_OPTIONS variable.
And as far I know, dpkg can't download packages on it's own and apt-get
is unlikely to obey DPKG_OPTIONS?

When grml-debootstrap doesn't use any network on its own (please
confirm), maybe this question should be rephrased as feature request for
debootstrap?

[Michael Prokop]

Post by adrelanos
I don't think this can work. grml-debootstrap itself (I checked
/usr/sbin/grml-debootstrap) does not use any network on its own? No
wget, no curl, no dpkg, no apt-get as far I can see. That's all
delegated to debootstrap?

Yes, and apt-get/aptitude as used after the debootstrap stage.

Post by adrelanos
I also checked /usr/sbin/debootstrap and
/usr/share/debootstrap/functions. Seems like debootstrap doesn't use
dpkg/apt-get either. The only point where it seems to use code to use
the network seems to be in /usr/share/debootstrap/functions using wget.
Also I couldn't find any documentation about the DPKG_OPTIONS variable.
And as far I know, dpkg can't download packages on it's own and apt-get
is unlikely to obey DPKG_OPTIONS?

The DPKG_OPTIONS variable is "documented" inside
/etc/debootstrap/config:

# Pass extra options to aptitude/apt-get.
# Default: no default.
# DPKG_OPTIONS='-o APT::Get::AllowUnauthenticated=true -o aptitude::Cmdline::ignore-trust-violations=yes'

So you can set it to whatever you like to control the usage of
apt-get/aptitude as invoked inside grml-debootstrap's chroot-script.

You can also set DEBOOTSTRAP_OPT or use the --debopt command line
switch to set additional debootstrap options, so whatever is
supported by deboostrap itself can be controlled here.

Post by adrelanos
When grml-debootstrap doesn't use any network on its own (please
confirm), maybe this question should be rephrased as feature request for
debootstrap?

Yes, besides one simple wget call when using the --backportrepos
option there are no extra network requests by grml-debootstrap
itself. So if you want to get a better network behaviour support in
debootstrap itself please file it as feature request for debootstrap
upstream.

regards,
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml/attachments/20131009/0286203f/attachment.sig>