[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: xAP directory service/config/watchdog
- Subject: Re: xAP directory service/config/watchdog
- From: James <james@xxxxxxx>
- Date: Mon, 02 May 2005 13:51:46 +0100
- References:
<E1DR2pz-0008Hr-M8@canyon-city.rapidhoster.co.uk>
--------------000704070801090504020904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
>
>
>How wide spread is the sub-address problem in practice? Is it really
going
>to be that common an occurrence that every sub-address needs explicit,
>individual configuration? The only example I can think of is X10, where
each
>device needs to be provided with a "friendly name" such as
"lounge lamp".
The netiom is another example 16 inputs,16 outputs, 16 counters, and
so on. Even something simple like a tom10 would need 10 names, 10 low
levels and 10 high levels.
A full ldap tree of all devices where you can click on an item to
configure it or click on an OU and have all sub devices inherit that
setting does sound ideal. I'm just wondering how groups come in to
this kind of setup. If you had an OU called lights with a contain for
each light that would be simple. but what if one of those lights was a
member of a group? should that group also be an OU and the light
appear in both? or should the group simply appear as another container
which can have config applied to it. The latter seems more normal but
i wonder if it's the best here. The only other thing is to get a
very simple ldap system setup, however this works it needs to be
simple! OpenLdap is probably a good start.
>
> >I'll dig out
> >the doc that was made as it would be good to get this config
> >issue solved.
> >
> >On the watchdog/audit/monitoring app, one thing that will make it
hard
> >to really monitor things is that once xAP data goes through a hub
you
> >lose mac address and ip address information.Without these you
could
> >easily miss issues when multiple apps are running on identical
> >defaults. Stuart, is there any way of xFx passing this info
> >on somehow?
>
>
>Or fix this as part of the start up process? When an app starts it
>identifies itself to the directory server as best it can as it requests
its
>config data. The unique key data is platform specific (e.g. mac
address),
>but contains a sufficiently random element (e.g. process start time in
local
>clock ticks) that multiple instances can be correctly discovered. Where
>multiple instances are legitimately installed on the same device, they
can
>be distinguished by install time ("first instance" was
installed first,
>etc). This is enough to be able to deliver a UID from the directory
service
>on a fool proof basis. It only falls apart in the case where you have a
>device which supports multiple instances of xAP applications, but has
no
>non-volatile storage of its own - and I think we can live with that
>limitation?
Another advantage of tracking by network info (mac or ip) is it gives
some level of security as it can alert you if messages from a xAP
source come from different hardware. I know ip and mac can be spoofed
but it's a start! You above plan seems fine for the xAP side of things
and that final limitation i wouldn't of thought of being a problem.
J
--------------000704070801090504020904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<span style="white-space: pre;">><br>
><br>
>How wide spread is the sub-address problem in practice? Is it
really going<br>
>to be that common an occurrence that every sub-address needs
explicit,<br>
>individual configuration? The only example I can think of is X10,
where each<br>
>device needs to be provided with a "friendly name" such
as
"lounge lamp". </span><br>
<br>
The netiom is another example 16 inputs,16 outputs, 16 counters,
and<br>
so on. Even something simple like a tom10 would need 10 names, 10
low<br>
levels and 10 high levels.<br>
A full ldap tree of all devices where you can click on an item to<br>
configure it or click on an OU and have all sub devices inherit
that<br>
setting does sound ideal. I'm just wondering how groups come in
to<br>
this kind of setup. If you had an OU called lights with a contain
for<br>
each light that would be simple. but what if one of those lights was
a<br>
member of a group? should that group also be an OU and the light<br>
appear in both? or should the group simply appear as another
container<br>
which can have config applied to it. The latter seems more normal
but<br>
i wonder if it's the best here. The only other thing is to get
a<br>
very simple ldap system setup, however this works it needs to
be<br>
simple! OpenLdap is probably a good start.<br>
<br>
<span style="white-space: pre;">><br>
>>I'll dig out<br>
>>the doc that was made as it would be good to get this
config <br>
>>issue solved.<br>
>><br>
>>On the watchdog/audit/monitoring app, one thing that will
make it hard<br>
>>to really monitor things is that once xAP data goes through
a
hub you<br>
>>lose mac address and ip address information.Without these
you
could<br>
>>easily miss issues when multiple apps are running on
identical<br>
>>defaults. Stuart, is there any way of xFx passing this info
<br>
>>on somehow?<br>
><br>
><br>
>Or fix this as part of the start up process? When an app starts
it<br>
>identifies itself to the directory server as best it can as it
requests its<br>
>config data. The unique key data is platform specific (e.g. mac
address),<br>
>but contains a sufficiently random element (e.g. process start
time in local<br>
>clock ticks) that multiple instances can be correctly discovered.
Where<br>
>multiple instances are legitimately installed on the same device,
they can<br>
>be distinguished by install time ("first instance" was
installed
first,<br>
>etc). This is enough to be able to deliver a UID from the
directory service<br>
>on a fool proof basis. It only falls apart in the case where you
have a<br>
>device which supports multiple instances of xAP applications, but
has no<br>
>non-volatile storage of its own - and I think we can live with
that<br>
>limitation?</span><br>
<br>
Another advantage of tracking by network info (mac or ip) is it
gives<br>
some level of security as it can alert you if messages from a xAP<br>
source come from different hardware. I know ip and mac can be
spoofed<br>
but it's a start! You above plan seems fine for the xAP side of
things<br>
and that final limitation i wouldn't of thought of being a
problem.<br>
<br>
J<br>
<br>
<!-- **begin egp html banner** -->
<br>
<tt><hr width="500">
<b>Yahoo! Groups Links</b><br>
<ul>
<li>To visit your group on the web, go to:<br><a
href="http://groups.yahoo.com/group/xAP_developer/";>http://groups.yahoo.com/group/xAP_developer/</a><br>
<li>To unsubscribe from this group, send an email to:<br><a
href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>xAP_developer-unsubscribe@xxxxxxx</a><br>
<li>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/";>Yahoo!
Terms of Service</a>.
</ul>
</tt>
</br>
<!-- **end egp html banner** -->
</body>
</html>
--------------000704070801090504020904--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|