Re: F21 System Wide Change: Workstation: Disable firewall
On 15.04.2014 11:40, Reindl Harald wrote: it is not a point of *what i can do and do* it is a point what the ordinary 08/15 user does which assumes to have a by default secure system after install Fedora is not for ordinary users. Fedora is for geeks and developers that like to experiment with a new software. Ordinary users use Windows and iOS (sometimes RHEL). Averedge Fedora user should be able to enable/disable firewall and justify if he needs such thing. So this decision about disabling fw be default is complitelly not important from security point of view. You can alway drop some iptables rules to your rc.local script. Mateusz Marzantowicz -- 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: Fedora.next: I would like working configurations
On 27.01.2014 22:01, Robert M. Albrecht wrote: Hi, dhcpd is just an (maybe bad) example. It is good example. See dhcp configuration in your home router - it requires some attention. Then try some Cisco or HP router and its dhcp configuration. This smart devices are not so smart to work for everybody out of the box. This is also true for Linux versions of this daemon. But even dhcpd needs a lot of work. I need to configure ranges, options (which could like gateqway and dns partly automagically gathered from the exsting network configuration), ... binding dhcpd to bind to enable dynamic updates, ... and double this stuff for IPv4 and IPv6. You can disable IPv6 if you don't need it. How can any software possibly know your network address before you enter it during installation? How would dhcpd daemon know IP ranges you want to lease to hosts on your network? Read your mind? I used this only as an example to show that nearly all daemons are not ready-to-run. cups and apache are not sharing user-groups with samba and nagios, ... Because I don't want that functionality. If it's what you need, please learn how to do it and just do it. No one is preventing you from doing that. Integration of services is often possible, but not done when doing a fresh Fedora installation. Because different people need to integrate different things. But it's not entirely true what you said, take a look at FreeIPA, perfect example of integrated service. What I would like is more integration to produce a working server. If I create a user group, it should be known in all installed services. It is... or you're doing something wrong. What kind of user accounts are not recognized by what software? This might not be restricted to servers: all audio-components are there to do some professional work: jack, pulseuaudio, alsa, Audacity, plugins, ... but I have to fiddle them together myself. What? Mateusz Marzantowicz -- 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: Fedora.next: I would like working configurations
On 27.01.2014 22:05, Robert M. Albrecht wrote: Hi, if the server sits in a RFC1918 network (192.168.1.0/16), has a static IP and a configured gateway and DNS, it might be reasonable to assume, the dhcpd should operate in this range and set the options for DNS and gateway accordingly. Imagine Linux box with three NICs, each on different network. To simplify things let there be NAT and and two public addresses (some kind of failover.) What interface should dhcp server operate on? What address pools should be used there? It can't be easily deduced without admin intervention. Too much use cases. Mateusz Marzantowicz -- 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: NetworkManager Bridges in Fedora
On 16.01.2014 21:38, Dan Williams wrote: On Thu, 2014-01-16 at 14:53 -0500, Steve Dickson wrote: On 16/01/14 14:39, Steve Dickson wrote: On 16/01/14 14:09, Dan Williams wrote: Also, if wouldn't mind passing along the systemd journal output for NetworkManager, that might help us figure out what's going on: journalctl -b _SYSTEMD_UNIT=NetworkManager.service The log is at: http://steved.fedorapeople.org/tmp/nm.log I bet ya the hang has something to do with these messages: info (bridge0): IPv4 config waiting until carrier is on info (bridge0): IPv6 config waiting until carrier is on info Activation (bridge0) Stage 3 of 5 (IP Configure Start) complete. What carrier is it waiting on? em1 is already up and running... So what's happening here is that you two configurations/connections/profiles that apply to em1: ifcfg-em1, and ifcfg-bridge0_slave_1. And ifcfg-em1 is getting chosen, but it's not a bridge slave configuration, it's just a normal DHCP configuration. Since ifcfg-em1 is not a bridge slave configuration, it never gets added to the bridge master, and the bridge master sits around waiting for slaves because it has no carrier which is required for DHCP. Persistent fix #1: edit ifcfg-em1 and change ONBOOT=yes to ONBOOT=no nmcli con reload then do Runtime fix below Persistent fix #2: rm /etc/sysconfig/network-scripts/ifcfg-em1 nmcli con reload then do Runtime fix below (or use nm-connection-editor to delete 'em1' or uncheck Connect automatically from the General tab.) Runtime fix (not persistent): nmcli dev disconnect em1 nmcli con up bridge0 slave 1 -- (In old network service speak, the runtime operation would be: ifdown em1 ifup bridge0_slave_1 and we still expect these commands to work even when NetworkManager is managing the interface.) -- Dan I'm doing this differently and now I don't know which method is recommended by RH/Fedora gurus. I don't use /etc/sysconfig/network-scripts at all but placed all network related configuration in /etc/NetworkManager/system-connections/ directory. Now I'm not sure if I should convert back to using /etc/sysconfig or what? Not to mention that GUI tool is c... and I had to use text editor to configure network bridging. Mateusz Marzantowicz -- 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: idea for installation - web
On 15.12.2013 09:19, חץ בן חמו wrote: IMHO, at the moment, the current installation process is quite .. confusing. text mode installation has gone, No it hasn't. Boot with parameter 'text'. and so VNC method (last I checked), No it hasn't. Boot with parameter 'vnc'. Could someone please add them to the boot menu please? I've been searching for ages for those options and I didn't see it mentioned anywhere. http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/vncwhitepaperadded.html Mateusz Marzantowicz -- 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: FTBFS if -Werror=format-security flag is used
On 10.12.2013 00:01, Les Howell wrote:
On Mon, 2013-12-09 at 15:59 -0700, Rich Megginson wrote:
On 12/09/2013 03:33 PM, Przemek Klosowski wrote:
On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
printf(string) is legitimate C, forcing printf(%s, string) is
just silly.
My apologies for being repetitive, but the original point is that
printf(string) is insecure unless you can guarantee that you control
'string' now and forever. Also, %s is the format for printing
strings, so I just can't agree that coding printf(%s, string) is
silly.
Silly is not the right word. printf(%s, string) is inefficient. In
this case, it would be better to use puts/fputs.
unless something has changed recently fputs and puts just like gets and
fgets have been deprecated and are discouraged due to potential security
issues.
Something must have changed. GCC uses puts instead of printf in some
cases. Please, see below:
$ cat p.c
#include stdio.h
int main()
{
printf(Hello world!\n);
return 0;
}
$ gcc -S p.c
$ cat p.s
.file p.c
.section.rodata
.LC0:
.string Hello world!
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$.LC0, %edi
callputs
movl$0, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident GCC: (GNU) 4.8.2 20131017 (Red Hat 4.8.2-1)
.section.note.GNU-stack,,@progbits
Mateusz Marzantowicz
--
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: Can we have better ssh fingerprint collision messages?
On 13.11.2013 22:19, Jeffrey Bastian wrote:
On Wed, Nov 13, 2013 at 01:29:34PM -0500, Przemek Klosowski wrote:
On 11/12/2013 07:47 AM, Miroslav Suchý wrote:
2) if you know that some machines change fingerprint and you *trust it*
you
can do:
~/.ssh/config:
Host 192.168.1.1
UserKnownHostsFile /dev/null
It always bugged me that the choice was to either disable or manually edit an
obscure file, so I was happy to find that you can delete stale entries from
commandline:
ssh-keygen -R hostname
I work on some lab systems that get kickstarted frequently and thus
change ssh keys quite often, so I wrote the script below to update my
known_hosts file with the new key.
Note that I use the format hostname,ip-address so that I don't get two
entries in my known_hosts file (which causes its own set of problems if the
system gets a new IP address due to DHCP changes).
~~~
#!/bin/sh
KNOWN_HOSTS=~/.ssh/known_hosts
NEW_HOST=$1
IP_ADDR=$(host $NEW_HOST | awk '/has address/{print $NF}')
if ! grep -q $NEW_HOST $KNOWN_HOSTS ; then
echo Could not find $NEW_HOST in $KNOWN_HOSTS
exit
fi
ssh-keygen -R $NEW_HOST
[ -n $IP_ADDR ] NEW_HOST=$NEW_HOST,$IP_ADDR
ssh-keyscan $NEW_HOST $KNOWN_HOSTS
~~~
Jeff
You can also manage host keys and fingerprints using FreeIPA.
known_hosts file is managed for all machines added to directory.
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/host-keys.html
Mateusz Marzantowicz
--
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: Draft Product Description for Fedora Workstation
On 03.11.2013 20:25, Rahul Sundaram wrote: Hi On Sun, Nov 3, 2013 at 1:57 PM, Mateusz Marzantowicz Do I understand correctly that first problem could be solved by stabilizing APIs used in various Linux projects? Because developers don't want stabilizationt they invent workarounds like sandboxes? Wouldn't it be easier to have stable API for some period of time? You mean ABI and not API but your question is answered already in the comments at http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/ Ideally we *do* want most app to share the system libs, but only those, not the non-core libraries of varying ABI stability and quality. This way we can work hard to make the core 100% ABI backwards http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 04.11.2013 11:13, drago01 wrote: On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy frankl...@gmail.com wrote: On Mon, 4 Nov 2013 11:03:45 +0100 drago01 drag...@gmail.com wrote: Apps shipping from upstream direcly does not have to be closed source. Firefox for instance could use that, or libreoffice, or eclipse. If a user needs a newer version (or nightly build) without having upstream worry about the specific distribution. I haven't read every post in the thread. Confused are use asking users to build nightlies (or other ver) from src? No we are just creating a way to allow those upstreams to create those builds for users (as Florian said without having them to update to rawhide or wait six months for the next release). The average user don't use nightly builds and should not be interested in such experimental software. Only developer could benefit from gaining access to latest builds in order to participate in project development. Users would be more than happy to use the same software version as long as they can. I meet users that ask me the same boring question: why do we need to upgrade to the new version and why do we need to learn using this software again and again and ? They understand the need of fixing bugs and happily welcome some minor improvements but are not interested in applications as such. Software is like hammer - it's a tool. People don't care about hammers unless they can build what they want. People don't want to install software - they want to use it! Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 04.11.2013 12:18, Florian Müllner wrote: On Mon, Nov 4, 2013 at 11:37 AM, Nicolas Mailhot nicolas.mail...@laposte.net mailto:nicolas.mail...@laposte.net wrote: GNOME decided to break it all the time (can't even get extensions work from one gnome-shell version to the next one and no gracefully disabling is still functional breakage). So what do you suggest? We can either (1) restrict the functionality extension can provide (e.g. add an icon with a menu to the top bar - of course that'd mean no alternate-tab, shell-shape, alternative-status-menu etc.) (2) cease development of gnome-shell (1) will cause an understandable outrage as it would mean the end for a large percentage of extensions, and (2) is not an option. Just see how others does this. Linux Kernel is one example, Django is another. This two projects from very different corners are able to provide stable API/ABI for some longer time period. I really appreciate your (GNOME devels) hard work but sometimes it is better to stop and think for a moment about where we're going, than writing as much code as one can handle and the remove it in next release. Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 04.11.2013 19:25, Florian Müllner wrote: On Mon, Nov 4, 2013 at 6:57 PM, Kevin Kofler kevin.kof...@chello.at wrote: Florian Müllner wrote: ... or users having to update their *entire* system to unstable/experimental versions if they want to try the lastest Firefox/Libreoffice/Eclipse Then either upstream or the Fedora packager should just build the unstable version against the stable Fedora in a PPA. See e.g. kde-unstable for KDE betas. This does not work if the unstable package depends on an unstable version of a dependency shared with the stable system, e.g. if kate depends on an experimental Qt version, your current choice is to not test it or have all of KDE use an unstable version of Qt. This sounds like a good use case for virtualization. You test your unstable apps in your test environment with other unstable software and don't need to destroy your workstation. If I were using Kate (to follow your example) for my daily work I wouldn't risk making it unusable on my system. Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 04.11.2013 20:15, Stephen Gallagher wrote: On 11/04/2013 02:01 PM, Reindl Harald wrote: Am 04.11.2013 19:32, schrieb Stephen Gallagher: e, we probably would end up reducing the number of applications available in the standard yum repos. I'm not as convinced as you are that this is a bad thing. Right now, there's really no distinction between what constitutes the operating system and what constitutes the application ecosystem. *that* is the definition of a *distribution* I don't think so. I think that's the definition of a *library*. Let's say you want to build a boat. So you go to the library and you dig through the thousands of books there until you find some on carpentry, buoyancy principals and boat-building. You probably *can* build a boat from this information, but that's not the purpose of every book in the library. A distribution would be more like going to an engineering college and studying nautical engineering. Focused and dedicated to the task, you'll probably produce a better boat in the end. I don't get your example but I agree with Reindl Harald - Linux Distribution is a set of software that works as one coherent environment. Let it be 10, 100 or 1000 different packages but they're chosen, compiled and adjusted to work together. This is the strength of Linux as operating system. Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 04.11.2013 21:03, drago01 wrote: On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 04.11.2013 20:56, schrieb drago01: On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald h.rei...@thelounge.net wrote: that's all true but you can be pretty sure if a app-store with bundeled applications exists *nobody* would package and maintain them as RPM - everybody would point with his finger to the app No because RPM packages apps *do* have benifits .. otherwise we wouldn't have this discussion. if it goes in that direction, and it starts faster than anybody likes you do a dramatical harm to the userbase which likes the consistent package managment and *really used* conecpt of shared libraries Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and* rpm packaged apps at the same time. the most imporant word in your answer is *CAN* but you will not, nobody will package whatever application as RPM if he is fine with the app-store, so you *could* have both but i doubt at the end of the day it will happen And I disagree ... but there is a way to find out ... lets try and see ;) After all there are other Linux distributions, so let's see if Fedora survives this experiment. ;-) Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 03.11.2013 15:10, Kevin Kofler wrote: We DON'T want Apple-like apps! This is exactly what is going to happen with Sandboxed applications for GNOME (GNOME, Fedora, Linux - whatever you want). Sadly this idea is promoted and developed by some RH employees. Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 03.11.2013 19:15, Rahul Sundaram wrote: Hi On Sun, Nov 3, 2013 at 12:44 PM, Reindl Harald wrote:if success is * to have no centralized updates * have most applicatons and tools never updated at all * have the weakest security model even compared to Windows these days * have a standards violating OS * have a unstable OS and all above points are taken from Apple workstations surrounding me then indeed i prefer to keep that unsuccesfull You assume that sandboxed apps means we get all the negatives and none of the benefits. That is unwarranted. We can adopt the good parts and improve upon it based on the lessons learned from adoption of app stores across multiple operating systems and mobile devices that serve a much broader audience. We should be willing to let competent contributors who are interested in doing that try it and provide useful feedback when necessary instead of dismissing it on bad assumptions as a knee jerk reaction on our experiences with proprietary software or bad conduct of particular companies. For a server oriented user those sandboxed apps might not be relevant and they might be contend to get their apps from the distribution but sandboxes apps are a fine tradeoff for others who prefer to be not locked in to a narrow channel for all their needs. Lets not pretend that commercial sucess doesn't matter as well. Fedora might be free for you but it is certainly not free for say Red Hat and their continued participation is dependent on Fedora being more successful as well. I for one, consider this a good thing. Just one question: what exact problem are trying to resolve sandboxed applications? Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 03.11.2013 19:40, drago01 wrote: On Sun, Nov 3, 2013 at 7:33 PM, Mateusz Marzantowicz mmarzantow...@osdf.com.pl wrote: On 03.11.2013 19:15, Rahul Sundaram wrote: Hi On Sun, Nov 3, 2013 at 12:44 PM, Reindl Harald wrote:if success is * to have no centralized updates * have most applicatons and tools never updated at all * have the weakest security model even compared to Windows these days * have a standards violating OS * have a unstable OS and all above points are taken from Apple workstations surrounding me then indeed i prefer to keep that unsuccesfull You assume that sandboxed apps means we get all the negatives and none of the benefits. That is unwarranted. We can adopt the good parts and improve upon it based on the lessons learned from adoption of app stores across multiple operating systems and mobile devices that serve a much broader audience. We should be willing to let competent contributors who are interested in doing that try it and provide useful feedback when necessary instead of dismissing it on bad assumptions as a knee jerk reaction on our experiences with proprietary software or bad conduct of particular companies. For a server oriented user those sandboxed apps might not be relevant and they might be contend to get their apps from the distribution but sandboxes apps are a fine tradeoff for others who prefer to be not locked in to a narrow channel for all their needs. Lets not pretend that commercial sucess doesn't matter as well. Fedora might be free for you but it is certainly not free for say Red Hat and their continued participation is dependent on Fedora being more successful as well. I for one, consider this a good thing. Just one question: what exact problem are trying to resolve sandboxed applications? Have a way for thrid parties to distribute applications which does not have to be tied to a specific version of fedora and just works while at the same time (as the app must not be from fedora) have some level of sandboxing to prevent it from doing what is not supposed to do. [1] It also makes it easier for user to install applications without having to affect other users. 1: http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/ Do I understand correctly that first problem could be solved by stabilizing APIs used in various Linux projects? Because developers don't want stabilizationt they invent workarounds like sandboxes? Wouldn't it be easier to have stable API for some period of time? There are some large Opens Source projects that don't change everything in API with each new release. Maybe Fedora/GNOME could do the same? I don't see how maintaining local instance of each application is going to make things easier. It was done this way in MS DOS. Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 01.11.2013 19:15, Josh Boyer wrote: On Fri, Nov 1, 2013 at 12:35 PM, Mateusz Marzantowicz mmarzantow...@osdf.com.pl wrote: On 01.11.2013 15:24, Christian Fredrik Kalager Schaller wrote: Hi everyone, Attached is the draft PRD for the Workstation working group. The proposal tries to be relatively high level and focus on goals and principles, but I have included some concrete examples at times to try to provide some clarity on how the goals and principles could play out in practice. I hope the community at large will take the time to read through it and provide feedback so that when the working group meet next we can use that feedback to start tuning in on the final form of the PRD. Also in the name of openness, before I sent this here, I showed the PRD draft to key stakeholders and decision makers inside Red Hat, to ensure that we have the necessary support for these plans to get the kind of engineering resources allocated from Red Hat we will need to pull this off. It looks like it is designed only for developers by developers. What about graphic designers, musicians, document writers, etc.? They all are not mentioned as target audience. Per this document, those would fall into the Other users section. Is it wise to put 90% of use cases in other users section? Maybe I don't understand intention of this document but judging based on it's content Workstation product only (mostly) embraces software development. The software for much of those use cases is available in the wider Fedora repository, so one could install them if needed. I'm aware that this Fedora devel process revolution shouldn't result in mass package removal but I'm really worried that goals are set so narrowly and this might result in functionality degradation. Now we have all packages for different use cases but no progress is stagnation and finally death. Mateusz Marzantowicz -- 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: Draft Product Description for Fedora Workstation
On 01.11.2013 15:24, Christian Fredrik Kalager Schaller wrote: Hi everyone, Attached is the draft PRD for the Workstation working group. The proposal tries to be relatively high level and focus on goals and principles, but I have included some concrete examples at times to try to provide some clarity on how the goals and principles could play out in practice. I hope the community at large will take the time to read through it and provide feedback so that when the working group meet next we can use that feedback to start tuning in on the final form of the PRD. Also in the name of openness, before I sent this here, I showed the PRD draft to key stakeholders and decision makers inside Red Hat, to ensure that we have the necessary support for these plans to get the kind of engineering resources allocated from Red Hat we will need to pull this off. It looks like it is designed only for developers by developers. What about graphic designers, musicians, document writers, etc.? They all are not mentioned as target audience. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
User/Group ID assignment
Are there any guidelines regarding user and group id number assignment on Fedora? I'd like to add user/group for daemon, related to installed package, in order to avoid running it as root. What numbers are already reserved and where can I find up to date table with that numbers? I see in my /etc/passwd that regular user accounts are assigned numbers starting from 1000 (was it 500 on older systems?), 0-200 and 201-999 are used by system accounts and packages like httpd, wireshark, etc. I've found this [1] site but it looks outdated and incomplete because it references FC5 and discussions pointed there are from 2005. [1] https://fedoraproject.org/wiki/PackageUserCreation Mateusz Marzantowicz -- 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: User/Group ID assignment
On 22.10.2013 13:32, Mikolaj Izdebski wrote: On 10/22/2013 01:25 PM, Mateusz Marzantowicz wrote: Are there any guidelines regarding user and group id number assignment on Fedora? I'd like to add user/group for daemon, related to installed package, in order to avoid running it as root. What numbers are already reserved and where can I find up to date table with that numbers? I see in my /etc/passwd that regular user accounts are assigned numbers starting from 1000 (was it 500 on older systems?), 0-200 and 201-999 are used by system accounts and packages like httpd, wireshark, etc. UIDs = 1000 are reserved for users, 1000 for system. System UIDs can be allocated statically or dynamically. Static UID allocation can be found in [1], to add a new UID you need to file a RFE against setup package. Dynamic UID allocation is done from 999 downwards. You don't need to reserve anything, but UIDs can very between systems. [1] /usr/share/doc/setup/uidgid Thanks, that is the list I was looking for. Is there any mechanism to assign first available id from less than 999 pool or should I manually find the right number? I understand that dynamic assignment is done by package manager, but I don't want to rebuild and reinstall rpm package for now on. Mateusz Marzantowicz -- 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: Fedora Working Groups: Call for Self-Nominations
On 11.09.2013 21:31, Matthew Miller wrote: Introduction Based on discussions at and around Flock, the Fedora Project Board has approved a proposal for a big change in the way we put Fedora together. Rather than presenting one Fedora with multiple slightly-different install options, future Fedora will be designed, developed, and promoted as three separate products built around a common core. To take that idea from talk to reality, we're making a corresponding change to Fedora leadership. Each product will be guided by a Working Group, which will function as an independent subcommittee of FESCo, (the Fedora Engineering Steering Committee). FESCo will resolve issues which impact multiple working groups, and the Fedora Board will continue to set overall strategic direction, but the working groups will be largely autonomous within their own areas. The Groups -- We are creating a group for each of the three initial products the Board has approved: * Fedora Workstation * Fedora Server * Fedora Cloud What about Fedora Embedded? Do you plan to drop ARM support on Fedora? I can't match small credit card size devices with either Workstation, Server or Cloud group. Is this group list fixed or could be extended and on what basis? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
firewalld rewrite in C - outdated wiki page
I've found this page [1] with following content: - Targeted release: Fedora 16 - Last updated: 2011-06-27 - Percentage of completion: 10% Is it OK to have feature which is 10% complete and is still targeted at eol release? Mateusz Marzantowicz [1] https://fedoraproject.org/wiki/Features/firewalld-rewrite -- 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: hidden GRUB menu - Re: Suspension problem last 2 days
On 22.09.2013 18:34, Reindl Harald wrote: Am 22.09.2013 18:30, schrieb Jan Kratochvil: On Sun, 22 Sep 2013 18:24:45 +0200, Reindl Harald wrote: Am 22.09.2013 18:13, schrieb Jan Kratochvil: My grandfather still believes those are multiple _different_ Fedora installations, each having different games/files. As he has also CentOS menu item there having multiple Fedora items is just too much for him. explain it to him I have tried many times for many years but he still insists on it. * because i saw the menu from the very first beginning * because doing nothing the next boot-step after that menu failed * so what did i: look waht happens if i chosse something other from the menu There is never a perfect solution, everything has its pros and cons. yes and the chance having a unbootable system has more cons So it could wait for 5 secs, just displaying a message Hit SHIFT to display a boot menu.. That hopefully should not confuse users while it would still help you to solve your problem place a descriptive text *above* the menu and display it as default would be the best one, but i guess pragmatic solutions edcuating users are not the ones developers these days perfer wondering from which tress in 10 years the advanced users will fall if all advanced options are more and more hidden beause the could confuse somebody Oh, come on. Not all advanced options need to be presented to anybody at any time. You, as advanced user, don't need all of this advanced features every time you use your system. Going back to boot menu - how many of your reboots are not successful so you need to choose different kernel or specify different options? Regular Linux user expect to boot system successfully every time and if it's impossible it means distro devels screwed up releasing untested package. It's good to have all that options around but presenting them to user just in case he might want to do something more advanced once a year is simply wrong. To educate new Linux/Fedora users, it's better to write some good documentation or produce high quality podcast than showing them all that meaningless options. Mateusz Marzantowicz -- 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: About F19 Firewall
On 20.09.2013 22:23, Björn Persson wrote: Anyone can broadcast an SSID. How does FirewallD authenticate the network connection? FirewallD is not responsible for such authentication/AP validation. Firewall as such is not meant to assure you're connecting to where you want. Mateusz Marzantowicz -- 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: About F19 Firewall
On 16.09.2013 07:55, P J P wrote: Hello Tomasz, - Original Message - From: Tomasz Torcz to...@pipebreaker.pl Subject: Re: About F19 Firewall You seem to have missed this Fedora *18* feature: https://fedoraproject.org/wiki/Features/firewalld-default firewall-cmd is supposed to isolate user from all this chains. Yep, true. My contention is not with the tool, but with the complexity it adds to the rules with all the zones and sub-chains and user-space tooling around it. - https://fedoraproject.org/wiki/FirewallD As I suspected a zone describes a network one is currently connected in. It could be home, work, public(wifi at a coffee shop) etc. That means one must keep shifting from home to work to home and in between public for coffee-shop. I wonder who's going to do that every day. If they don't they either don't get to use the network services or are not protected enough. Ex. one always has the 'public' zone rules activated. Wireless networks have unique names and are represented as different connections on NetworkManager (network connection != interface). For network named MyHomeNet one can associate Home zone in NetworkManager and for network CoffeShowHotSpot one assigns Public zone. You don't have to change anything once it's assigned. Public zone is as I understand strictest but usable one (block zone does not allow traffic). This can also be applied to wired connection. The reason for all that chains is to allow adding/removing rules without need to reload all of them. It's written somewhere on FirewallD's site. I agree they're harder to understand and maintain manually by sysadmin but they're not designed for such usage. Mateusz Marzantowicz -- 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: About F19 Firewall
On 17.09.2013 12:31, Nicolas Mailhot wrote: Le Mar 17 septembre 2013 11:33, Björn Persson a écrit : Mateusz Marzantowicz wrote: Wireless networks have unique names and are represented as different connections on NetworkManager (network connection != interface). For network named MyHomeNet one can associate Home zone in NetworkManager and for network CoffeShowHotSpot one assigns Public zone. You don't have to change anything once it's assigned. So when some innocent-looking guy is sitting in the café with a smartphone posing as an access point with an SSID of MyHomeNet, will your Fedora laptop connect to it, switch to the Home zone, and assume that everybody on that network is friendly? Does not matter if the firewall rules become complex enough no one will ever audit them and they become the malware-ridden black-boxes common in windows environments. (though systemd and gnome3 are taking the 'pile of overengineered rules no one checks' route fast) Maybe, true but I doubt that simpler set of rules, that never get audited, written by inexperienced users are more secure than complex rules in FirewallD which at last had chance to be checked. BTW, there is not that much magic in rules applied by FirewallD and other firewall solutions for Linux have similar level of rule complexity (ufw, shorewall, etc.) Mateusz Marzantowicz -- 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: About F19 Firewall
On 17.09.2013 15:02, Kevin Kofler wrote: P J P wrote: Hmmn, it should have been a package for user to install at will, rather than a replacement of an understandable firewall. +1, the fact that this is opt-out rather than opt-in (even for upgrades from Fedora ≤ 17 – I had to go out of my way to disable that feature immediately after upgrading to F18) really sucks, also considering that it is written in Python. (The core system should be free of interpreted languages. Lennart is going out of his way to replace shell stuff by fast native code in systemd, why sabotage that effort by shoving a Python firewall down our throats?) It's written in Python and so what? Interpreted languages like Perl and Bash are widely used in Linux world to implement many tools. I don't buy argumentation that if something is not implemented in C it sucks. Mateusz Marzantowicz -- 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: Firewall blocking desktop features
On 11.09.2013 17:24, Daniel J Walsh wrote: On 09/11/2013 09:18 AM, Reindl Harald wrote: Am 11.09.2013 15:05, schrieb Daniel J Walsh: On 09/11/2013 08:56 AM, Alec Leamas wrote: Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. very very bad idea! In a perfect world I agree. Sadly we need something better then we currently have. Microsoft tried the tell the user about every port connection and this does not work, because users have no idea. I am trying to find some happy ground between, telling everyone you have to disable firewall to do cool stuff on the desktop. If a random prompt came up that says Do you want to share FOOBAR on the internet? A non educated user could have a chance of saying No? If it kept on happening, he might even ask someone why his machine is acting weird. But if he just said setup sharing of FOOBAR he would understand this and make the correct decision. We have a tool that could be used for labeling the processes that are asking, SELinux, but we would have to eliminate the unconfined_t domain :^(. that means if the is no samba running and whatever harmful process needs to open incoming connections it would trigger the promt for samba these is the way to go only if you want to design a security nightmare The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless Interesting discussion but several things doesn't fit together for me: 1. It's firewall's job to manage and keep track of opened ports and established connection so it also should be the piece of software that asks user if he wants to allow network traffic or not. 2. Why you say there is no way for firewall to know which app is requesting specific port to be opened? There is a process name and path and it could be identified. It's also easy to maintain database of most commonly used binaries and ports that they'd like to open/close. If you don't trust binaries on your system it means it's already been compromised and firewall is then useless. 3. If you allow each app to ask for permission to open some port, it'll certainly be done in thousand different ways and lack of consistency isn't going to help users. Mateusz Marzantowicz -- 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: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
On 22.07.2013 15:38, Matthew Miller wrote: I've been involved to some small degree with Fedora since the beginning. This is a project and a Linux distribution which I love, and which I know everyone reading this also cares about deeply. We don't want to break what is successful and works. But... --- * We need to be more than that * Not widely used by RHEL users Because it lacks reliability of RHEL. This needs to be enhanced. * Not so great for building on... Because it lacks high quality developer's documentation for all this new pieces of software that it contains not to mention that this pieces are swapped in and out too often. * Including Red Hat's own stuff * We're not seen as relevant... * Let alone exciting Whenever I go to a tech meetup or talk to someone from a new startup company, their developers are inevitably using a different (usually proprietary) desktop OS, plus a non-Fedora distribution on their code. We're being left behind and left out. It doesn't matter how theoretically great we are if we end up with no users. The Idea --- Focus core distro as platform, include layers of modular enabling technologies, and provide room for special interest groups to create solutions within the Fedora circle. I think it's good approach for OS development to stay focused on rock solid core that is reliable and doesn't break. Then all other rings mentioned below in your proposal are easier to manage and could sometimes break in some way. But core does never break form F(n) to F(n+1). Sadly I encounter lot of regressions in Fedora that I don't in other distros. If something works in one version of F it should not break in the next one. So there we have it. Comments and discussion, please! I think it's one of the most reasonable proposals since decade that occurred to Fedora. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Developers guide for Fedora Linux
Hello, I'm writing some apps for Linux, from time to time. I'd like to know if there is any comprehensive developers guide for Fedora. I see lot of changes are made to Fedora (and maybe soon RHEL) like no syslog by default, systemd machinery, etc. How can one use all that new exciting features and APIs in their own programs? Please, enlighten me with some (preferably official) resources e.g. about logging using journald in C/C++ or Python/Perl. Thanks in advance, Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard link to root-owned file now fails (since Fedora 19)
On 15.07.2013 19:35, Chris Adams wrote: Once upon a time, Richard W.M. Jones rjo...@redhat.com said: Why? http://docs.fedoraproject.org/en-US/Fedora/19/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm263811933136 There is a BUG it the documentation or in my Fedora 19 system! This lines mentioned in documentation: fs.protected_hardlinks = 1 fs.protected_symlinks = 1 are in /usr/lib/sysctl.d/50-default.conf file and not in /usr/lib/sysctl.d/00-system.conf file as it's written. Is someone checking this before releasing invalid documentation or this new feature was so hot and finally landed in different file than it was initially designed? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 15.07.2013 11:11, Miroslav Suchý wrote: On 07/15/2013 10:44 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: No Default Syslog = https://fedoraproject.org/wiki/Changes/NoDefaultSyslog Change owner(s): Lennart Poettering lennart at poettering net, Matthew Miller mattdm at fedoraproject org No longer install a traditional syslog service by default. (Specifically, remove rsyslog from the @core or @standard groups in comps.) The systemd journal will be the default logging solution. Rsyslog, Syslog-NG, and even traditional sysklogd will continue to cover use cases outside of the default. My voice may be one of thousands, but I'm saying: I want to have traditional syslog service as default and have journal from systemd as option. Maybe Fedora developers can arrange some simple survey. Only one question: do you know what is journalctl and what's it's purpose? If more than 50% of users (sysadmins, developers and others) answers yes, than maybe it's time to switch. Six out of nine of my colleagues which do server administration haven't even heard of new syslogd replacement. They just don't care right now. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 15.07.2013 23:06, Lennart Poettering wrote: It's a matter of finding the right balance: i.e. what can be text files, and where we have to win more by making it binary. I am pretty sure this is a case where we win more by sticking to binary files. It's totally fine if you disagree on this, but I'd still like to ask you to think about whether your specific usecase and specific requirements are strong enough to (continue to) be the default for Fedora, instead of just being your local configuration of Fedora. I mean, you should never forget that on your own machines everything will stay as is: you will install syslog, and things will be exactly as before. Lennart So maybe we (Fedora) should go with XML instead of binary or some dedicated RDMBS for storing system logs? I'm not against binary log format but try to understand why it's superior to text and also why something more sophisticated isn't used if we really need this additional meta data that could not be included in plain text? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 15.07.2013 23:49, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jul 15, 2013 at 11:38:14PM +0200, Mateusz Marzantowicz wrote: On 15.07.2013 23:06, Lennart Poettering wrote: It's a matter of finding the right balance: i.e. what can be text files, and where we have to win more by making it binary. I am pretty sure this is a case where we win more by sticking to binary files. It's totally fine if you disagree on this, but I'd still like to ask you to think about whether your specific usecase and specific requirements are strong enough to (continue to) be the default for Fedora, instead of just being your local configuration of Fedora. I mean, you should never forget that on your own machines everything will stay as is: you will install syslog, and things will be exactly as before. Lennart So maybe we (Fedora) should go with XML instead of binary or some dedicated RDMBS for storing system logs? I'm not against binary log format but try to understand why it's superior to text and also why something more sophisticated isn't used if we really need this additional meta data that could not be included in plain text? With a binary format you can have an index of field - offset, hash-offset, etc., and then you can jump to this offset and read data there. With text files, and with XML files, this is not possible, at least not in any sane way. Efficiency would be much worse too. OK, XML is also text so my alternative is a bit illusory but it could be represented as DOM nodes and could be indexed easier and more efficiently. Please, see how good is XML implementation in PostgreSQL. You can say, it's too much and too complicated for stupid system logs to go with fully blown RDBMS solution, but hey, really? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 16.07.2013 00:21, Eric Smith wrote: On Mon, Jul 15, 2013 at 3:53 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: And honestly I dont understand why people are ack/nack-ing this since this is FESCO decision Some of us would like to think that FESCO members might be influenced by arguments made on the development list. Maybe that's just wishful thinking. Eric I don't know how it goes with FESCO but once, there was a community voice that was heard by developers about Anaconda not hiding password characters during installation. Don't lose your faith. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
On 17.06.2013 21:26, Dan Mashal wrote: On Mon, Jun 17, 2013 at 8:25 AM, Mateusz Marzantowicz mmarzantow...@osdf.com.pl wrote: On 17.06.2013 17:18, Heiko Adams wrote: From my point of view the java-plugin is a big security hole and should be kicked from default installations ASAP. Then, why not fix it? Mateusz Marzantowicz There is no way in hell anyone here is going to fix the security holes in Java (open or closed). The only way to avoid the security holes caused by java is to not use it. Is java environment the only security flawed software distributed in Fedora by default? I don't think so. Please, correct me if I'm wrong. Does it mean Fedora should drop about 1/3 of packages because they have security bugs? What about Linux Kernel? It's also buggy. Should it be not included in Fedora? That's like telling someone not to use Firefox because it has security holes. Isn't it what *-nix geeks tell to M$ people about using IE? Don't use IE - it's buggy! Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icedtea-web installed and enabled by default in Fedora 19
On 17.06.2013 17:18, Heiko Adams wrote: From my point of view the java-plugin is a big security hole and should be kicked from default installations ASAP. Then, why not fix it? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: why do have shared libs 755 perms?
On 10.05.2013 20:57, Reindl Harald wrote: why have .so files of fedora-packages executeable permissions? they are not executeable, see below the difference of my personal builds with files from fedora packages (the original httpd and php packages have also 755) you get even segfaults by try to execute such files [harry@srv-rhsoft:~]$ /usr/lib64/httpd/modules/mod_fcgid.so Speicherzugriffsfehler [root@srv-rhsoft:~]$ ls /usr/lib64/httpd/modules/ insgesamt 6,5M -rw-r--r-- 1 root root 4,9M 2013-05-09 12:13 libphp5.so -rw-r--r-- 1 root root 10K 2013-05-10 16:06 mod_actions.so -rw-r--r-- 1 root root 10K 2013-05-10 16:06 mod_asis.so -rwxr-xr-x 1 root root 20K 2013-04-10 10:47 mod_authz_svn.so -rwxr-xr-x 1 root root 24K 2013-03-19 21:46 mod_bw.so -rw-r--r-- 1 root root 26K 2013-05-10 16:06 mod_cgi.so -rw-r--r-- 1 root root 110K 2013-05-10 16:06 mod_dav.so -rwxr-xr-x 1 root root 172K 2013-04-10 10:48 mod_dav_svn.so -rwxr-xr-x 1 root root 16K 2013-04-10 10:47 mod_dontdothat.so -rwxr-xr-x 1 root root 100K 2012-07-21 02:20 mod_fcgid.so -rwxr-xr-x 1 root root 12K 2013-03-19 21:54 mod_flvx.so -rw-r--r-- 1 root root 79K 2013-04-20 00:42 mod_h264_streaming.so -rw-r--r-- 1 root root 31K 2013-05-10 16:06 mod_info.so -rw-r--r-- 1 root root 30K 2013-05-10 16:06 mod_mime_magic.so -rw-r--r-- 1 root root 38K 2013-05-10 16:06 mod_proxy_http.so -rw-r--r-- 1 root root 107K 2013-05-10 16:06 mod_proxy.so -rw-r--r-- 1 root root 575K 2013-05-06 15:56 mod_security2.so -rw-r--r-- 1 root root 223K 2013-05-10 16:06 mod_ssl.so -rw-r--r-- 1 root root 22K 2013-05-10 16:06 mod_status.so I've found this two links with some explanation: * http://unix.stackexchange.com/questions/40587/why-are-shared-libraries-executable * http://serverfault.com/questions/173853/why-shared-libraries-on-linux-are-executable I can confirm that in Debian shared libs are not marked as executable (most of them). Maybe Fedora/RHEL make use of some form of protection which requires executable bit to be set on .so? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI?decision?
On 05.05.2013 10:54, drago01 wrote: Seriously this changes just papers over another bug we suck at keyboard layout selection ... fixing it by showing the password like that is just wrong. Thank you for writing this here! Password entry box is not a place for testing keyboard layout. Maybe this obvious remark should be forwarded to Anaconda developers? Pleas don't break unrelated things in UI just to say that some other bugs are fixed by this change. I really don't like to say it but after this whole Anaconda rewrite it's still not as usable as it was in F17 and now this plain password issue which fixes nothing occurred! Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of Offline Updates
On 05.02.2013 13:21, Reindl Harald wrote: the whole discussion abiut offline updates and why yum is not so good for dist-upgrades is from the wrong point of view, most of the problems are only existing because with each release working things are mangeled actual example: https://bugzilla.redhat.com/show_bug.cgi?id=907749 https://bugzilla.redhat.com/show_bug.cgi?id=887763#c20 bothing bad would happen if the package would not touch /etc/mtab the same for updates of services: nothing would happen on a webserver with httpd if it would not be restarted at package-update which goes wrong if you are using PHP and packages of the dep-tree are not yet all updated which fails PHP to load, without the hardcoded restart httpd would happily continue to run with the old php-package from memory so all the problems which are statet against yum-upgrades are introdouced about the last 5-6 years and were not existing before what currently happens is that more and more HARD-WIRED cross-dependencies are introduced, more and more magic ist introduced and at the end of the road we will be on the windows way you touched anything on the system and so please reboot now The real problem is that we don't distinguish updates of packages between distro versions e.g. F17 to F18 and updates inside one release. This second kind of updates should never break and need reboot (only service restart). I can agree that after upgrading from one version of Fedora to another reboot is required (e.g. to reload C standard library to newer version or to start with the new kernel). But this requires that there are only non-breaking updates of software or devels precisely know what might blow up which is hard to do. It's because of poor project management lack of stable branches of software and need of new exciting features. It was very different 15 years ago. I can remember Torvalds laughing at Windows software and its need of rebooting and inability to remove opened file. Now Linux is going the same direction. Reboot every time you upgrade text editor. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
