The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1024 »

taqueso: Mar 8, 2004

'dialog' is a TUI system you can use for this kind of thing.
https://www.linuxjournal.com/article/2807
https://aplicacionesysistemas.com/en/dialog-crear-menus-tus-scripts/

# ? May 17, 2019 21:09

Adbot: ADBOT LOVES YOU

# ? Apr 24, 2024 04:09

MrPablo: Mar 21, 2003

pahuyuth posted:

In a bash script how can I create a menu from a file? If the file has contents of
code:
foo bar
abc 123
How can I use each line as an option so that the menu would be something like
code:
Select an option
1] foo bar
2] abc 123
3] Quit
The file of possible options will likely change every time the script is run.

Another option is whiptail, which is typically available in Debian and derivatives (Raspbian, Ubuntu, etc):

code:

whiptail --title 'Favorite Cheese' --notags --menu 'What is your favorite cheese?' 0 0 0 american American cheddar Cheddar gouda Gouda

Example:
https://www.youtube.com/watch?v=SwgppWS3RnI

# ? May 18, 2019 00:52

Computer viking: May 30, 2011; Now with less breakage.

An Enormous Boner posted:

I did say I expected there to be a tweak for it - but thanks.

(It's just such an annoying default - and I'm not going to install Tweaks to fix it when using someone else's desktop. I may bother to do so if I go back to gnome 3 myself, though.)

# ? May 18, 2019 02:05

jaegerx: Sep 10, 2012; Maybe this post will get me on your ignore list!

Use python setopts instead of bash?

# ? May 18, 2019 04:15

Volguus: Mar 3, 2009

What's the idea with the new grub2 boot system? Before, we had a grub.cfg/menu.lst file that was read by grub at boot and executed, and that was that. But now we have grubenv, and grubby and BLS and I have no idea anymore who does what and why they're there. And when stuff gets broken it's harder and harder to fix. How is the new system better than the old one? What are the advantages of so many moving pieces?

# ? May 21, 2019 00:13

xzzy: Mar 5, 2009

I didn't put any effort into understanding grub2, the usage model appears to be google whatever problem you have and let other people tell you how to fix stuff. Fortunately it doesn't happen too often, 99.9% of the time it does the right thing.

Maybe that makes me bad at my job but like you said the configuration is super opaque now and if that's the world they want, I wash my hands of it. :v:

# ? May 21, 2019 00:20

telcoM: Mar 21, 2009; Fallen Rib

Volguus posted:

What's the idea with the new grub2 boot system? Before, we had a grub.cfg/menu.lst file that was read by grub at boot and executed, and that was that. But now we have grubenv, and grubby and BLS and I have no idea anymore who does what and why they're there. And when stuff gets broken it's harder and harder to fix. How is the new system better than the old one? What are the advantages of so many moving pieces?

grub2's grubenv file is basically the same as the /boot/grub/default file in older versions of GRUB: it's a file that the GRUB itself may update at boot time, to optionally store the latest OS selection (and in GRUB2, also other GRUB variables if desired), like with the "default=saved" setting of the old GRUB.

Instead of relying on third-party things like grubby or update-grub, grub2 now tries to provide a uniform GRUB configuration system for all distributions: there is grub-mkconfig for creating/updating the actual configuration file, which uses /etc/default/grub for default kernel options and other simple configuration tasks. If you need more advanced than that (and some people do!), there is /etc/grub.d/ which contain a number of shell scripts, which will be executed in LC_COLLATE=C alphanumerical order to build up the actual GRUB configuration file. In there should be a 40_custom file which can be used to add custom menu entries to the end of the GRUB boot menu, and 41_custom which allows you to drop in a completely custom grub2 configuration file that can override everything the standard set-up does if desired, by name "custom.cfg".

Now, some distributions have made their old GRUB configuration management tools into a simple wrapper for the new grub-mkconfig: for example, Debian did that with their update-grub, which is now effectively just an alias for "grub-mkconfig -o /boot/grub/grub.cfg". I guess this has likely been propagated to several other distributions that have their roots in Debian. On the other hand, I think RedHat went with using the new grub-mkconfig directly.

My advice for trying to understand grub2 configuration? First check out /etc/default/grub, then take a peek into /etc/grub.d/. The files in there usually map to meaningful chunks in the actual grub.cfg file, and the comments in the scripts building each of those chunks will provide clarification on what is going on. Because of this automated build-up out of more-or-less independent chunks, the actual grub.cfg can have quite a bit of unnecessary duplication of things, a multitude of conditional clauses and assorted stupidities a fully hand-crafted grub2 configuration file would not have to include.

And here's ~~some light reading~~ a wall of text that might help understanding how grub2 works

The old GRUB 0.97-or-so had a two/three-stage system: stage1 was the first part. It had to be carefully squeezed into fitting in the boot code area of the MBR. Its one job was to load just the first block of either stage1.5 or stage2, by raw disk block location. The next stage (either stage1.5 or stage2) would then include a list of further blocks to read and a routine to do so within its first block. If stage1.5 was used, it contained a read-only filesystem driver which then could read the actual stage2 using a filesystem pathname.

But it turned out very few distributions and people actually used stage1.5; most had GRUB stage2 embedded into the empty space between the MBR and the beginning of the first partition, as it was usually the most reliable configuration. Since data alignment became an issue with SSDs and large storage systems, Microsoft promoted a new scheme of starting the first partition at exactly 1 MiB into the disk, this meant there was usually plenty of space available, instead of just up to 62 or so blocks as with the original MS-DOS compatible scheme of leaving C/H/S 0/0/1...0/0/63 for MBR only and starting the first partition at 0/1/1.

But there was also a need for GRUB to become more capable and thus bigger:

Handling software RAID1 sets by essentially installing two copies of GRUB manually was tricky, and some even want to boot from RAID 5 or 6 sets.
With disk encryption, leaving an entire /boot partition unencrypted is less than ideal, and in case of laptops, allows an easy way to introduce malware by replacing the initrd/initramfs file with a modified one.
Detecting and mounting filesystems based on filesystem UUID turned out to be a very useful idea in the face of hot-pluggable storage and enterprise SAN configurations, so it would be very nice to be able to do something like that in the bootloader too.
Likewise, the ability to boot from LVM logical volumes was also a desirable feature. On big enterprise SAN-based systems, there is often a need to migrate from old storage to the new by every 3-5 years as the lease and/or service agreement on the storage system expires and it is cheaper to just buy/lease a new model instead of keeping the old one. Using LVM makes on-line data migrations possible and even fairly easy.
There were a number of patches for making the old GRUB graphically nicer, so it was pretty obvious that this would need to become a feature of the standard GRUB.
The old GRUB had a set of commands that were useful at boot recovery situations, but extending that set of commands was difficult and the standard set had some annoying omissions.
Using the same bootloader for both local and network boot would provide a more uniform user experience.

If the GRUB 0.97-style model of fixed stages was used, adding all this functionality would make the stage2 awkwardly large. So a new, more modular system was introduced in grub2.

Instead of old stage1, there is now boot.img, which fits into MBR.
The stage1.5 concept is abandoned.
Instead of stage2, there is now grub2 core image (core.img) which is built on-demand by grub-mkimage. It includes the GRUB main kernel, the GRUB modules necessary to gain access to the filesystem containing the GRUB module directory (usually /boot/grub/<GRUB architecture>/), the GRUB path prefix (specifying at least the partition and pathname where the actual GRUB configuration file can be found), and optionally an embedded GRUB configuration file, a RAM disk file of whatever you want (similar to what you can do with SYSLINUX's memdisk utility), and/or a public key for verifying signatures on GRUB modules and kernels (for trying to provide boot security similar to Secure Boot even on traditional BIOS/MBR systems). The main part of the core image and things embedded within it can be compressed with LZMA and protected with Reed-Solomon error correction codes to make it more robust.

This allowed the development of a large number of grub2 modules to more easily extend grub2 as needed, and still keep the possibility to squeeze the core image to under 31 KB, so it can still fit into the space between the MBR and the first partition, even if the beginning of the first partition is chosen using the old MS-DOS compatible rules. But the more space you have available, the more modules you can embed and so the more features you can have - so grub2 can fulfill the needs of both old/small/embedded hardware users, the users of the newest shiny big enterprise systems, and anything in between.

For UEFI, the boot.img part is just skipped: the grubx64.efi file is simply the grub2 core image packaged into a .efi format. If Secure Boot is in effect, it blocks loading of further modules from /boot/grub/<grub2 architecture name> as grub2 modules are ELF files, not signed Windows-style PE32/PE32+ executables which is the standard executable format of the UEFI+Secure Boot combination. But modules embedded in the core image work just fine, since the whole image can be signed for Secure Boot. This makes the grubx64.efi file bigger, but the ESP partition usually has plenty of space.

# ? May 21, 2019 09:00

VictualSquid: Feb 29, 2012; Gently enveloping the target with indiscriminate love.

The last time I had a problem with grub2 it was because manjaro configures grub to only show a black screen instead of the menu.
And turning that feature off doesn't seem to be possible from any config file. I had to run a shell command directly for that.

Presumably there are lots more of those commands. And the goal must be to make sure that a backup of /etc/grub/ doesn't actually restore all of your settings.
Though I can't imagine a case where that would be useful.

# ? May 21, 2019 11:10

Volguus: Mar 3, 2009

telcoM posted:

...useful info...

Thank you for the information. There is now, however, a new player in the ring: BLS (Boot Loader Specification). Now, instead of the ### BEGIN /etc/grub.d/10_linux ### section in grub.cfg we have .conf files in /boot/loader/entries/ . While at https://systemd.io/BOOT_LOADER_SPECIFICATION they do provide a rationale for the thing to exist, to me that's just handwaving. More specifically: we don't want to deal with the old way so we're making a new way. Whatever, as long as it's working nobody cares. The problems appear when it is not working, or is not working as it should be.

My personal problems with it:

1. Doesn't remember anymore the last chosen menu option. It's not an extremely needed feature, but is very useful when I need to boot an older kernel if the latest one is broken for some reason. More specifically, in grub.cfg we used to have a call to "savedefault" in the menu option to save the latest thing (which just calls save_env) . Now that entire section is gone and everything is made up from those .conf files. And it doesn't save anymore. Maybe there is an option one could set in the conf files, but i haven't seen anywhere being specified.

2. The last grub2 update broke my boot. More specifically, it turns out that I had a broken grubenv (how did that happen?) but grub2 was working perfectly ok, by passing the kernel options from $default_kernelopts variable. Latest update fixed something and now that variable is no longer looked at and it turns out that i don't have root=<id> set anywhere else. That was a fun one to hunt down with an unbootable system.

Regenerating grubenv fixed my unbootable system, but man, it wasn't fun to hunt down through the myriad of moving pieces who is actually to blame for the problem. All in all I have a slightly worse booting experience than before BLS came into existence. Which is worse than before grub2 arrived, almost 10 years ago. Grub v1 was a huge improvement over LILO, but that's history now.

# ? May 21, 2019 14:18

telcoM: Mar 21, 2009; Fallen Rib

Volguus posted:

Thank you for the information. There is now, however, a new player in the ring: BLS (Boot Loader Specification).

Hmm. I'm not up to date with Fedora (I'm more of a Debian guy myself, and work with various "enterprise" distributions).

But it seemed to me that BLS is currently basically three things:

a boot configuration for the systemd-boot bootloader
a way to make setting up dual/multiboot easier for other Linux/BSD/whatever OSs, and for tools like os-prober or Boot-Repair.
some wishful thinking that other bootloaders would adopt the same scheme

Apparently Fedora 30 has indeed migrated to a BLS-compliant configuration generator for grub2: https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault

They acknowledge that their implementation is slightly different from the BLS "standard document"... and that tells me that BLS might still need a bit of tweaking, fine-tuning and general experience with the wide world before it gets to enterprise distributions. They even acknowledge that users are running into documentation that specifies the old way to do things, which no longer works with BLS.

But the general idea seems sound, and obviously if you want to change things, you've got to start somewhere.

There's also a way to return to the way things used to be, if BLS turns out to be problematic.

fedoraproject.org posted:

On platforms using grub, users can also switch back by installing the grubby-deprecated package, setting "GRUB_ENABLE_BLSCFG=false" in /etc/default/grub , and using grub2-mkconfig to re-generate their configuration file.

# ? May 21, 2019 15:31

Volguus: Mar 3, 2009

Yes, I was talking with Javier Martinez Canillas (BLS maintainer) over the weekend and he helped me figure out the grubenv issue that prevented me from booting properly. If push comes to shove I will disable BLS, but in my experience that will just kick the can down the road. More specifically, I tend to just upgrade Fedora in place whenever new version gets released (twice per year). Most of the time is fine. But when I do things like this (disable a new feature) I will forget it even exists and then 5 years later they just force it on everyone and then the pain is even greater. And then I need to reinstall from scratch. I suppose there's nothing I can do about it, I'll better just reinstall in a few releases but disable it for now so that everything works as it should. Then again, if nobody is using the new feature they don't even know about what's broken so then they can't fix it either. Quite the catch 22.

# ? May 21, 2019 15:45

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

anyone managed to get linux to recognize airpods as a headset (instead of headphones)?

# ? May 22, 2019 01:23

G-Prime: Apr 30, 2003; Baby, when it's love,
if it's not rough it isn't fun.

Can't speak to Airpods specifically, but I've gone through a few different bluetooth headsets and Linux installs (different distros, different versions) over the past few years, and I had great success on getting headsets working on Ubuntu 16.04, and headphones only on Ubuntu 18.04 and Antergos. Really kinda annoying, haven't found the common thread except to think something notable changed in bluez.

# ? May 22, 2019 12:45

mystes: May 31, 2006

Sometimes with bluetooth earphones on linux you have to manually change the profile to the one you want; will it let you do that with the airpods?

# ? May 22, 2019 13:12

taqueso: Mar 8, 2004

Airpods use a proprietary Bluetooth scheme because standard BT doesn't have twin audio support yet.

# ? May 22, 2019 13:39

mystes: May 31, 2006

taqueso posted:

Airpods use a proprietary Bluetooth scheme because standard BT doesn't have twin audio support yet.

What's twin audio?

# ? May 22, 2019 13:56

taqueso: Mar 8, 2004

mystes posted:

What's twin audio?

Also called dual audio. I don't remember which one is Samsung's name and which is Apple's. It is sending the audio to two Bluetooth devices, one for each channel.

# ? May 22, 2019 14:06

General_Failure: Apr 17, 2005

G-Prime posted:

Antergos.

Oh. My condolences.

# ? May 23, 2019 22:20

Double Punctuation: Dec 30, 2009; Ships were made for sinking;
Whiskey made for drinking;
If we were made of cellophane
We'd all get stinking drunk much faster!

General_Failure posted:

Oh. My condolences.

In case anyone is not aware about this, Antergos is dead, and you should migrate off of it ASAP.

# ? May 23, 2019 22:29

Kreeblah: May 17, 2004; INSERT QUACK TO CONTINUE; Taco Defender

So, here's a weird question. I bought a network scanner, and it works great, except for one thing. It's supposed to be able to send scanned output to a printer, and I'm having trouble having it do that. It's not a super essential feature for me (since it'd be a pretty rare use case), but it could be a bit of a timesaver.

If I can't get that to work, though, I know I can get it to drop files on my server since that's been working fine (and was my primary use case, really), so is there any Linux software to monitor a directory, send any PDFs it finds in it to a printer, and then delete them?

# ? May 24, 2019 00:16

RFC2324: Jun 7, 2012; http 418

Kreeblah posted:

So, here's a weird question. I bought a network scanner, and it works great, except for one thing. It's supposed to be able to send scanned output to a printer, and I'm having trouble having it do that. It's not a super essential feature for me (since it'd be a pretty rare use case), but it could be a bit of a timesaver.

If I can't get that to work, though, I know I can get it to drop files on my server since that's been working fine (and was my primary use case, really), so is there any Linux software to monitor a directory, send any PDFs it finds in it to a printer, and then delete them?

Seems like it would be fairly trivial to script something

# ? May 24, 2019 00:20

G-Prime: Apr 30, 2003; Baby, when it's love,
if it's not rough it isn't fun.

General_Failure posted:

Oh. My condolences.

Double Punctuation posted:

In case anyone is not aware about this, Antergos is dead, and you should migrate off of it ASAP.

Their demise is greatly overstated. At the end of the day, Antergos was 95% Arch with a pretty installer and some metapackages. They're going to be releasing most of the metapackage stuff to AUR and an update that reverts the references to their repos to fall back to the standard Arch ones. It's really not that big of a deal. I'll be sad to see them go, and it means that standing up a new Arch install is going to take a little longer, but it's not that big of a deal.

# ? May 24, 2019 03:24

jaeger: Jul 28, 2005; ...

originalnickname posted:

So I've got an issue with my CentOS install and I can't figure out how to google this correctly.

Basically, I've got 2 nics installed (1 4x1Gbit copper, 1 4x10GbE SFP+) and CentOS seems to be loading the drivers simultaneously. Normally this is absolutely fine but when CentOS enumerates the interfaces it interleaves the 8 NICs in ip -c.

Another wrinkle I've got to deal with (I don't want this to happen but I need it for something else) is that I have to use the old Eth* naming scheme.

I'm only assuming that this is interleaving because of some sort of race condition while loading drivers, but dmesg seems to back me up regarding the load order.

Is there a way that I could force a wait in the boot between the NIC driver loads so that CentOS doesn't do this?

(sorry about the rambling, hope I was able to make this clear enough).

I'm late to the party on this one but surprised so many people say setting NIC device names is so tough. In my experience it only takes 2 lines in /etc/sysconfig/network-scripts/ifcfg-whatever:

HWADDR=<your MAC, of course>
DEVICE="the name"

For example, in a test VM:

code:

# egrep 'DEVICE|HWADDR' /etc/sysconfig/network-scripts/ifcfg-enp0s3
DEVICE="somethingawful0"
HWADDR=08:00:27:7e:99:ae
# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: somethingawful0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:7e:99:ae brd ff:ff:ff:ff:ff:ff

The value of net.ifnames makes no difference in this case.

Apologies if I've missed something essential, just wanted to chip in that this is easy.

# ? May 24, 2019 03:27

apropos man: Sep 5, 2016; You get a hundred and forty one thousand years and you're out in eight!

G-Prime posted:

Their demise is greatly overstated. At the end of the day, Antergos was 95% Arch with a pretty installer and some metapackages. They're going to be releasing most of the metapackage stuff to AUR and an update that reverts the references to their repos to fall back to the standard Arch ones. It's really not that big of a deal. I'll be sad to see them go, and it means that standing up a new Arch install is going to take a little longer, but it's not that big of a deal.

I concur that, after listening to the latest Linux Unplugged pod yesterday, it seems that the main stream of security updates etc are going to be kept going for a while. I dunno how Arch works although in the past I have installed it from scratch, had a brief dabble with Antergos, and used Manjaro for a few weeks on a 2nd PC. Do all distros share the same AUR?

Anyway, from what they were saying about the Antergos project, you'll be fine with updates for a while. Yes, you probably should think about moving to a new distro but I there's no need to panic and rush it. That's for the other poster, not G-Prime.

Edit: maybe it was for G-Prime. I'm on my phone and can't be bothered to scroll that far back.

In other news: I set up a Fedora 30 virt host the other day. Yesterday I SSH in to configure a network bridge to hang some VM's off of. The /etc/sysconfig/network-scripts/ directory was empty. Genuine WTF moment from me. I had to use nmcli to create the bridge.

apropos man fucked around with this message at 06:57 on May 24, 2019

# ? May 24, 2019 06:53

Kreeblah: May 17, 2004; INSERT QUACK TO CONTINUE; Taco Defender

RFC2324 posted:

Seems like it would be fairly trivial to script something

Probably, though I noticed my printer has a built-in FTP server that'll print out PDFs, so I just had to point the scanner at that and I was good to go.

# ? May 24, 2019 07:42

other people: Jun 27, 2004; Associate Christ

jaeger posted:

I'm late to the party on this one but surprised so many people say setting NIC device names is so tough. In my experience it only takes 2 lines in /etc/sysconfig/network-scripts/ifcfg-whatever:

HWADDR=<your MAC, of course>
DEVICE="the name"

For example, in a test VM:
code:
# egrep 'DEVICE|HWADDR' /etc/sysconfig/network-scripts/ifcfg-enp0s3
DEVICE="somethingawful0"
HWADDR=08:00:27:7e:99:ae
# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: somethingawful0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:7e:99:ae brd ff:ff:ff:ff:ff:ff
The value of net.ifnames makes no difference in this case.

Apologies if I've missed something essential, just wanted to chip in that this is easy.

That is all fine as long as the DEVICE name is not set to some ethX name which it was in this case. Since the kernel assigns an ethX name to each interface as drivers load in a non-deterministic order, udev's renaming attempt may fail if the name is already in use. Older, pre-systemd releases of udev tried to handle collisions by doing a renaming dance but that code has long since been removed as it was never foolproof.

Basically, if you are trying to assign a specific name, stay away from a form that matches what the kernel uses (ethX) and stay away from udev-styles like enoX, ensX, enpXsY and biosdevname emX, etc unless you also disable those features (net.ifnames=0, biosdevname=0).

RHEL8 comes with a neat userspace helper that will automagically set up a consistent mapping for the system using a given prefix. So you can have say net0, net1, net2, etc without having to manually set it up beyond specifying 'net' as the input prefix. But again, it will fall on its face if you try to use the prefix 'eth' since that is "reserved" by the kernel.

# ? May 24, 2019 09:45

G-Prime: Apr 30, 2003; Baby, when it's love,
if it's not rough it isn't fun.

apropos man posted:

I concur that, after listening to the latest Linux Unplugged pod yesterday, it seems that the main stream of security updates etc are going to be kept going for a while. I dunno how Arch works although in the past I have installed it from scratch, had a brief dabble with Antergos, and used Manjaro for a few weeks on a 2nd PC. Do all distros share the same AUR?

Anyway, from what they were saying about the Antergos project, you'll be fine with updates for a while. Yes, you probably should think about moving to a new distro but I there's no need to panic and rush it. That's for the other poster, not G-Prime.

Edit: maybe it was for G-Prime. I'm on my phone and can't be bothered to scroll that far back.

In other news: I set up a Fedora 30 virt host the other day. Yesterday I SSH in to configure a network bridge to hang some VM's off of. The /etc/sysconfig/network-scripts/ directory was empty. Genuine WTF moment from me. I had to use nmcli to create the bridge.

AUR is common and can be openly contributed to. The thing a lot of people are missing is that Arch maintains its own repos, and Antergos was sticking an extra repo on top of those to provide distro-specific packages. The majority of packages you install on Antergos are coming straight out of the standard Arch repos. You can think of it similarly to how Mint uses the Ubuntu repositories, but also has their own. If Mint shut down today, the majority of stuff would be fine because Ubuntu is still live. Contrast this against Ubuntu using Debian as a base and you'll see a stark difference, because Ubuntu fully manages and builds packages for everything in its repos and doesn't provide Debian repos as a fallback (also, Ubuntu is consistently ahead of Debian and the closest thing it could be compared to is Debian Unstable).

Manjaro is comparable to the Ubuntu/Debian thing. They maintain their own repos and put things into them at their own pace, which doesn't inherently match the pace of mainline Arch.

Edit: Apparently, members of the community are already picking up the torch and continuing in the spirit of Antergos under a new name (at the previous team's request), Endeavour.

G-Prime fucked around with this message at 13:22 on May 24, 2019

# ? May 24, 2019 13:16

apropos man: Sep 5, 2016; You get a hundred and forty one thousand years and you're out in eight!

Interesting. Thanks.

Meanwhile, in Red Hat land, anyone know what the official line is in configuring network interfaces now that Fedora have decided to remove ifcfg scripts? I used nmcli to sort out my bridge, but I don't know what the suggested method is.

# ? May 24, 2019 14:46

CommieGIR: Aug 22, 2006; The blue glow is a feature, not a bug; Pillbug

apropos man posted:

Interesting. Thanks.

Meanwhile, in Red Hat land, anyone know what the official line is in configuring network interfaces now that Fedora have decided to remove ifcfg scripts? I used nmcli to sort out my bridge, but I don't know what the suggested method is.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-configure_network_bridging

# ? May 24, 2019 14:51

jaeger: Jul 28, 2005; ...

jaeger posted:

Ah, ok, I think I get you now. Sorry for the confusion. Does it make any difference then if you leave net.ifnames set to 1? I mean if net.ifnames is 1, does the kernel ever create the 'ethX' devices at all? If not, leaving net.ifnames set to 1 and using DEVICE=ethX is an easy solution. If, on the other hand, net.ifnames=1 just means they're created initially with ethX names and then renamed every time, it could still be a problem.

Just wondering because I have a few systems at work doing this very thing with no problems. One such system has 9 physical interfaces and I forced it to name them eth[0-8] in order of MAC address without any issues.

I can tell you from experience that yes, it very much does matter. I'm glad you were able to chip in 3 weeks later telling me how easy it was though :P

# ? May 24, 2019 16:29

jaeger: Jul 28, 2005; ...

originalnickname posted:

I can tell you from experience that yes, it very much does matter. I'm glad you were able to chip in 3 weeks later telling me how easy it was though :P

Sorry, didn't do it to be a jerk. I was trying to understand the difficulty.

# ? May 24, 2019 17:05

Axe-man: Apr 16, 2005; The product of hundreds of hours of scientific investigation and research.

The perfect meatball.; Clapping Larry

I name all my ethos ports by osmosis.

# ? May 24, 2019 17:20

other people: Jun 27, 2004; Associate Christ

jaeger posted:

Ah, ok, I think I get you now. Sorry for the confusion. Does it make any difference then if you leave net.ifnames set to 1? I mean if net.ifnames is 1, does the kernel ever create the 'ethX' devices at all? If not, leaving net.ifnames set to 1 and using DEVICE=ethX is an easy solution. If, on the other hand, net.ifnames=1 just means they're created initially with ethX names and then renamed every time, it could still be a problem.

Just wondering because I have a few systems at work doing this very thing with no problems. One such system has 9 physical interfaces and I forced it to name them eth[0-8] in order of MAC address without any issues.

When a NIC driver loads, kernelspace assigns a name in the format ethX where X is the lowest currently unused number. The kernel is inherently stateless and there is no guarantee drivers will always load in the same order so the kernel-assigned ethX names cannot be expected to be consistent across reboots ( though if you only have one interface or they all use the same driver it probably will be 99% of the time). So for consistency, an OS must havr some userspace component to rename the interfaces when they appear. For most (all?) current distros this is some set of udev rules/scripts/helpers. net.ifnames is a setting recognized by systemd-udev to enable/disable the enoX/ensX/enpXsY style naming; it means nothing to the kernel itself.

# ? May 24, 2019 18:05

other people: Jun 27, 2004; Associate Christ

apropos man posted:

Interesting. Thanks.

Meanwhile, in Red Hat land, anyone know what the official line is in configuring network interfaces now that Fedora have decided to remove ifcfg scripts? I used nmcli to sort out my bridge, but I don't know what the suggested method is.

RHEL8 still uses ifcfg files. NetworkManager reads/writes them via its ifcfg-rh plugin.

I guess if you do not see ifcfg files in current fedora but it still uses NM then maybe they have changed the default NM settings to use the keyfile plugin? That saves configs in a concise format in /etc/NetworkManager/system-connections/ or something like that.

But using NM remains the same regardless of plugin. nmcli/nmtui etc will all work the same.

# ? May 24, 2019 18:09

CommieGIR: Aug 22, 2006; The blue glow is a feature, not a bug; Pillbug

apropos man posted:

Here's what I've got:

code:

[root@stib ~]# cd /etc/NetworkManager/
[root@stib NetworkManager]# ll
total 24K
drwxr-xr-x. 2 root root 4.0K Mar 15 16:27 conf.d
drwxr-xr-x. 5 root root 4.0K May 19 09:12 dispatcher.d
drwxr-xr-x. 2 root root 4.0K Mar 15 16:27 dnsmasq.d
drwxr-xr-x. 2 root root 4.0K Mar 15 16:27 dnsmasq-shared.d
drwxr-xr-x. 2 root root 4.0K Mar 15 16:27 system-connections
-rw-r--r--. 1 root root 2.1K Mar 15 16:27 NetworkManager.conf
[root@stib NetworkManager]# cd system-connections/
[root@stib system-connections]# ll
total 0
[root@stib system-connections]# ll /etc/sysc
sysconfig/   sysctl.conf  sysctl.d/    
[root@stib system-connections]# ll /etc/sysconfig/network-scripts/
total 8.0K
-rw-r--r--. 1 root root 318 May 22 23:38 ifcfg-bridge-br0
-rw-r--r--. 1 root root 117 May 22 23:38 ifcfg-bridge-slave-enp9s0
[root@stib system-connections]# cat /etc/redhat-release 
Fedora release 30 (Thirty)
[root@stib system-connections]#

Oh sorry; I misunderstood what you originally wrote.

Your query was about the lack of ifup-eth, ifdown-eth, etc scripts in the network-scripts directory, right?

Those were part of the "legacy" network service scripts. Just simple bash scripts that ran a series of "ip" commands based upon ifcfg file settings. It worked great in many ways but was basically a "dumb" one-shot thing.

Those are no longer actively developed, or at least no longer actively developed by RH (someone is going to prove me wrong here maybe). The NetworkManager service is in charge now. It talks to the kernel via libnl3 (netlink) to do everything and then can be actively aware of changes etc.

So your settings are still saved in ifcfg files for legacy reasons but the ol' network scripts are gone. Maybe they are buried in some optional package if there is some need for them but I'm fone posting so I decline to check right now.

# ? May 24, 2019 19:05

apropos man: Sep 5, 2016; You get a hundred and forty one thousand years and you're out in eight!

Yeah, that's what I was getting at. I don't mind, for home use. I usually leave NetworkManager running on my home stuff but we use a lot of RHEL and CentOS boxes at work for running our application and DB servers on.

The boss has everything configured with NetworkManager disabled and most (if not all!) of our Linux boxes are configured with static IP's using the ifcfg scripts. A lot of our stuff is still on RHEL6, mind.

We're actively trying to update everything to RHEL/CentOS 7 and it's coming along. I guess when we jump from 7 to 8 we will have to look at using NetworkManager in future.

# ? May 24, 2019 19:19

Adbot: ADBOT LOVES YOU

# ? Apr 24, 2024 04:09

waffle iron: Jan 16, 2004

I like headless NUC style machine at home running Debian I use systemd-networkd. Although my setup is so extremely plain (wired DHCP).

# ? May 24, 2019 23:24

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1024 »

pahuyuth posted:

code:

code:

code:

An Enormous Boner posted:

Volguus posted:

telcoM posted:

Volguus posted:

fedoraproject.org posted:

taqueso posted:

mystes posted:

G-Prime posted:

General_Failure posted:

Kreeblah posted:

General_Failure posted:

Double Punctuation posted:

originalnickname posted:

code:

G-Prime posted:

RFC2324 posted:

jaeger posted:

code:

apropos man posted:

apropos man posted:

other people posted:

jaeger posted:

originalnickname posted:

jaeger posted:

apropos man posted:

other people posted:

other people posted:

code:

apropos man posted:

code: