This document describes the legacy HTTP CGI-based API used by older SynAccess netBooter PDU models such as the NP-0201DU. This API is different from the newer SynLink Smart PDU REST API.
admin / admin192.168.1.100
Landlock is a Linux Security Module (LSM) that enables unprivileged processes to create security sandboxes by restricting filesystem and network access. This document explains how Landlock works across kernel versions 6.1, 6.6, and 6.12, highlighting the evolution of features and practical examples for C application development.
After setting up a Debian system which did not choose to use encryption during the installer, do these steps to encrypt sda3 partition so we have encrypted rootfs. Follow these steps when booted from another disk so we can off-line encrypt the rootfs:
mount /dev/sda3 /mntbtrfs filesystem show --mbytes /mntbtrfs filesystem resize 1:-32M /mntbtrfs filesystem show --mbytes /mntumount /mntbtrfs check /dev/sda3cryptsetup reencrypt --encrypt --verify-passphrase --reduce-device-size 32M /dev/sda3
I have 2 Yubikeys which support the OpenPGP card capability. I want to have a robust GnuPG solution which allows me to store one of the keys in a safe place and to carry the other key with me daily on my physical keychain. I want to be able to fairly easily survive having the daily carry Yubikey be stolen, lost, or simply fail, by revoking those keys. I also want to be able to survive having the safely stored key fail by revoking those keys.
My original plan was to create a main key pair and 2 sets of encryption and authentication subkeys (4 total, 2 enc and 2 auth). The main key pair and one set of the encryption and authentication keys would be transferred to each Yubikey, so each Yubikey would share the common main key pair but have a different set of encryption and authentication subkeys. This turns out to be quite difficult to implement in a secure way due to how GnuPG's key-to-card functionality works. GnuPG expects if you transfer a key to a card that you want that key to only live on that card an
If the Linux kernel is compiled with the EFI stub loader (grep CONFIG_EFI_STUB /boot/config-*), then an EFI BIOS can boot the kernel directly, without the need for a bootloader like GRUB. This only requires that the kernel and the initrd exist on the EFI partition. The EFI boot menu and boot order can be managed with the command-line utility efibootmgr.
Copying the kernel image and initrd onto the EFI partition the first time is simple; the problem is keeping them up-to-date as the system is updated. In particular, lots of software packages can trigger the initrd to be rebuilt. The most recent kernel image and initrd need to be copied to the EFI partition every time they are updated.
The Debian Linux Kernel Handbook documents initramfs hooks, stating that "Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/initramfs/post-update.d
| Read start4.elf bytes 2243232 hnd 0x0000021d | |
| Read fixup4.dat bytes 5351 hnd 0x0000021b | |
| Firmware: 0403e22018aafab833d0a16374ac773f66fd7be9 Oct 19 2021 11:50:10 | |
| 0x00d03114 0x00000000 0x00000fff | |
| MEM GPU: 76 ARM: 947 TOTAL: 1023 | |
| Starting start4.elf @ 0xfeb00200 partition 0 | |
| + | |
| MESS:00:00:04.964546:0: brfs: File read: /mfs/sd/config.txt | |
| MESS:00:00:04.967336:0: brfs: File read: 206 bytes |
I'm speaking into the Antlion ModMic Business connected to a Schiit Audio Fulla 3 USB sound interface and recorded by Audacity. I've set the mic input level about 3dB down which is about 89%. The microphone is 2 fingers width away from my face.
Now I'll toggle the in-line mute on and repeat the first 3 sentences of my review.
And now I've turned the mute back off. Hope this is helpful!
Create a bootable USB flash drive for generating and managing PGP keys. The keys will be generated and stored, encrypted, on the drive but then also transferred to Yubikeys for general use. Unless a Yubikey is lost or damaged, use of the flash drive should be extremely limited, if it is used at all.
A master certifying and signing (CS) key will be created, then sub-key signing (S), encrypting (E), and authenticating (A) keys will be created and signed by the C key. The C key will be archived with a password to the flash drive as well as transferred to a Yubikey 4. The SE&A sub keys will also be archived to the flash drive as part of the C key
In the longer term, I could see us having the possibility of leveraging Github more. Currently the trac.clfs.org web page has a perception of lacking in functionality, for instance it's very hard to tell someone how to go from the front page of trac to reading the current development version of the books online. Migrating everything from trac onto Github is an option in order to reduce maintenance burden of the trac instance. Additionally, instead of relying on the existing git hooks and existing clfs.org book building infrastructure, we could host the built books on Github pages and use something like Travis to do the building of that. Github pages can also be setup for the cross-lfs group on Github to take the place of what the trac instance has been used for in the past, mainly as a presence on the web and directing visitors on how to read/contribute to the books. The only aspect which I don't feel Github could serve all of the project's needs is with mailing lists.
I don't want to push for moving ev
To setup a YubiKey 4 and YubiKey 5 NFC to both authenticate myself for the following services: