Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Hollow Talk
Feb 2, 2014

I swear I had a list somewhere! :confused:

ninja-edit: great post, great snipe

Adbot
ADBOT LOVES YOU

Saukkis
May 16, 2003

Unless I'm on the inside curve pointing straight at oncoming traffic the high beams stay on and I laugh at your puny protest flashes.
I am Most Important Man. Most Important Man in the World.

Bob Morales posted:

Random-rear end question, somewhat related to Linux:

How do you guys keep all your USB drives straight?

I bought keyring tags. Printed labels are also nice solution, but I usually don't have a label printer nearby.

Only registered members can see post attachments!

Antigravitas
Dec 8, 2019

Die Rettung fuer die Landwirte:

Bob Morales posted:

Random-rear end question, somewhat related to Linux:

How do you guys keep all your USB drives straight?

Which one has CentOS 7? CentOS 8? Fedora? Ubuntu? VMware ESX?

I guess I could find some cheap ones and just stick a Brother label on them, but some of mine are those tiny Sandisk drives

I PXE boot if I have to boot an OS, which I usually don't need to.

MS MDT boots via wimboot from iPXE, the other Linux crap just boots directly from iPXE.

I admit not everyone has the time to set this kind of thing up, but it's amazingly convenient.

(The boot menu is also behind a login that authenticates against MS AD, everything is TLS encrypted after the initial bootstrap of the iPXE binary)

I have a USB drive. It has iPXE on it, to run on systems that can't PXE for some reason.

namlosh
Feb 11, 2014

I name this haircut "The Sad Rhino".

Antigravitas posted:

I PXE boot if I have to boot an OS, which I usually don't need to.

MS MDT boots via wimboot from iPXE, the other Linux crap just boots directly from iPXE.

I admit not everyone has the time to set this kind of thing up, but it's amazingly convenient.

(The boot menu is also behind a login that authenticates against MS AD, everything is TLS encrypted after the initial bootstrap of the iPXE binary)

I have a USB drive. It has iPXE on it, to run on systems that can't PXE for some reason.

How much time are we talking? Like without the whole AD part? That sounds like Nirvana

Volguus
Mar 3, 2009

xzzy posted:

I gave up years ago and keep a single usb key, and dd over the top of it with whatever image solves my current problem.

The correct answer. Also, replace said usb key when it starts throwing weird errors.
Got a job few months ago at a company as a C++ developer. So far I've been writing bash, ash (busybox shell) and python scripts (with a smattering of C++), for their in-house debian-based distribution. I've been flashing a USB drive that I had for 5+ years at least 20 times a day to install and reinstall the distribution (working on installer and early-boot guts). After a while I saw reading errors being spit on the terminal and the write speed slowed down quite a bit. gently caress it, buy a new one and expense it.

mystes
May 31, 2006

How often do you people boot from usb drives that the images aren't already out of date when you need them?

CaptainSarcastic
Jul 6, 2013



mystes posted:

How often do you people boot from usb drives that the images aren't already out of date when you need them?

For me it isn't just boot drives, but drives I've used to transfer files from one machine to another for safe-keeping but I can't remember exactly what drive on which computer, so I'm loath to blank them if I don't have to. Or drives that are kind of archival, like old school papers and such. Or drives that I can't remember the capacity until I plug them in (hello 1GB drive from yesteryear!). Stuff like that.

Happy Thread
Jul 10, 2005

by Fluffdaddy
Plaster Town Cop
What's the correct protocol for dealing with a flash drive that is possibly infected with malware? Erasing it, formatting it. I'm using Ubuntu 20.04; assume I'm new to it.

I guess the hardware could have bad extra stuff designed into it that lingers even after a format, but I'll think about that next.

Antigravitas
Dec 8, 2019

Die Rettung fuer die Landwirte:

namlosh posted:

How much time are we talking? Like without the whole AD part? That sounds like Nirvana

Most of the time is spent trying to get at the exact magic kernel parameters required to initiate a PXE boot, because the kernel/initrd needs to know that it has to fetch its squashfs first and that's kind of standardised but not really.

The AD thing is just Apache configured with basic auth via LDAP against a domain controller. That is the easy part.

The process is:
* Client requests DHCP
* DHCP server answers with the normal DHCP offer and PXE file location
* Client fetches file via tftp and executes it
* iPXE (in our case) executes an embedded script that runs DHCP again, then fetches a script via https that contains the login screen
* You enter your creds, iPXE then requests https://username:password@yourserver.fqdn/menu.ipxe and executes it
* You select the entry from the menu, iPXE fetches kernel+initrd via https and boots the kernel
* The initrd does DHCP again, then fetches a squashfs image and mounts it. Boot continues as normal

There are some annoying caveats:
* You probably need to use a self-signed cert for that connection because large cert chains can not be embedded into the iPXE executable. If you're at home, I wouldn't bother, but you probably don't want to transmit your AD creds over plain http.
* Your DHCP server should be able to reply differently to bios and efi clients so that bios clients get their bios binary and efi clients get their efi binary
* You probably need to compile iPXE yourself to embed an initial script that does dhcp and chainloads the login screen script
* EFI PXE firmware is often horribly broken, even more so than BIOS PXE ever was



Happy Thread posted:

What's the correct protocol for dealing with a flash drive that is possibly infected with malware? Erasing it, formatting it. I'm using Ubuntu 20.04; assume I'm new to it.

I guess the hardware could have bad extra stuff designed into it that lingers even after a format, but I'll think about that next.

Just blkdiscard it. If it doesn't support discard, blkdiscard -z zeroes the entire thing. If you don't want to touch the commandline, use gparted and write a new partition table.

BlankSystemDaemon
Mar 13, 2009



Bob Morales posted:

Random-rear end question, somewhat related to Linux:

How do you guys keep all your USB drives straight?

Which one has CentOS 7? CentOS 8? Fedora? Ubuntu? VMware ESX?

I guess I could find some cheap ones and just stick a Brother label on them, but some of mine are those tiny Sandisk drives
Netbooting, ie. via TFTP, (i)PXE, or UEFI HTTP(S) Boot depending on the platform.
The image is a custom-made FreeBSD image via poudriere-image(8), using the iso/usb+zmfs image type.

BlankSystemDaemon fucked around with this message at 12:35 on Oct 29, 2020

Truga
May 4, 2014
Lipstick Apathy

Bob Morales posted:

Random-rear end question, somewhat related to Linux:

How do you guys keep all your USB drives straight?

Which one has CentOS 7? CentOS 8? Fedora? Ubuntu? VMware ESX?

I guess I could find some cheap ones and just stick a Brother label on them, but some of mine are those tiny Sandisk drives

stash all the isos on the same USB, make a grub menu to select which iso to boot at runtime


vvvv: this is even better holy moley

Truga fucked around with this message at 14:31 on Oct 29, 2020

xtal
Jan 9, 2011

by Fluffdaddy

Truga posted:

stash all the isos on the same USB, make a grub menu to select which iso to boot at runtime

If you have a rooted android phone, or an old android phone you want to root, you can install an app that will make connected computers boot from an ISO downloaded to the phone

namlosh
Feb 11, 2014

I name this haircut "The Sad Rhino".

Antigravitas posted:

Most of the time is spent trying to get at the exact magic kernel parameters required to initiate a PXE boot, because the kernel/initrd needs to know that it has to fetch its squashfs first and that's kind of standardised but not really.

The AD thing is just Apache configured with basic auth via LDAP against a domain controller. That is the easy part.

The process is:
* Client requests DHCP
* DHCP server answers with the normal DHCP offer and PXE file location
* Client fetches file via tftp and executes it
* iPXE (in our case) executes an embedded script that runs DHCP again, then fetches a script via https that contains the login screen
* You enter your creds, iPXE then requests https://username:password and executes it
* You select the entry from the menu, iPXE fetches kernel+initrd via https and boots the kernel
* The initrd does DHCP again, then fetches a squashfs image and mounts it. Boot continues as normal

There are some annoying caveats:
* You probably need to use a self-signed cert for that connection because large cert chains can not be embedded into the iPXE executable. If you're at home, I wouldn't bother, but you probably don't want to transmit your AD creds over plain http.
* Your DHCP server should be able to reply differently to bios and efi clients so that bios clients get their bios binary and efi clients get their efi binary
* You probably need to compile iPXE yourself to embed an initial script that does dhcp and chainloads the login screen script
* EFI PXE firmware is often horribly broken, even more so than BIOS PXE ever was


