Summary: | dbus[n]: Unknown group "netdev" in message bus configuration file | ||
---|---|---|---|
Product: | IPFire | Reporter: | Jon <jon.murphy> |
Component: | --- | Assignee: | Adolf Belka <adolf.belka> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | - Unknown - | ||
Priority: | - Unknown - | CC: | adolf.belka, peter.mueller |
Version: | 2 | ||
Hardware: | unspecified | ||
OS: | Unspecified | ||
See Also: |
https://bugzilla.ipfire.org/show_bug.cgi?id=12916 https://bugzilla.ipfire.org/show_bug.cgi?id=13121 |
||
Attachments: | updated install.sh file for avahi addon |
Description
Jon
2022-12-10 17:03:43 UTC
Created attachment 1127 [details]
updated install.sh file for avahi addon
In the install.sh file from the avahi paks set the avahi user and group are created. What is not created is the netdev group.
Attached is the updated install.sh file with the third getent line being the additional line that checks if the netdev group exists and if not it creates it.
If you are able to test this then if you run that command
getent group netdev > /dev/null || groupadd -r netdev
then that should create the netdev group, if it does not exist, and if you then reboot it should no longer show that error message.
The modified install.sh file is what I am running in my build currently with some other package updates and if you are able to say that it works then I could use that input in the patch and specify that it has been tested by you when I submit my patches later today or tomorrow.
Works A-OK. Survives the reboot! And no "Unknown group "netdev" in message bus configuration file " message. Yay! Does IPFire follow the ID number in the LFS guide? If yes, then the command changes to: `groupadd -fg 86 netdev` and avahi changes to: `groupadd -fg 84 avahi` FYI - UID/GID Suggested Values https://www.linuxfromscratch.org/blfs/downloads/11.2/BLFS-BOOK-11.2-nochunks.html#postlfs-users-groups (In reply to Jon from comment #2) > Works A-OK. Survives the reboot! And no "Unknown group "netdev" in message > bus configuration file " message. Yay! > > Does IPFire follow the ID number in the LFS guide? If yes, then the command > changes to: > > `groupadd -fg 86 netdev` > > and avahi changes to: > `groupadd -fg 84 avahi` If you already have avahi installed then the avahi groupadd command won't make a difference as the code checks if it exists and if it does then it doesn't change anything. Also -fg 84 doesn't ensure that the gid will be 84 it says make it 84 unless that gid is already used in which case use the next free one. If you run the command getent group avahi on your ipfire it will tell you what gid was used when it was first installed. Mine came up with avahi:x:999: Unless I manually delete that group it will stay with that gid. I don't think it makes much difference what actual number is used in the majority of cases. The only case I have where the gid is important is on my nfs file server where I want the owner and group of a file to look the same on every pc that accesses it. For that I had to ensure that the user and group names had the same gid on every pc I use to access the nfs. That doesn't include IPFire as it doesn't need to access my nfs file server and I don't want it to be accessing my file server as that potentially opens attack paths to IPFire. So I don't intend to change the coding from what it was and will just let IPFire choose the next available system gid for the netdev group. If Michael or the other devs decidfe it should be different then I will change it. I have never seen anything in IPFire that is specifying the uid or gid used by a package, only the name. Forgot to say, thanks for testing and confirming that it solves the netdev group bug. I will add that into the patch commit. Patch submitted to patchwork https://patchwork.ipfire.org/project/ipfire/patch/20221211123330.5155-1-adolf.belka@ipfire.org/ Patch has been committed into next https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=15214970e65ae371852305c97743205803d0847e Core Update 173 Testing has been released. https://blog.ipfire.org/post/ipfire-2-27-core-update-173-is-available-for-testing Installed avahi on m y vm testbed clone with CU173 Testing. Then checked the /etc/group file and confirmed that the netdev group was present. So this should work but it would be good if @Jon could test and confirm. all looks A-OK! ``` [root@ipfireAPU ~] # /etc/rc.d/init.d/messagebus start Starting the D-Bus Messagebus Daemon... [ OK ] [root@ipfireAPU ~] # ``` Tested with: APU4D4 IPFire 2.27 (x86_64) - Core-Update 173 Development Build: master/fa2f6cb6 (In reply to Jon from comment #10) > all looks A-OK! > > ``` > [root@ipfireAPU ~] # /etc/rc.d/init.d/messagebus start > Starting the D-Bus Messagebus Daemon... [ OK ] > [root@ipfireAPU ~] # > ``` > > Tested with: > APU4D4 > IPFire 2.27 (x86_64) - Core-Update 173 Development Build: master/fa2f6cb6 Thanks for the confirmation that it works. Status has been changed to Verified |