> > problem with this - it will be sending user-related data over a tcp > > connection. This data COULD be sensitive configuration information and > > should be encrytped/tunneled. > > Yes, that's true. > > > it sounds like creating portmapper and portmapper has been an historic > > mess. > > It is much like portmapper. I'm not familiar with the historic mess > though I know what portmapper does - can you point me at docs on that, > or summarize? do a quick lookup on securityfocus of the number of security problems with portmapper. Additionally, the more services you have open on any given machine the increased likelihood that that service will be exploited in someway. If the client machine SOLELY acts as a client the world will be better off :) I guess what I'm saying is that a port-registering daemon is harder to write securely than a single daemon that doesn't need to juggle available ports. > Good point, this is the other possible design: that instead of > many-to-many connections (where each of N machines you log into can > have a connection to each of other machines), we have a one-to-many > connection, i.e. a single server and then all N machines you log into > connect to that one server. this helps a lot b/c I can do resource management based on how my server is handling the load. Additionally, If there is a config option I don't have to traipse all over the network looking for the flaky unit that has gconfd hung. > (Whether that server is an ACAP server specifically is another issue, > I think the answer is no because a) ACAP isn't exactly right for > config info, and since no one uses it there's no advantage of using a > standard anyway and b) we want to do things other than configuration > information.) Sounds ok to me. Stipulations on the server side could/should be: ssl/tls encryption no-X11/gtk/glib etc etc required to run it some sort of well-known-file-type backend (ie: dbm, sql, ldap or something - but something I can sift the information out of with normal tools if shit hits the fan) also something I can easily backup. - ldap might be a good option here. coordination with the kde-folks so that they use something similar (or ideally the same server) coordination with the ximian folks so that evo sticks its config information in the same place. > OK, despite I think bringing up the single-server/ACAP solution in > previous conversations, I had gotten in a brain rut the last few days > and forgotten about it. Let me restart my train of thought in that > direction and see if I can figure it out. ;-) yeah, you did mention it before. glad I could act as memory for you :) There are a lot of things that may work well on a smallish 4-10 system level but right now I've got 80-100ish linux workstations and the number doesn't seem like its going down. There are a lot of things in gnome that could be nicer for doing things on a network like this for more centralized control over configuration options but distributed installation of software. -sv
Attachment:
signature.asc
Description: This is a digitally signed message part