RE: [gentoo-dev] Adding support to metadata.xml to mark longdescriptions as outdated
I think someone in the documentation herd (Xavier Neys?) has a system for this in place for regular documents, but it's probably not used for metadata files yet. -Original Message- From: Petteri Räty [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 19, 2005 3:59 PM To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Adding support to metadata.xml to mark longdescriptions as outdated I thought that when I am bored I might translate the longdescriptions in metadata.xml files to Finnish. While thinking about it the following problem came to mind: When the English descriptions are updated there is no way currently to mark the other translations as outdated. I think it would be create to have a modified attribute or make an other solution that would make it easy to find outdated descriptions in the tree. The modification of the date could easily be integrated to for example repoman. Regards, Petteri Räty (Betelgeuse) -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] Re: where goes Gentoo?
I think Brian is right, we should stick to being constructive. Let's start an enterprise project on Gentoo.org Goals: 1) provide documentation on existing tools and practices for business/enterprise users. 2) try to enhance the set of tools to build a comprehensive framework that makes it easy to use and deploy Gentoo in a business/enterprise environment. 3) provide information so that concerned parties can find companies that specialize in Gentoo deployment/management/support. Any ideas? --Eric -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] Re: where goes Gentoo?
>On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote: >> >> Interesting thread. I have used Gentoo in enterprise situations very >> successfully, and I think the whole QA/live-tree argument is moot. In >> an enterprise environment, you might have a backup/testing machine to >> run your updates on first before they went live. You also wouldn't run >> new packages unless they passed your own QA tests first. >> >> Given the incredible flexibility of portage to support local mirrors, >> binary package preparation, and localized versions of packages >> (portdir_overlay), I would say that Gentoo is quite a contender in the >> enterprise environment. >> >> Perhaps we need some enterprise documentation to help people realize the >> full potential of portage? > >I think you've missed some of the idea of "enterprise" support. See, >for starters, every person shouldn't have to create their own >implementation of everything. Perhaps a better solution would be a >package that when installed, builds up a local mirror, a binary package >repository (with revision control), an automated update system, a system >for updating rolled out machines without forcing the use of etc-update >on each machine, a slower moving stable tree capable of being certified >with applications, and most likely a phone number of someone to call >when the shit hits the fan. Every business application of Gentoo I've done has been different. I don't think I could generalize my needs into a single ebuild. Although generally I have used rsyncd and apache, I never use them in the same way. What's so hard about using the default rsyncd config, and adding distfiles to your apache document root? (what 90% of people would use). About automating updates and etc-update: you can rsync your config file sometimes and just bypass all of the portage stuff. You could mount some config dirs over nfs even. You could even remove config_protect on some dirs and roll your own custom packages. About a slower moving portage tree for enterprise users: Great idea, I think there's a GLEP about that. I think it's best handled by third parties who can spend the money/man power on that kind of QA. This brings me to your last point about calling someone when there are problems: There are companies that provide Linux services, even Gentoo specific services. Some of these companies might even provide enterprise-grade portage mirrors with support for the packages they maintain there. > >While I will completely agree that Gentoo *can* be used in the >enterprise successfully, that does not make it "enterprise-ready", in >any sense. Many people also seem to misunderstand the concept of >"enterprise" when we are referring to it in this manner. We don't mean >"I'm running it on 10 servers in production" or anything like that. We >mean "I'm running this as our production platform for Linux services >across our entire enterprise, that could be hundreds or even thousands >of servers" instead. While it might be possible to maintain a handful >of Gentoo servers, it is next to impossible to maintain an army of them, >without spending significant up-front manpower to design, test, and >implement your own set of management tools. Gentoo has no real >management tools. There are a few here and there that do specific >tasks, but there isn't anything designed to really take control over >your network of systems. To be fair, Red Hat doesn't have anything like >this, either. Their "Satellite Server" product is good for initial >builds and for updates, but falls short on the management aspects. >Novell's offerings are probably the best examples of what we really >need. Of course, most people would be happy with even rudimentary >management capabilities, as currently, we have none. We don't have any >form of update server. You have to build one yourself. We don't have >any form of "jump-start" or "kickstart" for rapid automated deployments. >You have to build one yourself. Now, we do have the Gentoo Linux >Installer project, which has this as one of its goals, so we will have >this component at some point in the future. I'm sorry, I never ran 1000 Gentoo machines in production like that, I thought enterprise meant this (answers.com): en·ter·prise (ĕn'tər-prīz') pronunciation n. 1. An undertaking, especially one of some scope, complication, and risk. 2. A business organization. 3. Industrious, systematic activity, especially when directed toward profit: Private enterprise is basic to capitalism. 4. Willingness to undertake new ventures; initiative: “Through want of enterpr
RE: [gentoo-dev] Re: where goes Gentoo?
Interesting thread. I have used Gentoo in enterprise situations very successfully, and I think the whole QA/live-tree argument is moot. In an enterprise environment, you might have a backup/testing machine to run your updates on first before they went live. You also wouldn't run new packages unless they passed your own QA tests first. Given the incredible flexibility of portage to support local mirrors, binary package preparation, and localized versions of packages (portdir_overlay), I would say that Gentoo is quite a contender in the enterprise environment. Perhaps we need some enterprise documentation to help people realize the full potential of portage? -Eric -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] init script guidelines
Not everyone can patch them, more people would be capable of writing half-baked hacks that resolve most of the issues. Anyway I guess the new baselayout sounds promising here. > My point is that Snort and Apache are not alone in this, so I suppose > quite a few upstream developers just disagree with us on what proper > initialization means. Why should our users suffer? They shouldn't, but that doesn't mean implementing some half-baked hack to resolve the situation. It might be better to instead patch the daemon in question and send the patches upstream. Upstream developers (usually) are much more willing to make changes when you've done the work for them... ;] -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] init script guidelines
A few responses: (Please forgive the lack of normal formatting) 1) To Chris Gianelloni I really do agree that it's silly for a daemon to lie about it's initialization status. However, after actually haven taken some of these issues upstream (in particular Apache 1.3). I realized that the upstream devs don't really consider these bugs all of the time. In Apache's case, it's a bug, but one that's never going to be fixed in 1.3 (2.0 supposedly fixes it). I think there was one case where pure-ftpd actually fixed one of these bugs when I reported it. My point is that Snort and Apache are not alone in this, so I suppose quite a few upstream developers just disagree with us on what proper initialization means. Why should our users suffer? 2) To Mike Frysinger Most of these services are pretty common, and the suckage is usually limited to this area of initialization =) I do see how timing could be an issue for sleeps, but I would personally much rather have a timeout variable in conf.d somewhere rather than no check at all. I would also much rather have a simple check be performed that produced false positives itself (which is what the init scripts are doing now), as long as it cut down on the total number of false positives. 3) To anyone else So far it looks like developer awareness is the best we can do? What about making standard functions or check services available to help developers who are aware and need to use them? Even if developers just become willing to add checks, that would be great. Right now most devs simply rely on upstream (although I think upstream should certainly be a part of each case). -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] init script guidelines
Services that use Gentoo init scripts often report a status of [started] or[OK] even though they fail to start. The most recent bug like this that I'vefound is with snort. If you have a bad rule, snort will initialize, therc-scripts will give it an [OK] status, and then it will die once it parses therules. The real problem is not that the daemons don't return errors, but that our initscripts do not make reasonable attempts to verify service startup. If a Gentooinit script claims that a service started, it should make an effort to checkthat the processes are actually running shortly after the script is run, even ifstart-stop-daemon says the parent process initialized. Relying on the returnvalue of start-stop-daemon is simply insufficient for some services. I am aware that there are services that can monitor the status of other services(app-admin/mon?) but I think this issue is a little different. If an ebuilddeveloper is aware of an error condition can commonly occur shortly after adaemon initializes, why not attempt to catch those errors? Most of them couldprobably be caught by simply checking to see if the process is still runningshortly after the script is run. I propose increasing developer awareness of this problem, perhaps through someformal guidelines for ebuild developers. At the very least, I would like to seethese bugs being acknowledged in bugs.gentoo.org instead of getting the same oldupstream/it's not our fault response. We are responsible for our init scripts,and they are important to our users. I have 2 ideas for the actual implementation: 1) Some kind of check() function in the init.d script, or a generic check() functionthat just checks with ps | grep. This might typically be called after having theinit script sleep for a certain amount of time. 2) Some kind of special init script that checks registered daemons after all serviceshave started. (i.e. it depends on all daemons, or they are put into it’s config file).With this scheme we could avoid excessive sleeping during startup (to keep it fast),And perhaps even keep using service specific check() functions Does anyone else think this idea is worth looking into?
