Re: It’s time to transform the Fedora devel list into something new
On 4/23/23 18:32, Kevin Fenzi wrote: You can write the tag after the plus sign if that makes it easier to implement. Instead of"fedoraproject+newto...@discoursemail.com" the address could be"fedoraproject+de...@discoursemail.com" or maybe "fedoraproject+devel/newto...@discoursemail.com". Or some other format. The local-part can be structured any way the Discourse developers like, as long as it's at most 64 bytes and adheres to the dot-atom-text syntax in RFC 5322. But that also doesn't solve the spam problem... anyone could send to those addresses, and indeed spammers will. ;( I have not used the forum mailing lists so I don't know if they already include the following: Perhaps in each email include the url corresponding to the forum post, so that if you want to answer it, you have to do it from the forum, so the mailing lists can be read-only Gabrielo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/10/22 16:10, Neal Gompa wrote: On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski wrote: On Friday, 08 April 2022 at 16:14, Zamir SUN wrote: [...] Probably it isn't a problem for some users, but I'm still having bad experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 system that works fine with UEFI. And my parents' laptop was purchased 2 years ago and the UEFI firmware does not allow to boot anything other than Windows on UEFI mode (regardless of turning secure boot on or off) and I have to switch to BIOS mode to make Fedora work there. So in this situation, I think it's way too aggressive to accept the change - this will probably drive away some potential new users with decent laptop like my parents'. Have you tried renaming your Fedora boot entry to "Windows Boot Manager"? I have one Sony laptop that boots only the boot entry with that exact name. I wonder if this would work with one of my old machines too. I've never thought to rename the boot entry in the firmware before... about "Windows Boot Manager" efi entry required to boot: https://mjg59.dreamwidth.org/20187.html the above happens too with the lenovo thinkcentre m91 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 6/27/20 11:09 PM, Chris Murphy wrote: On Sat, Jun 27, 2020 at 9:25 PM Gabriel Ramirez wrote: On 6/27/20 9:06 PM, Chris Murphy wrote: Just a PSA: btrfs raid1 does not have a concept of automatic degraded mount in the face of a device failure. By default systemd will not even attempt to mount it if devices are missing. And it's not advised to use 'degraded' mount option in fstab. If you do need to mount degraded and later the missing device is found (?) you need to scrub to catch up the formerly missing device to the current state. That seems a step back, Yes. You do gain self-healing and unambiguous scrubs, which apply only to the used portion of the drives. Three steps forward half step back? The priority would be to replace the failing/failed drive before a reboot. Yes, the use case where the drive dies on startup and unattended boot is needed is weaker. yeah, but coming from mdadm, I (will be)/(was) expecting the same or better from a new filesystem, or documentation to resolve the situation "shutdown, replace the disk, boot with another media etc..." because when the problem happens, googling sometimes fails too 'btrfs replace' - There will be a "decoder ring" guide to adapt to various commands. A super rough draft, more of a quick and dirty concept, is here: https://fedoraproject.org/wiki/User:Chrismurphy/lvm2btrfs And hopefully this will expand into "how do I?" step by step use cases. that will be appreciated because btrfs seems to have many options Of course the single drive case folks aren't expected to know btrfs commands. If they want more detailed info however, they're there. start the machine with all services running create the disk partitions, if needed reboot again, and add the partitions to the raid devices Off hand I'm not thinking a reboot is needed. You can partition the replacement drive, and then do 'btrfs replace' - whether it's pre-emptive or for a missing device. This command combines: mkfs / device add, and replication of raid1 block groups using a variation on scrub. at least one shutdown, start is needed (I have to open the computer case, replace the hard disk) another reboot if after partition the drive the kernel complains about "the current partition will be used until reboot" Gabriel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 6/27/20 9:06 PM, Chris Murphy wrote: On Sat, Jun 27, 2020 at 7:32 PM Garry T. Williams wrote: On Saturday, 27 June 2020 17:29:23 EDT Chris Murphy wrote: For btrfs, it is either 'single' or 'raid0' profile for data, but 'raid1' for metadata (the file system itself). I need to test it or maybe someone beats me to it by looking at the code. But either way it's equal to or better than the current default. I just did that install (KDE) and it was raid0 for data (raid1 for metatdata). I switched to raid1 for data as soon as I noticed what had happened. Just a PSA: btrfs raid1 does not have a concept of automatic degraded mount in the face of a device failure. By default systemd will not even attempt to mount it if devices are missing. And it's not advised to use 'degraded' mount option in fstab. If you do need to mount degraded and later the missing device is found (?) you need to scrub to catch up the formerly missing device to the current state. That seems a step back, in my current scenario almost all my machines have 2 disks (not hotswap) in raid 1 with mdadm and the partitions are ext4, so when a disk failed: the machine keeps working until I do a shutdown replace the disk start the machine with all services running create the disk partitions, if needed reboot again, and add the partitions to the raid devices So seems with btrfs raid in my situation more downtime will be required, but I always do custom partitioning, so this change doesn't impact me, but if more people will be use btrfs it need more documentation. and yeah sometime a disk was missing and after a reboot was found so I has to add it to the raid devices again, but the machine was online too Gabriel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Abotu setting 'PermitRootLogin=no' in sshd_config
On 11/25/2014 09:45 AM, P J P wrote: On Tuesday, 25 November 2014 8:53 PM, Kevin Fenzi wrote: On Tue, 25 Nov 2014 09:56:59 -0500 Simo Sorce wrote: We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible. This has been the reason this hasn't been changed the last few times someone proposed to change it. I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage. If you want to remove root access that should be conditionally done at firstboot only if a user account was created. This seems a more reasonable place to look to change this, I agree. True, this concern has been raised before. We need to ensure that user creates at least one non-root user account; firstboot is just the right place to ensure that. no need to create a user account in *all* installs I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's, so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Abotu setting 'PermitRootLogin=no' in sshd_config
On 11/25/2014 11:05 AM, P J P wrote: Hi, On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's, so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple, True, it is complex. Maybe we could have an option in firstboot(and other such places) by which user can override the default non-root account creation. Ie. Say a user is prompted to create non-root user account; He/she can choose to override it and not create one. In such workflow, he/she is warned about the possible lockout situation and duly advised to explicitly enable remote root login in sshd_config(5). (Just a thought) --- Regards -Prasad http://feedmug.com thanks, in my multiple re installs, I can live with the following: an user prompt to create a user account and press no or setting an one more option in kickstart to prevent create a user account and change myself the ssh default to permit rootlogin to yes but not with: creating a user account by default logging with that account, change the sshd default to yes logoff logging with root delete the user account -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Per-Product Config file divergence
On 03/10/2014 12:44 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd rather see us handle things this way: fedora-release Requires: fedora-release-variant fedora-release-$PRODUCT[1] Provides: fedora-release-variant The first fedora-release-$PRODUCT package installed on the system sets the base product/spin appropriately (in some well-known config file, not necessarily /etc/os-release) but what happens with the people using kickstarts to install Fedora, by example I'm using kickstarts to install the following - @core @standard groups and 5 to 10 specific rpms (bind, lighttpd, postfix) - @core @base-x @virtualization and a list of 300 rpms packages so will be required to install a product (fedora-release-variant) and by consequence add more rpms to my kickstarts installs? thanks, Gabrielo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
