Re: systemd 230 change - KillUserProcesses defaults to yes
On 6/2/2016 7:04 AM, Lennart Poettering wrote: In all of these cases you really want to make sure that whatever the user did ends – really ends – by the time he logs out. I apologize if this has already been brought up, but I didn't see this particular point raised in the replies I've read and I wanted to be sure it is mentioned. The potential problem I see with changing the default behavior of systemd is that it is non-intuitive and could be potentially harmful if the user is not aware of it. Consider the following example. I routinely use screen when I connect to the systems I manage remotely specifically when I try to apply updates. I do this because if my VPN connection or my Internet connection is interrupted, the update process will not die with my login session. Incidentally, I learned to use screen when applying updates the hard way many years ago when a killed update wreaked havoc with a system of mine and I found screen to be an excellent solution. Currently screen is a utility whose purpose is, in part, to allow a user to disconnect from a running process in a safe way that will allow it to keep running and be resumed in the future from another session entirely. Now that will only be valid if the user knows whether or not systemd is configured on the system in question to not automatically reap these kinds of processes. This would have the effect of transforming what is clear and precise documentation of a well known and widely used utility into something that relies on another set of system configuration settings that are arguably not as intuitive. For the record, I am not trying to say I am opposed to increasing system security and progress in general in the slightest - both are laudable goals. What I am trying to say is that there is a lot of merit in making sure things are not made unnecessarily more complex and difficult to discern unnecessarily. Whatever needs to be done to increase security needs to be done while embracing the notion of not pulling the rug out from under legitimate uses of programs whose indiscriminate and unexpected reaping could cause disastrous results. Tom -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Systemd, Spamassassin, and the Missing Portreserve Package
On 2/5/2015 16:23, Tomasz Torcz wrote: SA needs portreserve exactly for the reason portreserve was written: SA assigned port is 783, and there's a risk portmap will hijack it. Missing dependency seems like packaging bug. Thanks for the insight, Tomasz! Tom -- 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: Systemd, Spamassassin, and the Missing Portreserve Package
On 2/5/2015 16:21, Kevin Fenzi wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1175798 I seem to have thought one of my co-maintainers would take care of fixing this, and perhaps he thought I was going to. ;( I'll get an update pushed out (or someone will) soon. Thanks Kevin! Tom -- 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: Systemd, Spamassassin, and the Missing Portreserve Package
On 2/5/2015 15:58, Reindl Harald wrote: why in the world does SA need portreserve? To be honest, I'm not sure that SA is the package that needs it. It is actually systemd that references it in the spamassassin.service file: # cat /usr/lib/systemd/system/spamassassin.service [Unit] Description=Spamassassin daemon After=syslog.target network.target [Service] EnvironmentFile=-/etc/sysconfig/spamassassin ExecStartPre=-/sbin/portrelease spamd ExecStart=/usr/bin/spamd $SPAMDOPTIONS StandardOutput=null StandardError=null Restart=always [Install] WantedBy=multi-user.target Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Systemd, Spamassassin, and the Missing Portreserve Package
Hello all, While configuring a new Fedora 21 workstation yesterday evening, I ran into something that I found interesting. I installed Spamassassin, tried to start it, and got the following entry in the logs: systemd: Failed at step EXEC spawning /sbin/portrelease: No such file or directory After checking "yum whatprovides /sbin/portrelease", I found it referenced portreserve-0.0.5-11.fc21.x86_64 which was not installed with Spamassassin as a dependency. Just for kicks, I looked for portrelease in the relevant systemd directory and found only Spamassassin was using it: # grep -R portrelease /usr/lib/systemd/system /usr/lib/systemd/system/spamassassin.service:ExecStartPre=-/sbin/portrelease spamd Does anyone know if this behavior is expected? The fix is easy enough, but I figured I should ask just in case it's not by design. Thanks! Tom -- 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: Improving the offline updates user experience
On 10/22/2014 10:58, drago01 wrote: No the OS is more than just a kernel. Kernel Space contains more than just the kernel. It also contains device drivers, kernel extensions, and other privileged processes that require full system access. User Space exists as a barrier to keep applications separate from the OS itself. Tom -- 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: Improving the offline updates user experience
On 10/22/2014 06:31, Lennart Poettering wrote: It would be great if we could nicely isolate the apps from the OS so that we can restart the apps independently from the OS, but this requires isolating things first. Isn't the differentiation between kernel space and user space sufficient for identifying what is the OS and what is an application? I know Windows blurred those lines during the Browser Wars with Netscape, but to my knowledge that separation still exists in Linux. Tom -- 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: No more deltarpms by default
On 10/17/2014 14:24, Rahul Sundaram wrote: Deltarpms is again enabled by default in Dnf a while back if you read the bug report. Everything else has been an tangent, yes. I suppose I'm having trouble understanding that when you started this thread with: On 10/6/2014 04:41, Rahul Sundaram wrote: One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 You wrote "dnf developers have disabled this and I think this change deserves a broader discussion." I went back and read your original post on the bug report you referenced and you said this: "Since Fedora 12 or so (my blog post on this at http://mether.wordpress.com/2009/10/01/fedora-12-and-yum-presto-plugin/) deltarpm support has been available by default for many users. dnf should enable this configuration by default as well" I even went back and read your blog post. I honestly don't understand. You say it needs to be enabled at first and now say that it's already enabled. Color me confused, my friend. Regardless, I don't think anyone, including you and I, wants to expend more bandwidth on tangential non-issues. If you say this is handled, then that's fine by me. I just wanted to be sure that everyone's bandwidth/processor issues were being adequately addressed. Tom -- 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: No more deltarpms by default
On 10/17/2014 13:19, Rahul Sundaram wrote: For the last time, my point is that: "smart" and "stupid" is not determined by whether a user understands bandwidth/processor considerations. I completely understand that not comprehending all of the complexities of bandwidth/processor considerations doesn't make one stupid. I agree wholeheartedly with you. However, you are going off on a tangent again that really has nothing to do with the point I was trying to make. I would really like to know how you can equate that with my original point: "Hey, maybe instead of throwing Presto under the bus we could discuss the option of giving users the choice to determine how much bandwidth/processor resources to throw at system updates instead." At least then we wouldn't be throwing out something that significantly benefits those who DO pay a lot of money and DO have low bandwidth connections to the Internet. It's a simple compromise: keep things configured as efficiently as possible while still allowing those who want to open up the throttle to do just that. Tom -- 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: No more deltarpms by default
On 10/17/2014 11:29, Rahul Sundaram wrote: On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote: I didn't call them stupid - in fact I suggested just the opposite. Go back and read what I wrote. I did. You said "My point is that users aren't too stupid to understand bandwidth/processor considerations". I am just saying even if one doesn't understand these considerations, they aren't stupid. If you deconstruct the sentence you quoted above, it boils down to the subject "users" and the predicate "aren't". Therefore I said quite specifically that users ARE NOT "too stupid to understand bandwidth/processor considerations." The inverse of that statement is the users ARE "smart enough to understand bandwidth/processor considerations." More to the point, I went on to bolster the notion that Linux users are capable of understanding what's at play by saying this: "These are Linux users after all." That sentence is meant to infer that using Linux requires a decent amount of skill, something that again goes against the notion that I have somehow called them stupid. Overall, the entire point of me advocating that users should be asked whether they want to endure large amounts of bandwidth/processor usage during system updates is predicated on the notion that they CAN answer the question intelligently. It would make absolutely no sense to posit querying users if they couldn't respond intelligently. Please don't persist in asserting I'm saying people are stupid. It quite simply is not the case. Tom -- 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: No more deltarpms by default
On 10/17/2014 12:11, Gerald B. Cox wrote: I think you're setting up a false equivalency here. There is a difference between the requirements of say an XBOX or Playstation user and that of updating a Fedora system. If given the choice, most people will say "Yes, I have a high speed connection... turn it on, it's more better. They won't give it a second thought. My point was to say Linux users are usually more tech savvy than XBox and Playstation users. If they say they have a high speed connection and they don't and that decision ends up costing them more money in ISP costs, then that's on them. Still, that's really not the crux of what I've been trying to say. We should be looking for ways to improve the performance of Presto...not just throwing it over the wall and assume that the network will handle it. I completely agree. My comments on this topic were meant solely to counter the notion that it must be completely abandoned, low bandwidth/high-cost bandwidth users be damned. I was merely trying to illustrate that there may be a way to make everyone happy. Tom -- 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: No more deltarpms by default
On 10/17/2014 10:43, Rahul Sundaram wrote: Wile users might be able to handle such questions (I would avoid calling them stupid even otherwise) I didn't call them stupid - in fact I suggested just the opposite. Go back and read what I wrote. , it is contrary to the goals of the installer. The Fedora installer is explicitly designed to do the absolute minimum necessary to get the installation up and running. Everything else should be handled post installation. Pre-installation, post-installation, whatever is best. I simply advocated asking a question because users are smart enough to handle it. Tom -- 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: No more deltarpms by default
On 10/17/2014 10:05, drago01 wrote: Because it makes no sense and pushes it to the user. The os (i.e we) should handle that. In that case we should do both 1) have lower bandwith requirements (i.e use deltas) *and* 2) have fast installation of updates. Those two goals are not mutually exclusive. Its just the current implementation that is lacking. So instead of messing with questions during the installation we should just fix that. If the proper configuration can be determined automagically, then by all means just do it. My point is that users aren't too stupid to understand bandwidth/processor considerations. The configuration of how much bandwidth/processor time will be involved in one configuration versus another is not rocket science. These are Linux users after all. I completely reject the notion that there isn't a simple way to phrase the configuration of how the system is update. After all, setting up a secure wireless connection is much more difficult and these same users do it every day. You customers would be *way* happier if stuff would just work without having them to mess with options until the correct configuration is found. Asking the user is the last resort when everything else fails. We configure the system for them whenever possible, so that's precisely what we do. When it comes to a subjective decision about the way the system operates after we've implemented additional functionality, we always preserve the way the system works and offer an option to change it if they so desire. By the way, considering we have a vast majority of our clients still with us and have kept them happy from the WANG 2200 days, through Xenix, SCO Unix, and on to Windows and Linux all these years from when we first opened our doors in 1985, I'd say we're doing a good job. Tom -- 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: No more deltarpms by default
On 10/17/2014 05:09, Reindl Harald wrote: on a 56kbit modem you don't want to download the full RPMs and on a 150Mbit line the download will always be faster than rebuild the RPM Perhaps this has already been suggested, but why not ask a question during the installation of the OS? For example, during the installation process it may be possible to simply ask the user whether they want to set themselves up for full downloads or not. Based on the answer to the question, you can choose delta RPMS or not. It is also possible to put something in the output of running an update that says to some effect, "If you want to limit bandwidth usage, adjust the settings here>." Those are just two examples of how it may be possible to have the best of both worlds. Anyone who has played video games over the past couple of decades knows that questions about one's Internet connection speed are the norm during installation/configuration so perhaps it makes sense to implement something similar in this instance. Also, for what it's worth, for the past 25+ years I've been part of a development team that writes code for products like a physician practice management system and software that automates wholesale distributors. Anytime we introduce a new configuration option we try to offer as much choice as possible without taking functionality away from those that expect it to remain the way it is. Choice is key in this process and every time we've embraced it our customers have been happiest. Tom -- 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: Dash as default shell
On 10/2/2014 11:13, Rahul Sundaram wrote: Sure but the rationale isn't just security as I have explained earlier. Do read the links and other mails fully. I have read the emails fully. Sure, I see where you said there were other reasons later in the discussion, but that's not what your original point was. When I addressed that initial point, you ignored the basis of what I wrote and instead brought up a technicality regarding the scope of the switch. When I pointed that out, you told me you ignored the point I was initially trying to make because it was irrelevant. All I have been trying to do is simply make the point that it is relevant. Thank you for finally acknowledging the veracity of my argument. I guess the third time really is the charm. FYI, I am a contributor for pretty much the entire history of the project and we are merely discussing something. Noone is expecting someone else to single handedly do anything. I am fully aware of your status and I never said anything about someone having to do anything single-handed. Do read what I have read fully and please don't put words in my mouth. You know, you could've simply replied to my original take on your self-described opportunistic proposal with something like, "No, Tom, I'm not just making this proposal because of Shellshock. I really think there are some merits to dash. Here are a few..." or something like that. Instead, I get a terse, cherry-picked, technical comment as to the scope of the switch followed by a bunch of rhetorical slight of hand as you change the focus. Let's stay on target from now on, OK? Tom -- 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: Dash as default shell
On 10/2/2014 09:58, Rahul Sundaram wrote: I didn't address it because it was not really relevant either. The impetus is merely the backstory. On the contrary, the rationale for your proposed change is very relevant. The reasons for undertaking a project of this magnitude should be substantial because there is a substantial amount of work and research that must be done to ensure it is a good replacement and is implemented properly. Not only that, but it could potentially impact a lot of people in ways that have yet to be thoroughly explored. Prudence dictates an approach that isn't merely opportunistic as your original statements suggested. There's an old saying: No job is too big for the person that doesn't have to do it. Asking others to undertake a project of this magnitude because some people were spooked by Shellshock is hardly a good reason. Tom -- 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: Dash as default shell
On 10/2/2014 09:27, Rahul Sundaram wrote: That is a mischaracterization. Bash will remain the interactive shell. This discussion is limited to switching the system shell (/bin/sh) from Bash to potentially Dash. While I appreciate your technical correction on the scope of this proposed switch, you conveniently failed to address the core argument I made which is by far the larger issue: the impetus for this switch is a knee-jerk overreaction to something that has already been patched. As I stated previously, if this same logic were followed for every piece of software for which a vulnerability was discovered then a lot of software should be dumped as well. There needs to be a better reason to switch to another piece of software other than, "Oh my God! We found a bug!" Tom -- 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: Dash as default shell
On 10/1/2014 22:39, Rahul Sundaram wrote: Since the recent Shellshock aka Bashdoor vulnerability, there have been some discussions about more distributions switching over... So there's a vulnerability found in bash, it gets patched almost immediately, and all of a sudden there's a push to abandon it altogether? If this is the proper thought process, then Heartbleed should've made everyone dump openSSL. Carried to the extreme, most software should be completely abandoned then because none of it is completely bug free. This sounds like mindless panic to me. Also, let's not forget that SELinux is baked into Fedora. Even if something does get access to the system, it is contained to a large degree. This is something I seldom hear about when this particular bug is discussed in the media. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