Awesome right up... thanks very much for this. I need to start simple, but like I said... you’re living in the end game my friend

RFC2324
Jun 7, 2012

http 418

Happy Thread posted:

What's the correct protocol for dealing with a flash drive that is possibly infected with malware? Erasing it, formatting it. I'm using Ubuntu 20.04; assume I'm new to it.

I guess the hardware could have bad extra stuff designed into it that lingers even after a format, but I'll think about that next.

Toss it. Malware infecting the actual hardware of a usb drive is trivial, and once the actual hardware gets infected it will reinfect every time you reinsert it.

Flash drives are too cheap to try and clean up

xzzy
Mar 5, 2009

I've been meaning to migrate my environment to ipxe for a while now, but normal pxeboot works just well enough that I haven't actually forced myself to do it.

But ipxe has so many neat features that would make my installs work smoother, handing out vmlinuz/initrd over http would let me stop relying on UDP to ship those images across my network (it works most of the time, but breaks just enough to be irritating).

Obviously with physical hosts I couldn't completely eliminate tftp, but the ipxe image is a lot smaller.

Antigravitas
Dec 8, 2019

Die Rettung fuer die Landwirte:

namlosh posted:

Awesome right up... thanks very much for this. I need to start simple, but like I said... you’re living in the end game my friend

I can post curated config examples tomorrow after I get my work done. There are some gotchas that are hard to debug if one doesn't know the protocols involved well.

Happy Thread
Jul 10, 2005

by Fluffdaddy
Plaster Town Cop

RFC2324 posted:

Toss it. Malware infecting the actual hardware of a usb drive is trivial, and once the actual hardware gets infected it will reinfect every time you reinsert it.

Flash drives are too cheap to try and clean up

Buying a cheap pile of drives ""new"" is what I did, but even then I still distrust them quite a bit. With so many knockoffs it seems hard to prove the manufacturer, even independent of the price.

Isn't there a way to stop Ubuntu from being affected by any executable code on a USB drive upon insertion? Such that no matter what signals it gets back from the drive, it's not going to run anything? Is it enough to just disable the most obvious "autorun" type actions from OS options? It seems like I'd want to be sure about the moment of insertion before I think about running the blkdiscard command.

If there's as you say still easily malware in the hardware, I guess at that point I'd only be vulnerable to MITM style stuff, as in files I put on there get messed with on the way back to me. I guess that still makes it very hard to turn them into bootable OS drives that are trustworthy...

mystes
May 31, 2006

Happy Thread posted:

Buying a cheap pile of drives ""new"" is what I did, but even then I still distrust them quite a bit. With so many knockoffs it seems hard to prove the manufacturer, even independent of the price.

Isn't there a way to stop Ubuntu from being affected by any executable code on a USB drive upon insertion? Such that no matter what signals it gets back from the drive, it's not going to run anything? Is it enough to just disable the most obvious "autorun" type actions from OS options? It seems like I'd want to be sure about the moment of insertion before I think about running the blkdiscard command.

If there's as you say still easily malware in the hardware, I guess at that point I'd only be vulnerable to MITM style stuff, as in files I put on there get messed with on the way back to me. I guess that still makes it very hard to turn them into bootable OS drives that are trustworthy...
Are you worried about malicious code stored on the usb stick or are you worried about malicious code executing on the usb stick? I don't think ubuntu automatically runs anything off of usb mass storage devices, although there are always potentially bugs in thumbnail rendering if you actually open it up in a file manager, but a malicious usb device doesn't need to actually present itself as a mass storage device, so it theoretically has every usb device driver as the attack surface if it decides it doesn't want to play nice.

Malicious HID devices are the most common target of experimentation, but someone who knew what they were doing could probably find actual usb driver exploits that would be much more effective.

mystes fucked around with this message at 20:38 on Oct 29, 2020

RFC2324
Jun 7, 2012

http 418

I originally read about an exploit that allowed the microcontroller to be infected with a worm, and be an unblockage vector for infection that way, but can't seem to find it now.

Happy Thread posted:

Buying a cheap pile of drives ""new"" is what I did, but even then I still distrust them quite a bit. With so many knockoffs it seems hard to prove the manufacturer, even independent of the price.

