Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On 12/23/23 16:40, Sam Varshavchik wrote: Christopher Klooz writes: Btw, does anyone know if this (in the practically-same manner) is really already introduced in Windows, Mac, Android by default? Globally? This Most recent Android phones, and iPhones do this by default. What they do is pin each randomized MAC address per AP. They're not randomizing MACs for each connect, but basically generate a randomized MAC for each AP known to the phoneto spam, report it: https://pagure.io/fedora-infrastructure/new_issue I hope that's per SSID and not per AP, or else that would mean that as a device roams among access points in my network it would keep generating new MAC addresses that are not known to my DHCP server? It's bad enough that I can't know in advance what MAC address a new device will be using, and might thus have to decide which, of several possible DHCP requests that might appear, is the one to which I want to grant access. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. -- ___ 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: Need help with nut systemd scriptlets and multiple services and targets
On 4/7/23 16:17, Orion Poplawski wrote: On 4/6/23 21:27, Robert Nichols wrote: ... The user needs to enable nut-driver-enumerator.service if there is any UPS hardware monitored by this system (i.e., not needed if this is a "secondary" system and some other "primary" system is actually monitoring the UPS). Why should the user have to explicitly enable nut-driver-enumerator.service? It does seem necessary for some reason to enable it to have it start with nut.target below. But I don't understand why. It has PartOf=nut.target: [Unit] # This unit starts early in system lifecycle to set up nut-driver instances. # End-user may also restart this unit after editing ups.conf to automatically # un-register or add new instances as appropriate. Description=Network UPS Tools - enumeration of configure-file devices into systemd unit instances After=local-fs.target Before=nut-driver.target PartOf=nut.target just like nut-server.service: But nut.driver.target is an empty target that contains no "wants". If you enable nut-driver-enumerator.service, that generates a link in /etc/systemd/system/nut.target.wants, so the enumerator gets started when nut.target starts. Unless the user explicitly enables the enumerator service, nothing starts it. I had some discussion of this with the developer on <https://github.com/networkupstools/nut/issues/1851#issuecomment-1436621461>. The developer seems to feel it's just a documentation issue. The docs currently imply that the enumerator starts automatically. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ___ 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: Need help with nut systemd scriptlets and multiple services and targets
On 4/6/23 17:56, Orion Poplawski wrote: The nut package has a number of different systemd units: /usr/lib/systemd/system/nut-driver-enumerator.path /usr/lib/systemd/system/nut-driver-enumerator.service '/usr/lib/systemd/system/nut-driver@.service' /usr/lib/systemd/system/nut-driver.target /usr/lib/systemd/system/nut-server.service /usr/lib/systemd/system/nut.target And I have a number of questions about how to handle them: * I think we want a preset to automatically enable and start nut-driver-enumerator.path. This monitors /etc/ups/ups.conf and runs nut-driver-enumerator.service when it does. It also has: [Install] WantedBy=nut.target Does that seem appropriate? Is is possible to start it immediately after install in %post? You don't want to start _anything_ until the user has done the rather extensive editing required in the config files to tell the package what hardware to look for and what to do. * What is a user expected to do to enable and start "nut"? It seems like: systemctl enable nut.target systemctl start nut.target The user needs to enable nut-driver-enumerator.service if there is any UPS hardware monitored by this system (i.e., not needed if this is a "secondary" system and some other "primary" system is actually monitoring the UPS). Then, running "systemctl enable nut.target" will start the package on the next boot. Include "--now", or run "systemctl start nut.target" to start it immediately. But all of that has to wait until the user has made the necessary edits in the config scripts in /etc/ups.conf and edited the /usr/bin/upssched-cmd script to set up any additional actions (e.g., notifications, etc) that are wanted. Would do the trick, but I don't think it's very intuitive - most users think in terms of service units I think. Overall, it's a pretty user-unfriendly package. Some things that used to "Just Work" back in the days of CentOS 6 need manual configuration now. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ___ 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
[EPEL-devel] Re: partclone-0.3.12-1.el7 fails to clone and restore FAT12 partition
On 8/8/19 3:40 PM, Robert Nichols wrote: Where can I find the 0.3.11 RPM? I don't have it saved anywhere, and I need to downgrade one system. OK. I found the archive directory. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] partclone-0.3.12-1.el7 fails to clone and restore FAT12 partition
The new version of partclone (0.3.12-1.el7) will not properly save and restore FAT12. If I save a FAT12 EFI partition with "partclone.fat12 -c -o test.pcl -i /dev/sdg2" and then restore it to a different device with "partclone.restore -i testpcl -o sdh2", then the restored filesystem has I/O errors when listing directories. The previous version of partclone (0.3.11) will segfault when trying to take input from this test.pcl file. Version 0.3.11 has no problem working with these same devices itself. Anyone else? I don't see anything in the Fedora EPEL for partclone. Where can I find the 0.3.11 RPM? I don't have it saved anywhere, and I need to downgrade one system. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Package zbar blocks ImageMagick update for CentOS 6.7
zbar requires libMagickWand.so.2 and libMagickCore.so.2 from ImageMagick-6.5.4.7-7.el6_5 The ImageMagick-6.7.2.7-2.el6 update provides libMagickWand.so.5 and libMagickCore.so.5 Error: Package: zbar-0.10-7.el6.x86_64 (@epel) Requires: libMagickCore.so.2()(64bit) Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@anaconda-CentOS-201410241409.x86_64/6.6) libMagickCore.so.2()(64bit) Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base) Not found Error: Package: zbar-0.10-7.el6.x86_64 (@epel) Requires: libMagickWand.so.2()(64bit) Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@anaconda-CentOS-201410241409.x86_64/6.6) libMagickWand.so.2()(64bit) Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base) Not found -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On 04/30/2015 06:37 PM, Adam Williamson wrote: I'd prefer objective analysis over anecdata. poettering's contention is : i) there is only a problem if you have time-based fsck enabled ii) this is not the default In addition, it's only going to be a problem when fsck is run during early boot, before the kernel's clock has been adjusted for having been initially set to local time from the RTC. And even then, it depends on whether your time zone offset is positive or negative. In the goode olde days, fsck was performed from rc.sysinit long after the kernel's clock was set correctly, so the effect of RTC in local time was just some bogus timestamps in the boot log. Now, with more tasks performed in early boot, the effect of a large positive or negative shift in the kernel's clock can be more severe. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- 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: Flash plugin 0-day vulnerability in the wild
On 01/23/2015 09:29 AM, Daniel J Walsh wrote: On 01/23/2015 10:25 AM, poma wrote: Until this is resolved, is this a valid way: $ sandbox -X -T tmp -t sandbox_web_t firefox to cover this security issue, or can we isolate only libflashplayer.so, not the entire browser. Daniel, can you comment. libflashplayer.so runs within the Mozilla-plugin I believe. If so it would be confined if you have not turned on the unconfined_mozilla_plugin_transition boolean. If this is the case we are somewhat protected, and of course you run with setenforce 1. sandbox -X will also add more protection. Is that boolean just very badly named/described, because it certainly sounds like it works the opposite of what you said above: Allow unconfined users to transition to the Mozilla plugin domain when running xulrunner plugin-container. The only possible way I can read that is to say that with the boolean _set_ execution will transition to the confined plugin domain, and with the boolean _unset_ it will remain unconfined. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- 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: /media - /run/media???
On 08/17/2014 12:31 PM, Nico Kadel-Garcia wrote: On Sat, Aug 16, 2014 at 1:54 PM, Jon jdisn...@gmail.com wrote: The rationale here is that media mounts for a seated user are part of that users run-time, or session. By placing them in an area exclusive to the seated user, the system as a whole is more secure. And that could have been put at /media/$username/$medianame. Not one part of that security practice change required using /run Calling stored content, typically used across multiple sessions and often used for archival or non-writable storage, part of the run-time data is a serious misreading of what the run-time data of the FHS spec describes. The language is clearly aimed at PID data and similar boot-time erasable data. I've never personally used attachable media that I scrubbed, or expected to be scrubbale, with everey reboot. The media would not get scrubbed since it is not yet mounted at that point in the boot sequence. What _does_ get scrubbed is any leftover /run/media/$USER directories and the temporary mount points they contain, which is arguably preferable to allowing that cruft to accumulate in /media. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- 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: F20 System Wide Change: No Default Sendmail
On 07/22/2013 05:36 PM, Lennart Poettering wrote: Also, cronie will split up the messages by line anyway if it logs to syslog instead of sendmail. That sounds particularly horrible for concurrent cron jobs that would thus have their output interleaved in the log. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On 07/22/2013 11:36 AM, Lennart Poettering wrote: I am pretty sure that most of the stuff we currently mail (like the log output of cron jobs) simply makes no sense as mail, and should much rather be treated exactly like all other log output. There's nothing special really about cron that would make it so much better suitable for sending out its logs per mail, rather then just log them. How many megabytes can the log system reasonably accept in a single message? The output from a cron job can be a lot more than what anyone would consider to be a reasonable log message. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On 07/15/2013 09:14 AM, Lennart Poettering wrote: This feature is about not doign local mail delivery by default, by not installing any MTA. Instead you find the log output of cronjobs at the same place as you find any other log output, the journal/syslog, for example accessible via: journalctl -u crond or systemctl status crond (the latter will only show you 10 log lines by default, the former all of them. You can pass -n 100 to either to see the 100 latest ones) You are thinking only about error output from cron jobs. Regular output from cron jobs can be quite voluminous. Is it reasonable to send 15 to 20 Kilobytes to the journal (root's logwatch job currently sends that much every day)? How about a couple of JPGs (graphs of resource usage)? -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On 07/15/2013 04:17 PM, Eric Smith wrote: On Mon, Jul 15, 2013 at 3:14 PM, Till Maas opensou...@till.name wrote: But the information cron sends via email is usually more important than the regular log entries, because output in cron jobs usually means there is an error. It seems wrong to store the important data hidden among less important data. Then the syslog severities are configured wrong. That's not a good justification for using email rather than syslog. So, all users on a multi-user system are now expected to dig through syslog output to see the output from their cron jobs? And of course, syslog output will now be stored somewhere that is, by default, world readable, right? -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/15/2012 09:20 PM, Sam Varshavchik wrote: I think that 99% of the problems that prelink is creating can be easily avoided simply by having prelink automatically skip executables that are currently running. This is something that should not be very difficult to do. All the information is trivially obtainable from /proc/*/exe. That would mean that prelink would skip much of a running system, and a full prelink could be done only by booting from separate media. Not going to happen. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/15/2012 01:10 PM, Jef Spaleta wrote: Generally speaking do we have a cron-like service that knows how to taste for onbattery in a high level way? Or do we have to encode that check into each script that fires from a cron-like service? In /etc/cron.hourly/0anacron there is a test using /usr/bin/on_ac_power before starting the anacron daemon, though I would consider it a shortcoming that this test is performed when anacron is started rather than when the actual jobs are run, which could be up to $RANDOM_DELAY minutes later. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder: Fedora 13 end of life on 2011-06-24
On 06/12/2011 07:27 PM, Josh Stone wrote: On 06/12/2011 04:11 PM, nomnex wrote: I might wait for F16 to do a clean install. It's the first time I reach an EOL. Can you tell me if the packages in the F13 repository remains available (even though the packages are not updated) past June, or not? Thanks The archives are here: http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/13/ http://archive.fedoraproject.org/pub/archive/fedora/linux/updates/13/ I'm pretty sure the mirror manager will do the right redirect for this. It's certainly doing that just fine for me with my (mostly) Fedora 12 systems. The mirror manager comes back with archive.fedoraproject.org plus a handful of mirrors that still carry F12. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On 05/18/2011 04:04 PM, Lennart Poettering wrote: Host requests power down from UPS in 30s. Host then continues shut down. If the host now ends up taking more time then expected for shutting down it might still be busy at the time of the power going away. It's a race between UPS powering off and system finishing shutdown. It's a bet that your system is faster than 30s when unmounting the remaining file systems, syncing the MD/DM metadata to disk, syncing ATA and so on (i.e. all the stuff the kernel does when you invoke the reboot() syscall). Here's another race. Host requests power down from UPS in 30s. Host completes shutdown. At some point during that 30s interval, commercial power is restored. Result: Host shuts down and never restarts. Sorry about that. The way I've always prevented that is to have the host do a reboot, not a shutdown, but send an immediate shutdown command to the UPS just before sending control to the BIOS for the reboot. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On 05/18/2011 06:42 PM, Simo Sorce wrote: On Wed, 2011-05-18 at 16:48 -0500, Robert Nichols wrote: On 05/18/2011 04:04 PM, Lennart Poettering wrote: Host requests power down from UPS in 30s. Host then continues shut down. If the host now ends up taking more time then expected for shutting down it might still be busy at the time of the power going away. It's a race between UPS powering off and system finishing shutdown. It's a bet that your system is faster than 30s when unmounting the remaining file systems, syncing the MD/DM metadata to disk, syncing ATA and so on (i.e. all the stuff the kernel does when you invoke the reboot() syscall). Here's another race. Host requests power down from UPS in 30s. Host completes shutdown. At some point during that 30s interval, commercial power is restored. Result: Host shuts down and never restarts. Sorry about that. The way I've always prevented that is to have the host do a reboot, not a shutdown, but send an immediate shutdown command to the UPS just before sending control to the BIOS for the reboot. What you should do is to configure the BIOS to always boot on power-up. This way the UPS will remove power, figure out power is returned, reapply power and the BIOS will reboot the machine. Telling my UPS to turn off merely shuts down the inverter. If it is not currently running on the inverter (because commercial power is available), that is effectively a no-op, and power at the UPS output remains on. Telling the BIOS to boot on power-up (which is how mine is configured, BTW) does nothing since _power_never_went_away_. All the BIOS sees is a command to shut down, which it does. And stays that way. Absent manual intervention, the only thing that would bring the system back up would be a power failure long enough to exceed the capacity of the essentially unloaded UPS, and that would be _quite_ a long time. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: move libusb from /usr/lib to /lib
On 06/27/2010 10:17 AM, Sam Varshavchik wrote: Robert Nichols writes: On 06/23/2010 04:24 AM, Richard Hughes wrote: On 23 June 2010 09:50, Tomasz Torczto...@pipebreaker.pl wrote: “/sbin/upsdrvctl is used as the near final step in /etc/init.d/halt to command That's completely bogus. You really don't want to just power down the machine like that -- it might lead to disk corruption and is certainly not a good idea for a server with a huge power load. I really don't think we want this feature in Fedora. That action occurs after all filesystems have been unmounted and just before /sbin/halt will be called to shut down the ATA power supply or /sbin/reboot called to send control back to the BIOS. The OS has already cleaned up for shutdown. The root filesystem is still mounted read/write, as I believe. I added a line touch /junkfile in /etc/init.d/halt just prior to the code that would turn off the UPS. The result was: touch: cannot touch `/junkfile': Read-only file system The code that remounts remaining file systems read-only is just a few lines above that. The only time that's going to fail is if some hung process resisted a kill -9 and had a file open for writing. That's going to result in a dirty file system regardless of how the shutdown is done. Shutting down the UPS is a requirement if you want the system to come back up automatically when commercial power is restored. Otherwise, the system will halt and never see a power remove/restore unless the outage exceeds the battery life of the unloaded UPS. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/18/2010 11:12 AM, Till Maas wrote: I just bought a WD20EARS and tested on F12. fdisk has an option to set the sector size to 4096 byte, but it will still use sector 63 by default for a new partition. Shouldn't it then default to sector 16, which is sector 64 with 512 byte sector size? The default pseudo-geometry will still be 63 sectors/track unless you change it, and by default a partition's start-of-data is forced to the beginning of a track. Making the sectors larger doesn't change that. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/18/2010 04:53 PM, shmuel siegel wrote: On 3/18/2010 9:47 PM, Robert Nichols wrote: The default pseudo-geometry will still be 63 sectors/track unless you change it, and by default a partition's start-of-data is forced to the beginning of a track. Making the sectors larger doesn't change that. Warning: this question is asked without any knowledge about the subject. Does it really make sense that the number of sectors/track is independent of the size of a sector? That parameter is already totally unrelated to the physical layout of data on the disk. It is no more invalid for a 4K sector size than it is for a 512-byte sector size. Really, the only thing that is affected is the amount of space that fdisk (in the default DOS Compatibility mode) leaves between a primary or secondary partition table and the start-of-data for the partition. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
