Re: [gentoo-cluster] sci-biology ebuilds [WAS] RSH/SSH? (Solution)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brady Catherman wrote: | BTW, are you guys looking for other commonly (or in some cases.. ultra | rarely) used science/biology ebuilds? I have built something like a | dozen for the utilities that we use in house here. That might find more talk on the gentoo-science list. Although I'm sure some people would be interested. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDe6NUXVaO67S1rtsRAqvJAJ4485mji3rjhl/J3Ck45vuaAHpInQCgnfHx s2WmigXeIP4YwBcENfHLts0= =M8Wy -END PGP SIGNATURE- -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] Gentoo clustering à l a www.clustermatic.org (PXE booted nodes )
Eric Thibodeau wrote: The way I see it, multiple Gentoo roots would be available (different machine profiles/optimisation) and they would be specified in the DHCP server's config file as simply as any PXE entry So I am not too sure I understand your couple of ROOT=/foo _and_ the busybox one... I just had a single NFS root for all the nodes; didn't have time to get more sophisticated. So the couple of ROOT was one NFS, one busybox. Didn't know/find such a document specific to Gentoo!Google to the rescue, I skipped through http://www.gentoo.org/doc/en/diskless-howto.xml and I agree that the copying of the master's environment is definately not the approach I would take. But, from what I read, it should be fairly easy to modify the procedure simply to point to a root that is an independant Gentoo tree, into which we can chroot (...limited to compatible arches of course...) and manage the installed packages from there (portage tree could be loop-mounted to avoid duplicating it). No reason to chroot, loop mount and all that garbage if you're just doing package management. Just start by unpacking a stage there, and then: ROOT=/path/to/diskless emerge -up world Thanks, Donnie -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] Gentoo clustering à la www. clustermatic.org (PXE booted nodes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Weigt wrote: | Donnie Berkholz wrote: | What exactly do you want more detail about? | | | They boot to an initrd containing busybox, then proceed to mount | necessary bits from a read-only NFS export and other bits via tmpfs | where they need to write, then pivot_root into the new NFS root. | | I'd like like some instructions how to do these things you wrote above. | If you don't like to write a huge essay, I don't mind getting it step | by step. A linuxrc file does all sorts of stuff. linuxrc is a file within an initrd that gets automatically executed when booting into the initrd. The initial, skeletal linuxrc downloads a more complex script called linuxrc.real from the NFS server and executes that. The more complex script mounts a number of NFS exports (/ and so on), then mounts tmpfs for the areas that need write permissions (chunks of /var and so forth). Another option here would be a unionfs, but I haven't looked into it. Originally, I got both of them from xmerlin (another dev), and modified them a bit to fit my circumstances. I'll look around a bit to see whether I can find them, and send them along. Another thing you'll want to look into at this point is using initramfs instead of initrd. initramfs is initrd's successor and operates a bit differently. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDf//4XVaO67S1rtsRAs96AKCx9wBPSplknmDund3Pj98CufCu0gCePpP8 aVhbOADoW+2ZBSLkmdxaCNw= =4Hi0 -END PGP SIGNATURE- -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] Gentoo clustering à l a www.clustermatic.org (PXE booted nodes )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stéphane Lacasse wrote: | Like you said, it's beside the point, but I think you could take a look | at their design and draw some inpirations from it. An easy install like | Rock Cluster but instead of using Kickstart(tm) files, would use the | emerge system + distcc + quickpkg. The gentoo installer can take a profile, which is essentially the same as a kickstart file. There are numerous front-ends, including GTK, dialog, or cli (which can be scripted). At least one person has already used the cli front-end to install a cluster. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgYbXXVaO67S1rtsRAu/+AKDkETdhygNZZdIqBm+o7IxvwCNK/gCg4pbH lYWFw5KHiwqeLIsUIJ6XdF4= =dyiC -END PGP SIGNATURE- -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] Install on a headless XServe?
Brady Catherman wrote: My next step was to take the live CD and try to modify it. The live CD needs two things enabled in order to consider it ready for use on a headless XServe G5. It needs to enable the serial console by default, and it needs fusion MPT support. Might be nice to search for and file bugs requesting these. OpenAFS segfaults the kernel every time its started (annoying) Another bug... Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] Switchable MPI
Andrew D. Fant wrote: I'll dig around and forward the ebuild to the list later tonight or tomorrow. At the risk of going off on a rant, I think that the /etc/env.d model is a core part of the problem. If two users want to use two different mpi implementations, will eselect allow them to both use them at the same time, or will it have to be one or the other at once? As I see it, something will have to be tweaking $LD_LIBRARY_PATH for each user's environment, Yep, that's the plan. Some things just won't work as well because they don't really respect variables, like the includes. Something like this: MPI_IMPLEMENTATION=$implementation PATH=/usr/lib/mpi/$implementation/$version/$compiler/bin:$PATH LD_LIBRARY_PATH=/usr/lib/mpi/$implementation/$version/$compiler/lib:$LD_LIBRARY_PATH CPPFLAGS=-I/usr/lib/mpi/$implementation/$version/$compiler/include:$CPPFLAGS MANPATH=/usr/lib/mpi/$implementation/$version/$compiler/share/man:$MANPATH INFOPATH=/usr/lib/mpi/$implementation/$version/$compiler/share/info:$INFOPATH or /etc/ld.so.cache will have to be changed for each user's login to reflect their prefered mpi environment. That totally screws with multiple simultaneous logins. Environment variables will have to be the way to go. $PATH and $MANPATH can be handled by judicious checks in /etc/csh.cshrc and /etc/profile, but since /etc/env.d insists on manipulating the shared object cache directly, this has the potential to get really ugly without some cooperation from the core system team. I don't think that the cluster herd can fix it on it's own. I think we can, but I could certainly be proven wrong on this. I would love to be proven wrong and will gladly defer to anyone who does so, I just know that I've been trying to outthink this problem for a year or so on our cluster and haven't come up with a sane solution for a true multi-user environment. I would love to find a way that works too. =) Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] High-Availability Howto for Gentoo
Ramon van Alteren wrote: Suggest we pick one of the usual free licenses (maybe the same as the gentoo documentation project uses ?) Please! Otherwise we can never incorporate the material into any official documentation. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] High-Availability Howto for Gentoo
Brady Catherman wrote: One last question for you all.. Why is distcc so popular? We used it on our 134 node cluster and it actually made compiling much slower than just running it on one of the nodes. The network overhead killed the performance gain. The only way we found that it helped was writing the makefile itself to take advantage of parallelism. Is this uncommon for most people? Autotools (properly used) create parallelizable Makefiles, so that's not much of an issue. Clearly if you're just exporting the same job to another node instead of parallelizing across multiple nodes, you will see a performance loss. distcc is particularly useful when not all nodes are attempting to locally upgrade/install something at the same time, so they team up on a parallelized compilation for a single node. There's no effective gain by using distcc on a large cluster if you're just compiling everything on every node -- you should be using it in parallel to build binary packages once, then installing across all nodes. distcc is also useful when you've got a mixture of slow and fast nodes, for obvious reasons. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] Gentoo vs RedHat cluster
Brady Catherman wrote: So the short of it is that higher is always better, and this is only a 'best as I personally' could do comparison. OK, thanks for the clarification. Have you also run lmbench? After our conversion things went together much smoother and now maintenance is fairly painless. I spend all of my time setting up our Apple cluster (The Gentoo ppc64 performance just wasn't good enough to wow the management into using it =) Yeah, from the numbers it looks as if it would be dependent on the purpose of the cluster whether OS X or Gentoo would do better. On ppc, Gentoo does poorly on the first two benchmarks and also on context switching. On x86, the first two are more comparable with RH, but the others, Gentoo has a small to large advantage over RH, just as on ppc. One big advantage of Gentoo is the ease in which new programs/libraries can be installed. I have written dozens of ebuilds for all the programs we use here in order to simplify installation and administration. If they're redistributed programs, we would very much appreciate contribition of the ebuilds. Now to install a new program I just have to build it on a node using: echo emerge -b program | qsub Then I install it on everything else using: emerge -K program ; pdsh -a emerge -K program Got a pdsh ebuild? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] Docs
Donnie Berkholz wrote: We used to have some documentation floating around, but it never got put on the Gentoo site and converted to GuideXML. I think there was a filesystem selection guide and a Heartbeat/DRBD howto, maybe something else. I'm poking the author to see whether he can dig them up. Finally picked the docs up: http://dev.gentoo.org/~spyderous/proj/cluster/fs-selection-guide.html http://dev.gentoo.org/~spyderous/proj/cluster/heartbeat-howto.html http://dev.gentoo.org/~spyderous/proj/cluster/keepalived-howto.html Anyone interested in going through them to update them and ensure they're accurate? Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-cluster] Adapting java-config for mpi-config
This message about java-config just passed across gentoo-dev. Apparently
it can switch both on a system and a user level, so it may be worth
looking into for adapting to mpi-config.
Thanks,
Donnie
Original Message
Subject: [gentoo-dev] Changes to the way Java packages are built
Date: Sun, 18 Jun 2006 10:39:06 -0500
From: Joshua Nichols [EMAIL PROTECTED]
Reply-To: gentoo-dev@lists.gentoo.org
To: gentoo-dev@lists.gentoo.org
= Background =
As some might have noticed, Java 1.5 has been package.masked for some
time now. There are a number of issues introduced with 1.5 that have
kept it in package.mask. Please see the Java 1.5 FAQ [1] for more details.
[1] http://www.gentoo.org/proj/en/java/tiger-faq.xml
About a year ago, work was begun on improving our part of the build
system (read: Java related eclasses and our java-config tool) in a way
to make it much more flexible in general, but specifically improve it to
get around the known issues. It took about six months to fully develop.
Unfortunately, the new system was not quite a drop-in replacement. So,
it took from then until now to determine how to migrate from the current
system to the new one in a sane way.
= The Current System =
To give some proper background, it is worth going over the current
system briefly.
== The Java Virtual Machine ==
Each Java Virtual Machine (VM) installs an environment file into
/etc/env.d/java. These files contain information about where JAVA_HOME
is, the PATH to include, etc.
VMs traditionally get installed at /opt/${P}
We have the concept of a 'system' VM and a 'user' VM. The system VM is
the default VM that will be used for root, and for users who haven't
selected a user VM. The user VM is, as one might guess, selected on a
per user basis. It is worth noting that root always uses the system VM,
and as a result, packages use the system VM when being merged by emerge.
java-config is used to set the system and user VM. When you do so, the
appropriate file from /etc/env.d/java is copied to/etc/env.d/20java for
the system VM or to ~/.gentoo/java-env for the user VM.
java-config's notion of the current VM is tied entirely to the
environment, specifically to JAVA_HOME. Therefore, if you change the
system VM, you'd need to run env-update and then resource /etc/profile.
Likewise, changing the user VM involves sourcing ~/.gentoo/java-env.
The fact that you're tied to the environment is annoying, because as
mentioned, you need re-source the appropriate files. Now imagine you
have a ton of terminals open... you'd have to source the environment
files from each one.
== Packages ==
When a Java package is built, information about it is saved in
/usr/share/${PN}-${SLOT}/package.env (or /usr/share/${PN}/package.env if
SLOT == 0). In particular, the jars that are associated with the package
are recorded, as well as which jars from other packages are used.
java-config can later be used to query for this information.
== Eclasses ==
There are currently 3 eclasses: java, java-pkg, and java-utils.
java.eclass is used for packages which provide a VM.
java-pkg.eclass is used for most Java packages. It provides tools for
querying installed jars, and for installing various Java related files.
java-utils.eclass provides a few utility functions for dealing with Java
stuff.
= The New System =
== The Java Virtual Machine ==
In addition to the concept of a system and a user VM, the new system has
a build VM. As the name implies, the build VM is used for building
packages (instead of the system VM). Sane defaults are defined on a per
platform basis at /usr/share/java-config-2/config/jdk-defaults.conf [3].
The build VM can further be configured by
/etc/java-config-2/build/jdk.conf [4] .
[3]
https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk-defaults-x86.conf
[4]
https://svn.gentooexperimental.org/svn/java/java-config-ng/branches/axxo/config/jdk.conf
For each Java release (ie 1.3, 1.4, 1.5, etc), you can specify which
vendor and version to use at build time.
In addition to being installed to /opt/${P}, VMs also now have a symlink
in /usr/lib/jvm/${PN}-${SLOT}. The purpose of these symlinks is
explained further down.
The user and system VMs are now represented by symlinks pointing to VMs
located in /usr/lib/jvm/. The system VM lives at
/etc/java-config-2/current-system-vm, and the user VM at
~/.gentoo/java-config-2/current-user-vm . Additionally, an environment
variable, GENTOO_VM, can be used to specify the VM used at a given
instance. GENTOO_VM should be the name of a VM located in /usr/lib/jvm.
So with regard to what VM is used, first GENTOO_VM is checked, then the
user VM (for non-root users), and then lastly the system VM.
All the trusty java binaries, ie java, javac, javadoc, jar, etc, now get
wrappers installed into /usr/bin. These are actually symlinks to
/usr/bin/run-java-tool. This is a script which will figure out which
tool was invoked, and then determine which VM to used
Re: [gentoo-cluster] openib
Hanni Ali wrote: I feel it would be sensible to have a gentoo cluster overlay for all clustering and grid related software, would be useful for testing and collaboration. http://overlays.gentoo.org/ http://overlays.gentoo.org/ There's already some stuff in the gentoo science overlay [1]. I'd prefer to wait on creating an official clusters overlay until better VCS software is available on o.g.o. Thanks, Donnie 1. www.gentooscience.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] openib in science overlay
Bryan Green wrote: Thats great to hear. Consider them a work in progress. They work great for me, and I've only tested them on amd64. I'd be happy to get feedback, including fixes/additions. Bug me on IRC sometime and I'll look them over with you. I'm pretty busy today though. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] examples of (large) Gentoo clusters
Bryan Green wrote: Yes, I actually used those ebuilds to test Lustre on our mini 3x3 hyperwall which runs Gentoo. I was able to get it working, but over here they want the supported, released version, whereas those ebuilds are for the beta. I tried to install the released version, but eventually ran into problems. Also, since getting support from CFS is a requirement, that restricts the OS choice to specific versions of Suse or Redhat. I guess that means we should get in touch with them to get on the supported systems list. =) I'd very interested in the different approaches here. I had thought about a static portage tree, but that left the problem of getting needed updates, especially GLSA's. Your suggested approach sounds very interesting. How big of an extra administrative burden does that create? Maintaining our own version controlled portage tree might be a hard sell. Thanks for the script - I'll take a look at it. Is there any documentation out there about a static portage tree? The OSL (Open Source Lab), which hosts much of the Gentoo infrastructure and runs a lot of other projects on Gentoo boxes, takes a similar approach to what I mentioned above. I think you already know Corey Shields, so you could ask him about it. You may also want to take a look at http://article.gmane.org/gmane.linux.gentoo.devel/43984 -- it's from one of our developers who's deployed fairly decent-sized clusters. Thanks, Donnie -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] examples of (large) Gentoo clusters
Bryan Green wrote: Donnie Berkholz writes: I guess that means we should get in touch with them to get on the supported systems list. =) Sounds like a fine idea to me. :) I talked to someone there at SC06, but they did not sound terribly open to the idea of directing precious resources in that direction. But it would be great to convince them otherwise. We would probably need to show that there are a decent number of places that would like to (or already do) use Lustre on Gentoo, and would be interested in paid support. We've now got at least you and SiCortex using it, but not sure about interest in support from SiCortex. Anyone else? Thanks, Donnie -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] examples of (large) Gentoo clusters
John R. Dunning wrote: From: Bryan Green [EMAIL PROTECTED] A longer term solution is to do some combination of remodularizing vfs and recasting the lustre stuff so as to depend less on getting its fingers into the guts. I once spent some time looking into that, and I do believe it's possible, but it would take some work, and would really need to be done in concert with the rest of the core kernel guys, and I ran out of time to pursue it. In the meantime, the more the gentoo community can resist the temptation to patch the kernel (at least the vfs parts of it), the easier it will be to add lustre. Based on what you've said, I wouldn't fool around with SLES, I'd just figure out what close-to-vanilla kernel you want to start from (picking one you think you can live with for a while) and do some part of what I described above. You might have a somewhat easier time of it if you started with 2.6.18, as I believe there's a cfs-supplied patchset for that one. If you want to start from a gentoo 2.6.18 one, I suspect your task will be to start with vanilla, make that work, then work out how to re-apply the gentoo patches. Re getting cfs to help, my bet would be that you'll have an easier time getting the gentoo community to create patches that are amenable to going on top of a lustre-ized vanilla kernel (and relying on cfs to support vanilla kernels) than you will getting cfs to generate patches to go on top of gentoo. If you watch the lustre lists, you'll see more people asking for vanilla than are asking for gentoo. I've just got a couple comments on this. * The gentoo-sources patches are almost all upstream and based on the W.X.Y.Z stable release patchsets, except for 2-3 cases that probably aren't relevant to clusters. As a result, Gentoo folks would be reasonably well off just running vanilla-sources, which groups them in with everyone else wanting Lustre on a vanilla kernel. * Normally I would recommend hardened-sources for anything resembling a server, but you should have all your nodes and file servers blocked off from the Internet anyway so that's a non-issue. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-cluster] Herd split? hac-cluster and hpc-cluster
We might benefit from splitting the clustering packages into two separate groups for high-availability and high-performance computing. This will help to keep the bugs a bit cleaner so each group of folks will have a clearer idea of what they need to do. Does anyone else have thoughts on this? Thanks, Donnie -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] Herd split? hac-cluster and hpc-cluster
Andrew D. Fant wrote: Donnie Berkholz wrote: We might benefit from splitting the clustering packages into two separate groups for high-availability and high-performance computing. This will help to keep the bugs a bit cleaner so each group of folks will have a clearer idea of what they need to do. Does anyone else have thoughts on this? It sounds like a good idea. Are there enough developers who would want to go with either herd to make it viable? Here's the cluster alias: azarah ct george dberkholz pyrania voxus iggy xmerlin markusle ribosome Of those, I haven't seen azarah, ct, george, pyrania or iggy do anything lately. ha: xmerlin hpc: dberkholz, voxus, xmerlin, markusle, ribosome tantive also has metadata for much of the openmosix stuff. This pretty clearly shows that we could use extra help for HA packages. Thanks, Donnie -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] Herd split? hac-cluster and hpc-cluster
Philipp Riegger wrote: On Dec 11, 2006, at 9:11 AM, Donnie Berkholz wrote: Does anyone else have thoughts on this? I think, hac-cluster and hpc-cluster sound strange, since c in hpc and hac already stands for cluster. or computing... -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] gentoo 2006.1 + openmosix-sources-2.6.12.r577 + openmosix-user?
Hanni Ali wrote: ok so follow the hpc how to: http://www.gentoo.org/doc/en/hpc-howto.xml but modify for diskless which you seem to have got the hang of. FWIW, I've got plans to put together a doc for a clean setup of a diskless cluster. I'm unhappy with our clustering documentation, although it is better than nothing. Once I finish the LTSP port to Gentoo (which starts as standard diskless nodes), I'll probably write this doc up. Thanks, Donnie -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] SCIRE Project
Daniel van Ham Colchete wrote: I would like the deployment and maintenance to be done as easily as possible because this project needs to be scalable to more than 100 servers. Although we are going to install only 10 servers in the beginning, my boss says that I should be prepared for this number to grow. Good plan. Yesterday I found about the SCIRE project that seems to solve my problems easily. But it seems that the project's development is stopped. Unfortunately, I don't know a thing of Phyton, so I can't help. Do anyone know how is the project going? Are we going to have a production usable release? If so, when? It's not like I'm pushing anything, I just want to know if I can count on it or not. Setting the project aside, I'm thinking about developing my own installer to install a catalyst's stage4 and reboot a working Gentoo. After that I'm thinking about using emerge with binary packages to install updates automatically. What do you think? Will it work? Is it possible to rollback an update if something goes wrong? If you're just looking for an installer, check out quickstart -- http://archives.gentoo.org/gentoo-installer/msg_01300.xml and http://www.gentoo.org/news/en/gwn/20061218-newsletter.xml#doc_chap2 have some details, and you can get a copy at http://agaffney.org/quickstart/ . It was designed for automated rollouts. (When reading, GLI = Gentoo Linux Installer.) The SCIRE code is available at http://sources.gentoo.org/viewcvs.py/gimli/scire/ and there is a gentoo-scire mailing list, which would be a better place to ask questions about it. Thanks, Donnie P.S. -- In the future, do not post to two subscriber-only lists, because almost nobody can reply to both. signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] SCIRE Project
C. Bergström wrote: I've uploaded my rough outline of what I have so far to a google doc and started #gentoo-deploy on freenode for anyone interested in working together on this. I'd like if you guys could stick in #gentoo-cluster instead of a new IRC channel, it's relevant to everyone in there and saves those of us already there from adding yet another channel. Thanks, Donnie -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] SCIRE Project
C. Bergström wrote: Donnie Berkholz wrote: C. Bergström wrote: I've uploaded my rough outline of what I have so far to a google doc and started #gentoo-deploy on freenode for anyone interested in working together on this. I'd like if you guys could stick in #gentoo-cluster instead of a new IRC channel, it's relevant to everyone in there and saves those of us already there from adding yet another channel. I'm hoping our channel will create some noise next month and really put together something nice. I've been in #gentoo-cluster and wouldn't want to disturb the quiet there. Please don't be deceived into thinking the quiet in #gentoo-cluster is a goal. It's just a byproduct of a lack of new, useful things to talk about. If you've got some, please contribute them. Thanks, Donnie -- gentoo-cluster@gentoo.org mailing list
Re: [gentoo-cluster] Porting RH gfs-deploy-tool to Gentoo
C. Bergström wrote: I'm trying to really clean up my cluster deployment and while looking at GFS came across this. http://people.redhat.com/rkenna/gfs-deploy-tool/html.doc/ My first thoughts are of course switching out the dependency to pull rpms from the rh network to PORTAGE_BINHOST.. I'm hoping to find the time within the next 30 days to port this to Gentoo. If anyone is interested in contributing or the results let me know. Also any feedback from those using GFS is most appreciated. Your work would be most valuable if you could change the code to have distro-dependent plugins or directories, with a setting controlled by some sort of configure flag. That way, we could get your changes back upstream and also allow other distros, such as Debian/Ubuntu, to start using it. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-cluster] Network Booting
On 09:31 Fri 25 Jan , Ramon van Alteren wrote: I remember seeing a demo from yamin at a gentoo UK conference demoing netbooting with a genkernel kernel That's the genkernel-4 code. I've used it for diskless setups and it works quite nicely. It's living on gentooexperimental.org at the moment. We've build a system of catalyst, pxe+grub-netbooting + agaffneys quick-install + puppet that uses pxe to start bare-metal servers and bring up to production config in 45 minutes. Any chance you could share some puppet configs? It would be great to build a library of Gentoo puppet/cfengine stuff. Thanks, Donnie -- gentoo-cluster@lists.gentoo.org mailing list
[gentoo-cluster] [EMAIL PROTECTED]: RE: Linux/Cluster/Grid Project Leader]
Here's an opportunity to do clustering at Fermi Lab with fully funded grad school (nice in the current funding climate). If you're interested and have clustering experience, get in touch with this guy. Thanks, Donnie - Forwarded message from Darryl Coburn [EMAIL PROTECTED] - From: Darryl Coburn [EMAIL PROTECTED] To: 'Donnie Berkholz' [EMAIL PROTECTED] Subject: RE: Linux/Cluster/Grid Project Leader Date: Sun, 8 Jun 2008 22:51:15 -0600 Thanks Donnie, that would be great. Do you need anything from me? Darryl Coburn 630-573-5050 ext. 340 office 708-767-6367 cell Sr. Manager Cemco Systems www.cemcosystems.com -Original Message- From: Donnie Berkholz [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2008 7:18 PM To: Darryl Coburn Subject: Re: Linux/Cluster/Grid Project Leader I can send it out to our clustering mailing list if you're interested. Thanks, Donnie On 16:23 Fri 06 Jun , Darryl Coburn wrote: Don, Maybe you could help me on this. Just in case you know anyone with great Linux skills and Project Management who would enjoy a World Class Computing environment. While growing their technical career, Fermi Lab will fully fund an MS or PhD degree and sponsor their US Green Card if needed. see below. My name is Darryl Coburn, Senior Manager/Recruiter at Cemco Systems. I have recruited for various National Labs for the past 20 years. I have a Linux Team Leader role available at Fermi National Accelerator Laboratory. This is a permanent position working directly for the Lab. Must have managed large Linux systems (prefer 100's of nodes). Must have Technical Project Leadership/Management experience. Direct management experience is a plus. Cluster/Torque/Grid/Condor experience is a big plus. This environment is a real Technology CandyLand. Fermi will create or transfer H1 B visas, sponsor Green Card, and provide 100% Tuition Reimbursement through PhD. Fermi will even pay for your books! This 6000 acre Campus environment has bike/jogging trails, Gym, Pool, Fine Arts Series, herd of Buffalo, on site Daycare and fishing ponds. Competitive Salary and Great Benefits! Additional 10% of salary paid each year into 403b Retirement Plan. For more details, I can be reached through Friday at 630-573-5050. Please forward anyone with strong skills. Thanks in advance for any help on this.. Darryl Coburn 630-573-5050 ext. 340 office 708-767-6367 cell Sr. Manager Cemco Systems www.cemcosystems.com http://www.cemcosystems.com/ - End forwarded message - -- gentoo-cluster@lists.gentoo.org mailing list
[gentoo-cluster] Fwd: Gentoo cluster list
Here is another Gentoo cluster that needs to be added to the list. - Forwarded message from Tiago Marques tiago...@gmail.com - Date: Tue, 18 Nov 2008 12:35:21 + From: Tiago Marques tiago...@gmail.com To: dberkh...@gentoo.org Subject: Gentoo cluster list Hi! If you would like to add our cluster to the list: http://www.gentoo.org/proj/en/cluster/ Here are its specs: Flamingo cluster @ University of Aveiro, Portugal 64 cores, 8 nodes, Quad-core Xeon E5430 8GB RAM Best regards, Tiago Marques - End forwarded message - -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpu0LiFmDtFM.pgp Description: PGP signature