Isn't there a way to stop Ubuntu from being affected by any executable code on a USB drive upon insertion? Such that no matter what signals it gets back from the drive, it's not going to run anything? Is it enough to just disable the most obvious "autorun" type actions from OS options? It seems like I'd want to be sure about the moment of insertion before I think about running the blkdiscard command.

If there's as you say still easily malware in the hardware, I guess at that point I'd only be vulnerable to MITM style stuff, as in files I put on there get messed with on the way back to me. I guess that still makes it very hard to turn them into bootable OS drives that are trustworthy...

https://www.wired.com/2014/10/code-published-for-unfixable-usb-attack/

This has nothing to do with autorun type features

E: More thorough writeup: https://www.howtogeek.com/203061/don%E2%80%99t-panic-but-all-usb-devices-have-a-massive-security-problem/

RFC2324 fucked around with this message at 20:55 on Oct 29, 2020

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
I need a little ffmpeg wizardry. I'm trying to split a video ripped from a DVD that has chapters into individual videos of each chapter. I leveraged some Python code online for this that I don't think matters. It's eventually just invoking ffmpeg with something like:

code:
ffmpeg -i _VIDEO_ -ss _START_ -to _STOP_ -vcodec copy -acodec copy
The copy codec doesn't seem to completely do the job. The video kicks in some seconds after the audio. I'm guessing it's something like I don't have an i-frame until then. Is there any way to have ffmpeg reconstruct things so that I do get one? The brute-force thing I may try is just transcoding. That might hopefully force it, but then I'm kind of making a copy of a copy.

Pablo Bluth
Sep 7, 2007

I've made a huge mistake.
I'd go with it being a key-frame issue; if your _START_ doesn't align to a keyframe, copy on the video will have to wait until the next keyframe while audio behaves differently. Personally, I'd install a copy of avidemux and use that; you can still do a copy-copy without re-encoding but you can select the start/end times based on keyframes and get visual confirmation of what you're selecting. If you need to slice more time-specific than keyframes allow then re-encoding will be the only solution.

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
I ended up adjusting the script I was using so it went a tenth of a second earlier in the start time. Somehow that worked. I suspect it was starting right after that frame but I didn't really expect that hack to work lol.

Regarding avidemux, I tried it out because I somehow had installed it in the past before on a Windows setup. I couldn't crop unless I specified a codec other than the copy codec. I'm guessing that means it would have ended up transcoding the result.

Pablo Bluth
Sep 7, 2007

I've made a huge mistake.

Rocko Bonaparte posted:

Regarding avidemux, I tried it out because I somehow had installed it in the past before on a Windows setup. I couldn't crop unless I specified a codec other than the copy codec. I'm guessing that means it would have ended up transcoding the result.
You need to select your start marker using the next/prev keyframe buttons (the double arrow ones to the left of the A & B marker buttons, or use the up/down arrows on your keyboard). That's a fundamental requirement of slicing videos without re-encoding as keyframes/i-frames are the only frames that are encoded independent of other frames. Slice anywhere any and some frames end up orphaned from their starting point. Lots of codecs also use b-frames (bi-directional encoding) so generally it's best to end the slice on a keyframe too, although sometimes you can get away with cutting elsewhere.

I'm assuming your tweaked ffmpeg start time works because it ended up on a keyframe (or close enough for you not to notice any audio sync change).

namlosh
Feb 11, 2014

I name this haircut "The Sad Rhino".

Antigravitas posted:

I can post curated config examples tomorrow after I get my work done. There are some gotchas that are hard to debug if one doesn't know the protocols involved well.

Yes please

Antigravitas
Dec 8, 2019

Die Rettung fuer die Landwirte:
Alright, I finally found the time to do condense this down. I'm going to drop the auth and tls stuff because it's complicated.

Ingredients:
* a tftp server (tftp-hpa)
* a DHCP server (isc-dhcp-server here, but use whichever)
* optionally, a http server (apache here)


DHCP

You'll want next-server to point at our PXE boot server where tftp and httpd are running. There is an interesting bit of configuration here: BIOS and EFI clients require different binaries and luckily most implementations send their arch in the DHCP DISCOVER packet. So we can tell dhcpd what that is:

code:
option arch code 93 = unsigned integer 16;
We can use it in our scope to respond differently depending on client arch:

