August 2023

New Tumbleweed snapshot 20230731 released!
by Dominique Leuenberger 01 Aug '23

01 Aug '23

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/… [View More]

1 0

Re: missing Tumbleweed snapshot release announcements
by Eric Schwarzenbach 01 Aug '23

01 Aug '23

On 7/31/23 14:12, Jan Engelhardt wrote: > On Monday 2023-07-31 18:34, Bernhard M. Wiedemann via openSUSE Factory wrote: > >> On 31/07/2023 18.17, Eric Schwarzenbach wrote: >>> Are these snapshot release announcements also posted anywhere on the web? >> You can get the missing ones with >> >> curl https://download.opensuse.org/tumbleweed/iso/Changes.20230727.txt >> curl https://download.opensuse.org/tumbleweed/iso/Changes.20230728.txt > https://… [View More]

2 1

Re: Disk auto-unlocking with TPM 2.0
by Georg Schukat 01 Aug '23

01 Aug '23

> Am 31.07.2023 um 15:35 schrieb factory-request(a)lists.opensuse.org: > > Re: Disk auto-unlocking with TPM 2.0 > I set up a few remotely managed servers by moving all of the important > data to LUKS encrypted filesystems. These filesystems aren't in /etc/fstab > so they don't get mounted after a reboot. Once rebooted I remotely > SSH in and run a script that mounts the encrypted filesystem that prompts > for the password. It then starts the appropriate daemons (… [View More]Postgresql, etc) > and everything is fine. I know there's a possibility of data leakage > via /tmp and swap, but I think the risk is minimal and the servers are in > a protected space anyway. I wonder if swap and /tmp could be encrypted > this way too, it might be fun to fiddle with it someday? > > So the basic idea is to set up a server so that it partially boots, but boots > far enough to set up the network and start the SSH daemon. Then, log > in remotely to finish the rest of the boot after entering the LUKS password. > Could something like this be added to the Leap install process to make it > easier to set up? > > Regards, > Lew > You can go further, a sshd can be started from grub. I have 2 servers running in that mode. My logs how I did set that up are not 100% complete so I can only give hints. Core component is the package dracut-sshd For documentation see: https://github.com/gsauthof/dracut-sshd It shows you several options how to setup your remote server. In general either use early networkd or setup your network in the initrd command line. Further documentation about network configuration within initrd can be found at the "other Linux" site: https://www.redhat.com/sysadmin/network-confi-initrd Would be then similar to: in `/etc/default/grub` modify `GRUB_CMDLINE_LINUX` to include network configs: E.g. GRUB_CMDLINE_LINUX="rd.neednet=1 ip=..." Furtheron you have to create ssh client keyfiles and integrate the public key file into the servers list of known client keys. Details see above mentioned docs That way all partitions besides boot and boot/efi can be encrypted at boot and you get this nice boot prompt when you ssh into that server at boot: Welcome to the early boot SSH environment. You may type systemd-tty-ask-password-agent (or press "arrow up") to unlock your disks. This shell will terminate automatically a few seconds after the unlocking process has succeeded and when the boot proceeds. If you do so you will be prompted for the password of one encrypted disk, more if they have different ones. Grub will decrypt now the disks the same way if you would have entered the passwords sitting at the console. [View Less]

3 2

Main

Development

Information

Community

Social Media

Other

openSUSE Factory