1 |
Hello Harald, Mike et al, |
2 |
|
3 |
I'm hearing excellent ideas here. My first conception was to just have |
4 |
individuals responsible for their various boards with collaboration on a |
5 |
common platform, but to have a terminal server for other gentoo-embedded |
6 |
developers is also a fantastic idea. This would facilitate svn firmware |
7 |
images / filesystems, etc. |
8 |
|
9 |
The reason I believe that gentoo would be a great choice for embedded |
10 |
linux is purely for 2 reasons: |
11 |
|
12 |
1) portage - an incredibly versatile solution to package management |
13 |
2) a highly 'emergant' user / developer / bugfix base |
14 |
|
15 |
Obviously the developers in gentoo-embedded would prefer to have portage |
16 |
as the primary (only) package management system for gentoo-embedded - |
17 |
that only makes logical sense. |
18 |
|
19 |
However, there is also an important underlying issue here - whether the |
20 |
embedded device is Gentoo-based, Debian-based, or RedHat-based, there is |
21 |
still a need for a standardized embedded device architecture both in |
22 |
software and hardware. |
23 |
|
24 |
Some related notes from my most recent Linux World Expo visit in Toronto: |
25 |
|
26 |
I have spoken to Bdale Garbee, CT Open Source & Linux for HP on a |
27 |
similar topic. I asked him if HP would be interested in supporting a |
28 |
sort of 'summer of embedded code' for embedded Linux. He mentioned that |
29 |
he and HP would be interested in 'facilitating' more research into |
30 |
embedded standards, both hardware and software, since HP uses Linux |
31 |
exclusively for most of their products that have a processor network |
32 |
device built into them (aside from the iPaq ... sigh). |
33 |
|
34 |
Another business card that I acquired was from Andrew Overholt at |
35 |
RedHat. He has helped out considerably with the CDT / Eclipse project. |
36 |
If anyone here has used Eclipse, I'm sure you would agree that it |
37 |
provides an excellent and freely available platform for code as well as |
38 |
management. My opinion is that the management side of something on |
39 |
this scale is almost as important as the code itself, and if that |
40 |
platform can be standardized for embedded developers the world would |
41 |
literally be our oyster. |
42 |
|
43 |
These two potentials could not only improve the state of embedded |
44 |
development but also prove reasonably profitable for all parties |
45 |
involved, including Gentoo, RedHat, and HP, besides all of the |
46 |
subsidiary companies who may be employing the technology. |
47 |
|
48 |
I've CC'd Bdale and Andrew on this. Responses and comments are very welcome. |
49 |
|
50 |
|
51 |
Cheers, |
52 |
|
53 |
~/Chris |
54 |
|
55 |
|
56 |
|
57 |
|
58 |
wireless wrote: |
59 |
> Harald Schioeberg wrote: |
60 |
>>> There would also have to be an ACL (Access Control List) such |
61 |
>>> that I could regulate who gets access to these boards. |
62 |
>>> I could use some suggestions on iptables rules for this |
63 |
>>> (embedded) DMZ. I have spoken to several folks in the past that |
64 |
>>> have tried this, and maintaining security is always a challenge. |
65 |
>>> So a limited ACL in the beginning until the security mechanisms |
66 |
>>> mature, is a prudent step. |
67 |
>> |
68 |
>> Hi, |
69 |
>> |
70 |
>> here comes my experience with a similar configuration (not developers |
71 |
>> but students with root-privileges, even worse :)) |
72 |
>> |
73 |
>> a stepping-stone host with ssh-logins for outside devs. this is the only |
74 |
>> system, that accepts connections from outside, the firewall blocks any |
75 |
>> attempt to connect to any embedded system directly. we even have our |
76 |
>> devices in a network with private ip-addresses, with no routing at all |
77 |
>> to or from the internet, the steppingstone has 2 nics, one with a public |
78 |
>> IP for ssh-login, and one with the private ip. it does NOT do any |
79 |
>> routing or NAT. the private IP-config will probably not work for you, |
80 |
>> because: |
81 |
>> |
82 |
>> the dev systems probably need outgoing http/ftp/rsync if not more. block |
83 |
>> smtp at all costs. if you need mail for debugging the embedded systems, |
84 |
>> configure your stepping-stone so that it accepts mails for your |
85 |
>> dns-zone, and delivers it locally, but do not forward any mail from the |
86 |
>> dev-dmz. if you only want to support one system (say gentoo) you might |
87 |
>> get along with a local gentoo-mirror, but development is really |
88 |
>> cumbersome if people don't have http/ftp access do download some patches |
89 |
>> or whatever. people will start to build ssh-portforwards if you are too |
90 |
>> restrictive and that kills any firewall. |
91 |
>> |
92 |
>> you need ip-switchable powersupply for all dev-systems, these things |
93 |
>> will crash and the users need a way to reboot them remotly. |
94 |
>> (afair ~300 Euro per 8 devices) |
95 |
>> see that you get some with snmp support, then you can write a small tool |
96 |
>> that checks against the acl before it reboots the device. |
97 |
>> |
98 |
>> you need a serial connection to each dev-system. we use terminal-servers |
99 |
>> for that purpose. make sure you can break a serial login, users will |
100 |
>> forget to log out and block the serial port forever. again, see for snmp |
101 |
>> support for that purpose. |
102 |
>> (terminal-servers are really expensive, about 150 Euro per port, but you |
103 |
>> can use a pc with lots of ports, and use a serial-to-network daemon) |
104 |
>> |
105 |
>> if multiple devs should be able to share a device, you need some kind of |
106 |
>> a reservation system. We started with a wiki, where everyone entered the |
107 |
>> devices that he wants to book in a table. that worked amazingly well. |
108 |
>> now we have switched to a sql-db, with allows us to restrict the logins |
109 |
>> on the devices to that devices, that the user has actually reserved. the |
110 |
>> most important thing is that never 2 independant users access the device |
111 |
>> at the same time if they want to do things like system configuration |
112 |
>> things... |
113 |
>> |
114 |
>> we provide our users with a tftp-server, that has a writeable directory |
115 |
>> for each stepping-stone-user. it is planned to allow the users to |
116 |
>> specify a config-snippet for the dhcpd (again, only for such system that |
117 |
>> the user has reserved in the db), when this is done there will be |
118 |
>> everything a user needs to boot any arbitary system on the device (if |
119 |
>> the device is netboot-enabled) |
120 |
>> |
121 |
>> hope that gives you some ideas, |
122 |
>> harald |
123 |
> |
124 |
> Hello Harald, |
125 |
> |
126 |
> This is a wonderful architecture, although I suspect it will take |
127 |
> me some time to get things together. I should like to start off |
128 |
> with a custom firewall. |
129 |
> |
130 |
> Currently we only have a single static IP, so I'll have to stick |
131 |
> to the four nic (2 DMZs) for now until we add some more |
132 |
> static/routable IPs. Give me a little time to get |
133 |
> organized. |
134 |
> |
135 |
> sincerely, |
136 |
> |
137 |
> James |
138 |
> |
139 |
|
140 |
Mike Frysinger wrote: |
141 |
> > On Friday 21 July 2006 17:03, Christopher Friedt wrote: |
142 |
>> >>Is there a published list of boards and their status for embedded |
143 |
gentoo? |
144 |
|
145 |
> > we dont support boards at the moment, just architectures |
146 |
> > getting a bsp up and running is left as an exercise for the end |
147 |
user ;) |
148 |
|
149 |
>> >>Would anyone be interested in polishing up a gentoo embedded port onto |
150 |
>> >>that platform with me? |
151 |
|
152 |
> > WRT54G ? that's mipsel right ? we've got mipsel/uclibc and |
153 |
mipsel/glibc |
154 |
> > running ... |
155 |
|
156 |
>> >>Has anyone published a list of minimum or suggested specs for |
157 |
devices in |
158 |
>> >>terms of ram / flash ? |
159 |
|
160 |
> > again, see previous comment ... |
161 |
|
162 |
> > as you can see, Gentoo/embedded is at the 'for developers' stage |
163 |
... it could |
164 |
> > use a lot of work before being ready 'for users' and doing mini bsp |
165 |
releases |
166 |
> > for like the nslu2/wrt54g/what-have-you ... if you really feel like |
167 |
getting |
168 |
> > down and dirty, this is an area that is wide open at the moment ;) |
169 |
> > -mike |
170 |
|
171 |
|
172 |
Well, I agree, all of this is a good idea and 'wide open'. I'm in |
173 |
the process of customizing a firewall, with several DMZs to put |
174 |
up embedded systems for outside developers to access and control |
175 |
various mechanical and imaging systems. |
176 |
|
177 |
I have an old TS-5500, based on AMD 133 MHz 586 PCMCIA, which |
178 |
is available. Besides using an x86 for a baseline, as an intro |
179 |
SBC to embedded gentoo, would ease the transition from |
180 |
workstation/server gentoo to embedded gentoo. After folks get use |
181 |
to embedded gentoo on an x86 platform, then they can diverge into |
182 |
a second embedded platform (arm, mips, sh, blackfin, ppc)..... |
183 |
Softening the upward migration path to so that other can |
184 |
migrate to embedded gentoo contributors is a good idea. |
185 |
|
186 |
I'd be receptive to purchasing/hosting several systems in this |
187 |
(embedded)DMZ for folks to play with, especially if there is a |
188 |
'turnkey' packaging where all I have to do is re-flash a SD/CF |
189 |
card, modify configs and boot up the system, in the event |
190 |
something goes wrong. |
191 |
|
192 |
There would also have to be an ACL (Access Control List) such |
193 |
that I could regulate who gets access to these boards. |
194 |
I could use some suggestions on iptables rules for this |
195 |
(embedded) DMZ. I have spoken to several folks in the past that |
196 |
have tried this, and maintaining security is always a challenge. |
197 |
So a limited ACL in the beginning until the security mechanisms |
198 |
mature, is a prudent step. |
199 |
|
200 |
|
201 |
thoughts? |
202 |
|
203 |
James |
204 |
|
205 |
|
206 |
-- |
207 |
gentoo-embedded@g.o mailing list |