code:
    next-server our-server.local;
    if option arch = 00:06 {
        filename "ipxe/ipxe32.efi"; // NOTE: We won't use this because 32 bit EFI effectively does not exist
    } elsif option arch = 00:07 {
        filename "ipxe/ipxe.efi";
    } elsif option arch = 00:00 {
        filename "ipxe/ipxe.pxe";
    }
Which will instruct PXE clients to request the right binary. This is sometimes exposed in DHCP server software GUIs. Pfsense offers these as "Default BIOS file name", "UEFI 64 bit file name".


TFTP

We're going to use /srv/tftp as our base of operations with tftp-hpa running tftp. We can use http to serve everything but the iPXE binary, but I prefer having one big tree reachable via both tftp and http instead of separating them.

Folder structure below /srv/tftp
code:
./ipxe/ <--Where our ipxe binaries and scripts reside
./boot/ <--Where we store our operating systems
Compiling iPXE

I think there's a web buildbot thing available, but compiling iPXE is easy.

We'll need git and build-essential, then:

code:
git clone git://git.ipxe.org/ipxe.git
cd ipxe/src
We are compiling from source because we want to build a script into iPXE. You'll also want to compile it yourself if you want to change some options (in src/config/general.h), like compiling in HTTPS support or NFS or a myriad of other options.

This is the script:

