Re: [RFC] plans for initscripts in F22
Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit : > > For LSB, there is an explicit promise that if a vendor does what is > specified, the package will be possible to install and will run > correctly. We do, of course, have the option to repudiate LSB and > explicitly say we don't care for future releases. So shouldn't redhat-lsb or some subpackage be the one that pull that part ? As I do not think that Fedora is out of the box LSB compliant, I do not think that's a strong reason ( even if "not breaking outside stuff" could be something that matter ). In fact, if we were serious at supporting it, we would have it as a release criteria. I think we don't, and I think no one was interested into having it ( or rather, interested enough to do the job ). Also, regarding LSB compliance, do we want to consider all products to be LSB compliant by default, as I can perfectly see the cloud product being more interested into cleaning than lsb ? > And it's not only commercial software; private projects that make no > sense to publish (such as a company's web site) are equally affected > such changes. Simply spoken, if we care only about package in Fedora, > we are building an appliance; if we want to build an operating system, > we do need to cater for software not included directly in the repo. Then how can we signal to people that they need to update those packages ? Because we can as well say "we are gonna support that forever", but that will result into bitrot if no one really test. -- Michael Scherer -- 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] plans for initscripts in F22
Am 26.04.2014 11:24, schrieb Michael Scherer: > Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit : >> And it's not only commercial software; private projects that make no >> sense to publish (such as a company's web site) are equally affected >> such changes. Simply spoken, if we care only about package in Fedora, >> we are building an appliance; if we want to build an operating system, >> we do need to cater for software not included directly in the repo. > > Then how can we signal to people that they need to update those > packages ? the problem is that people don't want to rewrite/update perfectly working things which are broken by intention moving config files around or replace them with a completly new syntax because the rewrite of whatever piece of software did not have backwards compatibility in mind is annoying for a lot of reasons - besides some voices saying "i don't care about anything which is not part of the distribution" * it breaks working setups * it renders howtos invalid * it throws away knowledge of people that learned how to do things it's already a big problem that if you try to achieve something you can't rely on any information you find in the internet if it's not brand new written with stable interfaces and configurations you can build on top of several articles and howtos pieces together for your solution by permenantly changing interfaces (CLI params are user-interfaces) that ends in 3 of 5 pieces are still working that way but the big picture fails by the 2 no longer behave that way parts and if you try something you did never before and not sure what is the best way at all it get's really hard i have built a lot of automation for systems administration that way over years where machines for different services are configuring themself by meta-informations coming from simple actions like "fill out one webform for a new domain" * register that domain via EPP * add the domain to the DNS servers * add the domain on the primary webserver and create a document root * create a mysql database * install our self written cms with a default setup and configure it for that database * add the domain including whois-infos to the billing database * add the email addresses to dbmail * add the domain * add the domain to the spamfirewall-appliance * add a SPF record to 4 nameservers with LAN/WAN DNS views * configure autoconfig/autodiscover aliases on apache and add the DNS records * add the domain on the Trafficserver machine (ATS and local dnsmasq) to later decide with a single DNS change if it needs load-balancing that can be one big task and several cronjobs on several machines are doing that one time, but all these jobs also working alone for cases where no mail addresses where ordered and 6 months later are needed - well, enter the mail-addresses in a textfield, the above tasks which are relevant are happening and the result is a list with username:generated-password so all that pieces are running standalone but also heavily combined if one of them falls because a change in the distribution the damage depends on which one, can it be automatically detected and following actions stopped while raise alarm, how can you test the cases which may lead to failing one of the pieces, how do you manage to test the behvior if the underlying operating system make abusive changes and last but not least even if you know which things are changing in case of dist-upgrades how do you plan these changes in case we are talking about a lot of machines acting together since a distupgrade on a ton of machines is a non-atmoic process and you hardly can stop the whole infrastruture until now i managed to surivive dist-upgrades from Fedora 9 to 19 in such a environment inluding make space for GRUB2 with test-machines and dd-dumps of the (luckily) /boot-disks instead partitions distributed but that don't mean you ask yourself not if the current change is really worth the impact if you managed to get your result after that and the next Fedora version breaks it again because someone says "ah that was a terrible way to do things, we no longer support that please change that" and that happens too often it raises the question "is Fedora something you can build things on top of which is the job of an operating system or is Fedora something narcissistic you should avoid if you don't want to rebuild your work every few years or sometimes months" don't get me wrong, i am a perfectionist too re-factoring and optimizing my code up to comments and seek even wrong code-indenting of single lines while trying to get rid of code better never written that way - but doing that you need to draw a line where you better should stop because the damage defeats the positive effect and if you are not drawing that line you end in a loop of breaking, replacing, adopting, breaking, replacing, adopti
Re: default local DNS failover solution needed, nscd?
On Fri, Apr 25, 2014 at 6:51 PM, Chuck Anderson wrote: > I'm starting a new thread to clarify and emphasize the problem I'm > actually trying to solve. Here is the problem restated as I posted it > to the dns-operations list: > > - > Is it really expected that the first DNS server listed in > /etc/resolv.conf should never go down? Operationally speaking, who > can actually rely on listing multiple nameservers in /etc/resolv.conf > and using libc's failover mechanism in any kind of production server? > Because the failover behavior in libc is atrocious--each new or > existing process has to re-do the failover after timing out, and even > long-running processes have to call res_init() to re-read resolv.conf. > It seems that the only sensible way to run a datacenter (or a network > full of Linux workstations for that matter) is to either: > > 1. Make sure the first nameserver listed in resolv.conf never goes >down by using Anycast DNS or some other failover mechanism like >VRRP or CARP on the DNS server side. Run it through any decent load balancer, with "priority" settings to keep them in a specific order. One can host multiple IP addresses this way on the load balancer, on different VLAN's, just in case of routing issues. > 2. Use a local DNS daemon on every server with forwarders configured >to the network's nameservers, and fix resolv.conf to 127.0.0.1. > - > > (I've since learned that nscd can be a third option) > > On Fri, Apr 25, 2014 at 07:19:17PM +0200, Petr Spacek wrote: >> On 25.4.2014 18:19, Simo Sorce wrote: >> >On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote: >> >>On Thu, 10 Apr 2014 10:41:54 -0400 >> >>Chuck Anderson wrote: >> >> >> >>>[...] We need an independent, >> >>>system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to >> >>>solve this fundamental design problem with how name resolution works >> >>>on a Linux system. Windows has had a default system-wide DNS cache >> >>>for over a decade. It is about time that Linux catches up. >> >> >> >>I observe you pointedly ignore the existence of nscd (which does not >> >>require any changes to resolv.conf). Why is that? > > Ignorance about nscd on my part. Please tell me more. What are the > honest pros/cons to using nscd? Are there still big enough problems > with nscd to warrant its poor reputation? > >> >nscd is ... bad > > I've since learned more about nscd. Apparently its reputation may be > undeserved, at least the newer versions in glibc. I have no direct > experience, but I finally found a good thread about fixing the stub > resolver that addresses people's unwillingness to use nscd as well as > some other things that could be done, such as a patch apparently > carried by Debian and Ubuntu that improves detection of changes to > resolv.conf: > > https://sourceware.org/ml/libc-alpha/2012-12/msg00416.html > >> Main goal is to have local DNSSEC-validating resolver. > > I, as the OP, did not intend that as the goal, although I have no > problem with that as a different goal. My intent was to fix the > atrocious failover behavior of the glibc resolver. I also don't mind > using a caching resolver BUT there should be a better stub resolver > that can be widely deployed in a default configuration that doesn't > require a local caching resolver to paper over its deficiencies. > Maybe nscd (and some of the other ideas in the link I posted) are part > of the solution. > > Basically, we aren't going to win the war by suggesting that everyone > should run a DNSSEC-validating resolver everywhere. But maybe we can > get widespread consensus for having a lightweight daemon that just > does failover correctly and nothing else fancy so that people won't > mind it running by default on Server, Workstation, Cloud, etc. Maybe > nscd can be that daemon, or maybe something else needs to be written. > > Whatever the solution to DNS failover, we should be sure it works > correctly in combination with/doesn't get in the way of full > caching/DNSSEC-validating resolvers, both local and remote, whether > they are installed/enabled by default in various Fedora products or > not. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
