~caskd

Germany

https://redxen.eu

19, POSIX compliant sysadmin, zsh hacker and C dev.

~caskd/redxen-announce

Last active 1 year, 8 months ago

~caskd/redxen-discuss

Last active 2 years ago

~caskd/redxen-devel

Last active 2 years ago
View more

Recent activity

Re: IPv6 DNS in docker.io/alpine 8 months ago

From caskd to ~sircmpwn/alpine-devel

> isn't the resolv.conf in a started container populated on start depending on the
> networking configuration?
> 
> e.g. with --network=host it just uses your current /etc/resolv.conf. without it,
> it depends on how the networking for containers is set up, ...
> 
> the actual images are just the unpacked minirootfs, made with mkimg.minirootfs.sh,
> but i don't think that touches resolv.conf at all.
Indeed. I've started looking deeper and completly missed the upper layer where the actual change happens. This is irrelevant now.

-- 
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/

IPv6 DNS in docker.io/alpine 8 months ago

From caskd to ~sircmpwn/alpine-devel

Hello everyone,

i've been trying to pin down where the resolv.conf in the docker image is coming from without success. I've been looking into submitting a request to add IPv6 addresses to the default too to allow containers with IPv6 only connectivity to resolve without deriving a image from the base.

Could you help me pin down where the build scripts/Dockerfile for these are and would adding IPv6 as a fallback cause problems?

-- 
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/

Re: [PATCH v7] Support encrypted root in setup-disk 2 years ago

From caskd to ~sircmpwn/alpine-devel

> > > +	cryptsetup open "$dev" "$dmname" >&2
> > > +	echo "/dev/mapper/$dmname"
> > I would check that the device is unlocked properly here and if not,
> > prompt for a retry.
> 
> Is this really needed? cryptsetup open prompts for a retry when it fails.
Oh right, i have forgot about that. In that case the format should use the -y argument so that the entire setup doesn't have to be restarted due to a mistyped password during the format.

-- 
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/

Re: [PATCH v7] Support encrypted root in setup-disk 2 years ago

From Alex Denes to ~sircmpwn/alpine-devel

Hello,

Thanks for the patch and contribution. I've added my feedback to everything below.

> I have tested the script with syslinux (no EFI). Now there is a question
> about making it work with GRUB (EFI). This would require:
> 
> 1. changing luksFormat type to luks1 as GRUB2 does not support luks2;
GRUB has recently added support for luks2 but the mkimage wrapper doesn't include the required modules so the support is not as automated as it should be.
I would instead go for a encrypted root with a unencrypted /boot to avoid using luks1 for everything and it would simplify the setup. This is not "full-disk" encryption as one would want but it doesn't have the limitation that luks1 has.

"LUKS provides a generic key store on the dedicated area on a disk, with the ability to use multiple passphrases to unlock a stored key. LUKS2 extends this concept for more flexible ways of storing metadata, redundant information to provide recovery in the case of corruption in a metadata area, and an interface to store externally managed metadata for integration with other tools."

https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf