Re: [gentoo-dev] Gentoo Enterprise deployment tools
M. Edward (Ed) Borasky wrote: Thierry Carrez wrote: Hi folks, I would like to get your opinion on Enterprise-oriented desktop deployment tools for Gentoo Linux (or the lack of). As a small company CIO, I deployed Gentoo on a small scale here but quickly ran into scaling problems and the lack of tools to help. I have deployed gentoo on openmosix for the reason of scale, where only one machine was the subject of configuration and point of access, while all neighbor nodes were less specific in configuration but all shared kernel. openmosix is more secure than plain old IP, given its custom marked packets (or something keen like that) and is well suited to LAMP which can occasionally expect a cgi process to take a dump or hang or freeze, upon the loss of a node holding its virtual process. open source databases have lousy replicatoin, or at least did when i was undertaking this. its unlikely the IO-bound processes will migrate, but the linked-list traversals deservedly take a hike(ie migrate) when the app design falls short. so the question of how to begin locking down packages, etc for HA, that's where staging and testing plans are of key importance. this is where my own syadmin handywork started with a cloning system: the mothership on one side, and a rescue disc, gig-e hub, and a nc/gnutar combo to clone and stage mutations/development. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a #g-d first impression about voip (semi-technical)
what i really replied for is to ask, if i can forward your email to a friend of mine who happens to be involved with telephony with his company, i know zero about that, i do know he does use VoIP, so maybe he finds your hack nifty | | Jim hope you better luck next time in #gentoo-dev Daniel Yes, please. roughly what I can spell out with patience is: I have borrowed some qos configs elsehwere, applied occam's razor, and been satisfied with controlling outbound traffic [using only vanilla modules and no user-space]. wrt to throttling inbound traffic: I have googled, inquired, and seen non-vanilla qos modules but have not found an authority with which to ask a few very specific questions about ingress. this means that inbound traffic is not throttled and i just take it easy on multithreaded transfers. goals: run 5-10% headroom inbound at all times for voip (and similar realtime udp streaming) on broadband, inbound and outbound. This reduces upstream packet-queuing which can postpone delivery of voip packets ideal solutions leading to the goal: 1) delay TCP packets, never drop. so far I haven't found an *tables vanilla kernel module which documents the delay facility of a packet class. the collective forum may have covered more ground than I have covered 2) monitor all conntrack'ed tcp windows, delay ACK, and shrink windows on large numbers of descriptors in realtime 3) files of implementation fit the regex /etc/*.d/qos (with package deps, but no artifacts) 4) lock down the reasons why IMQ non-vanilla module/patch is the only documented sane inbound qos filter on googled sources and why not to treat TUN vanilla module is not an identical facility... The answer to my unfinished questions may exist in places I haven't turned over, however, testing the variations of inbound and outbound qos configs is a slow process with alot of phone downtime and advanced router side-effects leading to reboots. Jim -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] where goes Gentoo? Where went Fido?
Aron Griffis wrote: This is kinda bloggish, because it's basically a transcription of an IRC monologue. My apologies if it's hard to follow... This thread started out garnering cheers of elitest developer sentiment. There was even some mention of if they don't like it they can run something else. Then, that notion was reeled in, the developers are part of the user community. There is an open debate as to the meaning of support for 'enterprise', 'cluster', and 'hobbyist'; does gentoo mean any of these? In this thread I posted a suggested hack which must surely have been suggested before my reading/perusal of gentoo-dev, but also addresses a tangible element, growth. -- Portage's power is too great in one place, it should be forged in the hottest fires into the form of many rings for the leaders among gentoo, with one ring to bind them. Gentoo portage is growing, gentoo's communication network is growing in complexity, and gentoo's organization is growing. I saw it interesting that this is what describes the rise and fade of FIDO net. First there were hobbyist, later came zealots, some with bad attitudes, and eventually a full fledged organization devoted to handling the politics, which grew large enough for division into zones. There were online businesses thriving from its value as well as the very resourceful and isolated folks who had no other means of communicating among the world at large. One of fido's most interesting feature was its initial recognition that its growth needed structure, and that structure was formed. fido's own politiks from around the world failed to vote for survival of the IFNA(International FidoNet Association). So fido dissolved its official entity, and continuted to grow. Fido became a concept which spun off saplings and intertwined with the net, but in majority of years it was run by the folks with the biggest toys. I mention fido because of one similarity which is uncannily familiar. only 26% of the potential voters recently cast a vote for the gentoo metastructure. we saw some puzzlement, bordering on grumbling, and some amusement: eeeyup that must be us!. sooo. back to growth... does the portage design foretell a single monolithic repo growing ad infinitum? this is the common watering hole which draws every single participant to the same well. it's gotta work, 'emerge world' has gotta fly. does tinderbox indicate this is a predictable outcome with a stable margin of error, as t approaches infinity? if not, where goes gentoo? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a #g-d first impression might represent process and metastructure
Joshua Baergen wrote: 2) There are gentoo.org references to #gentoo-dev, but the process of interfacing, mentoring, and recruiting are self-referential beginning with a bootstrap of being on the good side of an existing developer. So for those of us who do not establish favorable dialogues by filing a bug, the door starts out closed. In reference to the difficulties outlined regarding becoming a developer above, I am in the process of becoming a dev without any contact with developers beforehand except for filing a bug that probably annoyed devs more than helped :P I contacted the recruiting group in response to a requirement for developers and they were glad to get the process started provided that I showed evidence that I would be an asset, mainly through input on bugs currently open. I doubt that I am the only one who has this story, but that doesn't mean your claim in #2 could not have happened to other people. Did you have any specific situations you were referring to when you wrote that? I was up late on a friday evening hacking up a nifty addition to my system and in my excitement and exuberance jumped on IRC to the dev channel to get pointers to the best official references to ebuild crafting and submission. As it was absolutely silent, I waited a few minutes and requested voice from the first notice of motion i saw in the channel.. re, or some similar indication of important offical business commencing. I was informed that the bottom line was voice was only granted to developers, period, end of story, no exceptions, and I was obviously misinformed and should be elsewhere. Instead of anything like assistance I wound up being told 1) (condescension) it was people like me who try to skirt the gentoo process which are actually the problem even if we think it's contributing, 2)these important people in this channel are only here so that they can occasionally ping each other and see thier nickname had been highlighted. 3) that under no circumstance was I going to get an audience in #gentoo-dev, now or in future context, because it was for developers, and regardless of 20 years coding experience or working on linux since 0.99, I was not a developer 4) I could feel free to file a bug if I thought there was an issue, or talk to a recruiter about something to help out with. my reply was that I enter #gentoo-dev, and request voice when it seems helpful and important, without incident in all previous occasions the response was that these developers were obviously in error and it was irrelevant to the discussion. I said I'm willing to take my chances as being perceived as noise. the response was an unceremonious kick. This developer was possessed with zeal and determination. to be sure. Anyways, it happened, it's over. the order and exact words may have been different but the tone and the impression stuck. I spent the due dillegence perfecting my system hack, but I did not succeed in making it available, or finding a likely benefactor project for voip qos settings. This was beneath the involvment of #gentoo-dev at the time i made the approach. I spent several hours researching volumes of gentoo info alternating between the recruitment process and the ebuild process, on a busy weekend i had planned to spend apart from a console. so.. as an aside, is there a package with an interest in iptable configuration for broadband voip qos configs? Jim -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays
Mike Frysinger wrote: On Tuesday 24 May 2005 05:11 pm, Jim Northrup wrote: but a CF-based or initrd root available when /lib goes to hell is an absolute must for supporting fault tolerance. do you mean like the disk underneath /lib is blown to crap or a bad glibc is merged ? if the latter, then the new busybox can help ... just boot with init=/bin/bb and you should have plenty of tools to recover with -mike great advice. I've learned whenever md or devfs rework occurs, or the **/sbin tools get rev'd, its foolish to proceed without a rescue nearby. of course bb is a space-saver, but i find myself turning the room upside down for full-static versions of tar, nc and fileutils Jim -- gentoo-dev@gentoo.org mailing list