code:
#!ipxe
dhcp
chain tftp://ourserver.local/ipxe/menu.ipxe
Save it as builtin.ipxe (or whatever name you want, it doesn't matter) in the src directory, then build iPXE

code:
make bin-x86_64-efi/ipxe.efi EMBED=builtin.ipxe
make bin/ipxe.pxe EMBED=builtin.ipxe
Then copy the resulting bin-x86_64-efi/ipxe.efi and bin/ipxe.pxe to your /srv/tftp/ipxe/ folder. Make sure the tftp server can read those.

So when a client starts executing our iPXE binary it will use dhcp to configure its interfaces. Immediately afterwards it will pull a script file from our server and execute it.

Note that a bin-x86_64-efi/ipxe.usb EMBED=builtin.ipxe produces an image you can dd onto a usb drive so you can skip the entire PXE malarkey for non-cooperating computers.

Let's write that second script file:

code:
#!ipxe
# setting a convenient variable for later to save typing
set server ourserver.local

# Let's have a menu
menu iPXE boot menu
# With two entries
item --key s shell (S)hell
item --key g grml (G)rml


:shell
# The iPXE shell is useful for debugging
shell

:grml
# I'm using grml here as an example. Most linux distros work similarly
# Note that initrd == imgfetch == module, i'm using initrd here out of convention. See also: https://ipxe.org/cmd/imgfetch
initrd tftp://${server}/boot/grml/boot/initrd.img
# Similarly to initrd, kernel is a synonym of a bunch of commands https://ipxe.org/cmd/kernel
kernel tftp://${server}/boot/grml/boot/vmlinuz initrd=initrd.img boot=live fetch=tftp://${server}/boot/grml/grml64-full.squashfs boot=live noswap live-media-path=/live/grml64-full/
# The above commands have downloaded two images to RAM and marked the vmlinuz binary for execution. Let's jump into vmlinuz
boot
Save it as /srv/tftp/ipxe/menu.ipxe


Get GRML
(or another Linux distro, I'm just using Grml as an example)

Go to https://grml.org/download/, download the large amd64 iso. IGNORE THE NETBOOT PACKAGE, it doesn't do what we want right now.

Unpack/Mount that iso and copy the files below boot/grml64full/ (initrd.img, vmlinuz) and live/grml64-full/grml64-full.squashfs to /srv/tftp/boot/grml/

Make sure tftp can read them, then try to PXE-boot a client.


HTTP

You can basically just put
code:
Alias /pxe/ /srv/tftp/
<Directory /srv/tftp>
    AllowOverride None
    Require all granted
</Directory>
in Apache2 and change the tftp:// urls into http:// ones above. Or just change the document root of the entire http server if you wish. This makes downloading the squashfs image much, much faster. Tftp is extremely basic and slow.



Getting the right kernel boot parameters for PXE boot

This is tricky because distros have different scripts in their initrd, but the process is usually the same:

* The kernel starts, along with a ramdisk (initrd)
* Scripts in the initrd use dhcp and then try to fetch a squashfs containing the real root file system
* squashfs gets mounted and the live image boots

Note that this boot process isn't actually all that dissimilar from the normal boot process of a modern distro. That's why we took the normal Grml iso, most distros have the process built into their initrd even in their desktop images.

Here's the kernel command line for clonezilla:
code:
:clonezilla
initrd http://${server}/pxe/boot/clonezilla/live/initrd.img
kernel http://${server}/pxe/boot/clonezilla/live/vmlinuz initrd=initrd.img boot=live union=overlay fetch=http://${server}/pxe/boot/clonezilla/live/filesystem.squashfs username=user config components noswap edd=on nomodeset nodmraid net.ifnames=0
boot
Here's gparted:
code:
:gparted
initrd http://${server}/pxe/boot/gparted/live/initrd.img
kernel http://${server}/pxe/boot/gparted/live/vmlinuz initrd=initrd.img boot=live config components union=overlay username=user noswap noeject fetch=http://${server}/pxe/boot/gparted/live/filesystem.squashfs
boot
You can usually copy these from the distro live images. Whether they use pxelinux, grub, or some other mechanism, their menu files somewhere list kernel parameters for booting a live image, and all you need to do is to tell it to also download its squashfs first.

Antigravitas
Dec 8, 2019

Die Rettung fuer die Landwirte:
A note on ^^^^: I heavily, heavily redacted internal documentation there. There may be typos hiding, so you'll have to do the homework. It's not the step-by-step guide that it is internally, sadly. (We compile iPXE via CI, for example)

Oh, and this basically replicates a bunch of stuff https://fogproject.org does as well…

A few things of note: Since iPXE can request scripts from a server via http you can have a server respond dynamically to boot requests. It's really easy to do so, in fact.

We have a few emergency janitoring utilities in our menu (gparted, clonezilla, grml), but most of the time it is used to run MDT (keyword: wimboot), or automated Debian installations that come with our ssh keys and initial config for automatic provisioning. Helldesk uses it as well for workstation janitoring (wimboot again).

xzzy
Mar 5, 2009

Have you ever played with or looked at puppet razor?

I love the basic idea, system boots ipxe and a bunch of info about the hardware get saved to a database and you can DO STUFF based on it. But the project doesn't seem to be moving very fast, and writing templates to install an OS really bugs me (I had to use cobbler for a while and hated it).

Hollow Talk
Feb 2, 2014

xzzy posted:

Have you ever played with or looked at puppet razor?

I love the basic idea, system boots ipxe and a bunch of info about the hardware get saved to a database and you can DO STUFF based on it. But the project doesn't seem to be moving very fast, and writing templates to install an OS really bugs me (I had to use cobbler for a while and hated it).

I have no experience with this, but this just reminded me of "serveradmin" which InnoGames use to deploy/administrate their infrastructure. There was a neat talk about it during FOSDEM19: https://archive.fosdem.org/2019/schedule/event/keeping_track_stateful_infrastructure/

Code: https://github.com/innogames/serveradmin & https://github.com/innogames/igvm

Side note: this makes me sad, because I presume FOSDEM won't happen in 2021, seeing how Covid is going more generally across Europe, and in Belgium in particular. :cry:

Antigravitas
Dec 8, 2019

Die Rettung fuer die Landwirte:

xzzy posted:

Have you ever played with or looked at puppet razor?

I love the basic idea, system boots ipxe and a bunch of info about the hardware get saved to a database and you can DO STUFF based on it. But the project doesn't seem to be moving very fast, and writing templates to install an OS really bugs me (I had to use cobbler for a while and hated it).

It does sound interesting, but in our case we don't operate at a scale where provisioning of hardware has to be centrally managed in this way. Ansible does all the Linux stuff except installing on bare metal and we don't need to provision new physical hosts that often. MDT does all the Windows bare metal crap, so we are covered.

xzzy
Mar 5, 2009

Darn, my hunt for someone to chat about hardware provisioning continues. :v:

Basically all I do is bare metal and I really want to overhaul our system but I'm unsure what the state of the art is (the path of least resistance is redhat satellite, a product I've evaluated many times over the years and discarded because it does nothing better than what I already have and comes with a huge price tag).

Bobulus
Jan 28, 2007

Computer viking posted:

Also, nothing spends all its time doing parallel work - it may just be in a single-threaded phase right now.

RFC2324 posted:

Might check docker config.

Following up, because I hate it when other people ask for help, then don't say 'thank you' when you fix the problem.


After I fixed my first problem, I had a second problem, using up all the system memory and the system killing the process, that was fixed by messing with the docker configuration. I ended up running the process inside a slice that limited the usable memory to only 55 gb out of 64 gb.




So, thread, thank you!

Bobulus fucked around with this message at 03:04 on Nov 3, 2020

namlosh
Feb 11, 2014

I name this haircut "The Sad Rhino".

Antigravitas posted:

Tons of amazing stuff

Thanks for taking the time to type that out. I’ll have to take a look later, but it looks like a really impressive setup man

Sheep
Jul 24, 2003

Antigravitas posted:

Ansible does all the Linux stuff except installing on bare metal and we don't need to provision new physical hosts that often.

This is our situation. Outside of large hardware refreshes (every 3-5 years in the datacenter) we do manual USB installs of minimal CentOS 8 and then run an Ansible playbook to install and configure everything as necessary. For hardware refreshes we have a PXE kickstart server we enable on the IPMI network that is broadly analogous to what you provided. Foreman/Katello would be nice but would get used so infrequently that it's difficult to justify the overhead of administration/training/etc.

Spacewalk did the trick before it got discontinued, but it was pretty janky in some places.

Sheep fucked around with this message at 22:09 on Nov 3, 2020

Pablo Bluth
Sep 7, 2007

I've made a huge mistake.
Today's lesson: when using LUKS encryption, make a backup of the master key or header.

I have a LUKS disk that suddenly won't decrypt. A dump of the header suggests all the keys have disappeared. I wasn't messing around with it so somehow it must have become corrupted; perhaps a failing disk? If I made a backup of the master key at the time of creating it, I've no idea where I stored it! Fortunately I can live with the stuff lost since my last backup.

Sheep
Jul 24, 2003
I ended up in your situation once before. No idea what happened but none of the normal keys (user, admin, oh crap rescue) worked. I don't recall doing any deep dive, I think we just wrote it off as a failing disk.

Because I didn't want to end up in that position again, one of the first things I did when building our clevis/tang setup was setup our deployment pipeline to automatically dump and backup the LUKS header once all of the keys were set.

Edit:
This is fine

quote:

load average: 8452.56, 10437.97, 10815.54
Solarwinds agent spins up infinite df processes if an NFS server goes down and the client running the Solarwinds agent doesn't unmount it first

Sheep fucked around with this message at 15:39 on Nov 6, 2020

BlankSystemDaemon
Mar 13, 2009



Sheep posted:

Edit:
This is fine
How can you tell whether they're caused by CPU load alone, number of processes waiting to be run, or uninterruptible wait - and the latter can be 1 or a combination of the over-400 codepaths, all of which contribute to uninterruptible wait, including disk I/O and locking primitives of all things?

Sheep
Jul 24, 2003
It's just processes waiting on RPC replies, but they do contribute to load average.

https://access.redhat.com/solutions/23338

quote:

NFS Client mounts the NFS export with the hard NFS mount option by default. This results in NFS RPC Requests being retried indefinitely. A side effect of hard-mounted NFS file system is that processes block (or "hang") in a high-priority disk with waiting I/O state until their NFS RPC Reply is received from the NFS Server. Hence, when an NFS Server goes down, the NFS mounts on the NFS Client will hang until the NFS Server recovers.

Sheep fucked around with this message at 20:30 on Nov 6, 2020

RFC2324
Jun 7, 2012

http 418

Never do hard NFS mounts unless you WANT an issue with the NFS server to kill everything else.

xzzy
Mar 5, 2009

All my users demand hard mounts because they're worried about data integrity. :suicide:

Adbot
ADBOT LOVES YOU

Volguus
Mar 3, 2009

Pablo Bluth posted:

Today's lesson: when using LUKS encryption, make a backup of the master key or header.

I have a LUKS disk that suddenly won't decrypt. A dump of the header suggests all the keys have disappeared. I wasn't messing around with it so somehow it must have become corrupted; perhaps a failing disk? If I made a backup of the master key at the time of creating it, I've no idea where I stored it! Fortunately I can live with the stuff lost since my last backup.

cryptsetup can store the header in a different file, so it can be a bit easier to make a backup of it.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply