From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1G5QqU-0006je-Ni for garchives@archives.gentoo.org; Tue, 25 Jul 2006 17:37:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k6PHZhQS009984; Tue, 25 Jul 2006 17:35:43 GMT Received: from ebox1b.ebox.com (ebox1.ebox.com [64.7.141.6]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k6PHZgPo001091 for ; Tue, 25 Jul 2006 17:35:42 GMT Received: from [192.168.1.102] (CPE0016b6287c54-CM0011e6c78e89.cpe.net.cable.rogers.com [72.60.94.243]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ebox1b.ebox.com (Postfix) with ESMTP id C22F7179EFA; Tue, 25 Jul 2006 13:35:40 -0400 (EDT) Message-ID: <44C6567E.3040802@visible-assets.com> Date: Tue, 25 Jul 2006 13:35:58 -0400 From: Christopher Friedt User-Agent: Thunderbird 1.5.0.4 (X11/20060516) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org MIME-Version: 1.0 To: gentoo-embedded@lists.gentoo.org Cc: bdale@hp.com, overholt@redhat.com Subject: Re: [gentoo-embedded] list of devices / boards, subprojects for each? References: <200607201806.08828.ladmanj@volny.cz> <44C14112.3060602@visible-assets.com> <200607210142.27411.vapier@gentoo.org> <44C0FF15.5010702@tampabay.rr.com> <44C201D8.2070207@net.in.tum.de> <44C56D6D.9000401@tampabay.rr.com> In-Reply-To: <44C56D6D.9000401@tampabay.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 355ffa13-118f-4ed8-97af-cb64c4648c6f X-Archives-Hash: df24b4f2b2ff52a76a7d596b0372f5d5 Hello Harald, Mike et al, I'm hearing excellent ideas here. My first conception was to just have individuals responsible for their various boards with collaboration on a common platform, but to have a terminal server for other gentoo-embedded developers is also a fantastic idea. This would facilitate svn firmware images / filesystems, etc. The reason I believe that gentoo would be a great choice for embedded linux is purely for 2 reasons: 1) portage - an incredibly versatile solution to package management 2) a highly 'emergant' user / developer / bugfix base Obviously the developers in gentoo-embedded would prefer to have portage as the primary (only) package management system for gentoo-embedded - that only makes logical sense. However, there is also an important underlying issue here - whether the embedded device is Gentoo-based, Debian-based, or RedHat-based, there is still a need for a standardized embedded device architecture both in software and hardware. Some related notes from my most recent Linux World Expo visit in Toronto: I have spoken to Bdale Garbee, CT Open Source & Linux for HP on a similar topic. I asked him if HP would be interested in supporting a sort of 'summer of embedded code' for embedded Linux. He mentioned that he and HP would be interested in 'facilitating' more research into embedded standards, both hardware and software, since HP uses Linux exclusively for most of their products that have a processor network device built into them (aside from the iPaq ... sigh). Another business card that I acquired was from Andrew Overholt at RedHat. He has helped out considerably with the CDT / Eclipse project. If anyone here has used Eclipse, I'm sure you would agree that it provides an excellent and freely available platform for code as well as management. My opinion is that the management side of something on this scale is almost as important as the code itself, and if that platform can be standardized for embedded developers the world would literally be our oyster. These two potentials could not only improve the state of embedded development but also prove reasonably profitable for all parties involved, including Gentoo, RedHat, and HP, besides all of the subsidiary companies who may be employing the technology. I've CC'd Bdale and Andrew on this. Responses and comments are very welcome. Cheers, ~/Chris wireless wrote: > Harald Schioeberg wrote: >>> There would also have to be an ACL (Access Control List) such >>> that I could regulate who gets access to these boards. >>> I could use some suggestions on iptables rules for this >>> (embedded) DMZ. I have spoken to several folks in the past that >>> have tried this, and maintaining security is always a challenge. >>> So a limited ACL in the beginning until the security mechanisms >>> mature, is a prudent step. >> >> Hi, >> >> here comes my experience with a similar configuration (not developers >> but students with root-privileges, even worse :)) >> >> a stepping-stone host with ssh-logins for outside devs. this is the only >> system, that accepts connections from outside, the firewall blocks any >> attempt to connect to any embedded system directly. we even have our >> devices in a network with private ip-addresses, with no routing at all >> to or from the internet, the steppingstone has 2 nics, one with a public >> IP for ssh-login, and one with the private ip. it does NOT do any >> routing or NAT. the private IP-config will probably not work for you, >> because: >> >> the dev systems probably need outgoing http/ftp/rsync if not more. block >> smtp at all costs. if you need mail for debugging the embedded systems, >> configure your stepping-stone so that it accepts mails for your >> dns-zone, and delivers it locally, but do not forward any mail from the >> dev-dmz. if you only want to support one system (say gentoo) you might >> get along with a local gentoo-mirror, but development is really >> cumbersome if people don't have http/ftp access do download some patches >> or whatever. people will start to build ssh-portforwards if you are too >> restrictive and that kills any firewall. >> >> you need ip-switchable powersupply for all dev-systems, these things >> will crash and the users need a way to reboot them remotly. >> (afair ~300 Euro per 8 devices) >> see that you get some with snmp support, then you can write a small tool >> that checks against the acl before it reboots the device. >> >> you need a serial connection to each dev-system. we use terminal-servers >> for that purpose. make sure you can break a serial login, users will >> forget to log out and block the serial port forever. again, see for snmp >> support for that purpose. >> (terminal-servers are really expensive, about 150 Euro per port, but you >> can use a pc with lots of ports, and use a serial-to-network daemon) >> >> if multiple devs should be able to share a device, you need some kind of >> a reservation system. We started with a wiki, where everyone entered the >> devices that he wants to book in a table. that worked amazingly well. >> now we have switched to a sql-db, with allows us to restrict the logins >> on the devices to that devices, that the user has actually reserved. the >> most important thing is that never 2 independant users access the device >> at the same time if they want to do things like system configuration >> things... >> >> we provide our users with a tftp-server, that has a writeable directory >> for each stepping-stone-user. it is planned to allow the users to >> specify a config-snippet for the dhcpd (again, only for such system that >> the user has reserved in the db), when this is done there will be >> everything a user needs to boot any arbitary system on the device (if >> the device is netboot-enabled) >> >> hope that gives you some ideas, >> harald > > Hello Harald, > > This is a wonderful architecture, although I suspect it will take > me some time to get things together. I should like to start off > with a custom firewall. > > Currently we only have a single static IP, so I'll have to stick > to the four nic (2 DMZs) for now until we add some more > static/routable IPs. Give me a little time to get > organized. > > sincerely, > > James > Mike Frysinger wrote: > > On Friday 21 July 2006 17:03, Christopher Friedt wrote: >> >>Is there a published list of boards and their status for embedded gentoo? > > we dont support boards at the moment, just architectures > > getting a bsp up and running is left as an exercise for the end user ;) >> >>Would anyone be interested in polishing up a gentoo embedded port onto >> >>that platform with me? > > WRT54G ? that's mipsel right ? we've got mipsel/uclibc and mipsel/glibc > > running ... >> >>Has anyone published a list of minimum or suggested specs for devices in >> >>terms of ram / flash ? > > again, see previous comment ... > > as you can see, Gentoo/embedded is at the 'for developers' stage ... it could > > use a lot of work before being ready 'for users' and doing mini bsp releases > > for like the nslu2/wrt54g/what-have-you ... if you really feel like getting > > down and dirty, this is an area that is wide open at the moment ;) > > -mike Well, I agree, all of this is a good idea and 'wide open'. I'm in the process of customizing a firewall, with several DMZs to put up embedded systems for outside developers to access and control various mechanical and imaging systems. I have an old TS-5500, based on AMD 133 MHz 586 PCMCIA, which is available. Besides using an x86 for a baseline, as an intro SBC to embedded gentoo, would ease the transition from workstation/server gentoo to embedded gentoo. After folks get use to embedded gentoo on an x86 platform, then they can diverge into a second embedded platform (arm, mips, sh, blackfin, ppc)..... Softening the upward migration path to so that other can migrate to embedded gentoo contributors is a good idea. I'd be receptive to purchasing/hosting several systems in this (embedded)DMZ for folks to play with, especially if there is a 'turnkey' packaging where all I have to do is re-flash a SD/CF card, modify configs and boot up the system, in the event something goes wrong. There would also have to be an ACL (Access Control List) such that I could regulate who gets access to these boards. I could use some suggestions on iptables rules for this (embedded) DMZ. I have spoken to several folks in the past that have tried this, and maintaining security is always a challenge. So a limited ACL in the beginning until the security mechanisms mature, is a prudent step. thoughts? James -- gentoo-embedded@gentoo.org mailing list