From (spam-protected) Tue Dec 1 00:20:12 2009 From: (spam-protected) (Mitar) Date: Tue, 01 Dec 2009 00:20:12 +0100 Subject: [Nodedb-interop] changed summary text of our group In-Reply-To: <081D2FE6-4865-4986-A71D-945F57A26438@lo-res.org> References: <081D2FE6-4865-4986-A71D-945F57A26438@lo-res.org> Message-ID: <4B14532C.50706@tnode.com> Hi! Shouldn't why maybe extend this also to interoperability of IP ranges we use? To maybe not just define a "RFC" but also a small page where to present this (after we could work there on this), which could be used also for IP allocations and other common documentation? I would like to see common node schema only as a start. > The request is encoded in a HTTP GET string (urlencoded) and the > answer is a HTTP "name: value" pair. I can give some samples if > needed. Yes, please. Mitar From (spam-protected) Tue Dec 1 00:26:37 2009 From: (spam-protected) (L. Aaron Kaplan) Date: Tue, 1 Dec 2009 00:26:37 +0100 Subject: [Nodedb-interop] changed summary text of our group In-Reply-To: <4B14532C.50706@tnode.com> References: <081D2FE6-4865-4986-A71D-945F57A26438@lo-res.org> <4B14532C.50706@tnode.com> Message-ID: <18785D98-CC0A-4B63-97E8-4C92E221A3E4@lo-res.org> On Dec 1, 2009, at 12:20 AM, Mitar wrote: > Hi! > > Shouldn't why maybe extend this also to interoperability of IP ranges we > use? To maybe not just define a "RFC" but also a small page where to > present this (after we could work there on this), which could be used > also for IP allocations and other common documentation? > > I would like to see common node schema only as a start. that is fine with me... we can use this list for any interoperability issues that we have. I agree , discussion of IP address ranges is 100% on topic. Do you want to provide a wiki? In case there is the need for it, Funkfeuer Vienna can theoretically help you to get PI space. At least we can try. You should just be clear about the recurring financial costs to RIPE. But on the other hand: public IPs are the natural way of doing peering agreements. > >> The request is encoded in a HTTP GET string (urlencoded) and the >> answer is a HTTP "name: value" pair. I can give some samples if >> needed. > > Yes, please. > ok, I will search for an example. > > Mitar > From (spam-protected) Tue Dec 1 11:46:28 2009 From: (spam-protected) (Mitar) Date: Tue, 01 Dec 2009 11:46:28 +0100 Subject: [Nodedb-interop] changed summary text of our group In-Reply-To: <18785D98-CC0A-4B63-97E8-4C92E221A3E4@lo-res.org> References: <081D2FE6-4865-4986-A71D-945F57A26438@lo-res.org> <4B14532C.50706@tnode.com> <18785D98-CC0A-4B63-97E8-4C92E221A3E4@lo-res.org> Message-ID: <4B14F404.60409@tnode.com> Hi! > Do you want to provide a wiki? We can. Do you think that we should setup a new wiki/page which would be dedicated to this or just make some it under our current wiki? I think the first way would be better as it can be easier expanded with other things. > In case there is the need for it, Funkfeuer Vienna can theoretically > help you to get PI space. At least we can try. You should just be > clear about the recurring financial costs to RIPE. But on the other > hand: public IPs are the natural way of doing peering agreements. At least for us we would currently stick to private IPs for IPv4. Later on we will probably move to IPv6 mesh and then we would probably like to have official/registered IPv6 addresses. I also think it would be useful to cooperate with guifi.net on this, as they are also going in this direction of being possible to provide public IP space and similar. So you both could become smaller wifi networks' windows to RIPE. But for now I think it is important to document this. So IP ranges everybody is using for example. Maybe even setup a allocation system or use an existing one (like guifi.net's). Mitar From (spam-protected) Tue Dec 1 12:24:00 2009 From: (spam-protected) (L. Aaron Kaplan) Date: Tue, 1 Dec 2009 12:24:00 +0100 Subject: [Nodedb-interop] changed summary text of our group In-Reply-To: <4B14F404.60409@tnode.com> References: <081D2FE6-4865-4986-A71D-945F57A26438@lo-res.org> <4B14532C.50706@tnode.com> <18785D98-CC0A-4B63-97E8-4C92E221A3E4@lo-res.org> <4B14F404.60409@tnode.com> Message-ID: <23DF1114-9B85-4623-8ADA-22DEDE1DFAC6@lo-res.org> On Dec 1, 2009, at 11:46 AM, Mitar wrote: > Hi! > >> Do you want to provide a wiki? > > We can. Do you think that we should setup a new wiki/page which would be > dedicated to this or just make some it under our current wiki? I think > the first way would be better as it can be easier expanded with other > things. however you wish :) > >> In case there is the need for it, Funkfeuer Vienna can theoretically >> help you to get PI space. At least we can try. You should just be >> clear about the recurring financial costs to RIPE. But on the other >> hand: public IPs are the natural way of doing peering agreements. > > At least for us we would currently stick to private IPs for IPv4. Later > on we will probably move to IPv6 mesh and then we would probably like to > have official/registered IPv6 addresses. ok, well.... also Funkfeuer has a /32 v6 space... so there is plenty of this. I think we can share some in case you need :)) > > I also think it would be useful to cooperate with guifi.net on this, as > they are also going in this direction of being possible to provide > public IP space and similar. So you both could become smaller wifi > networks' windows to RIPE. Yes, we could help the community Wi-Fi networks in this respect. Well, we know already that the main problem for small community Wi-Fi networks to get public v4 (and also v6 space) is the problem that the RIPE membership costs easily 2000,- year. As said above, I see no reason why we can not share some part of our v6 space with other community Wi-Fi networks without the high costs of RIPE membership (some sharing of the common financial burden us generally a good tone within our community - and this also lowers costs for everybody ). The other question of course would be if the community Wi-Fi network can get v6 upstream access (and v6 BGP peering ). > > But for now I think it is important to document this. So IP ranges > everybody is using for example. OK, here is a simple table (which can be copied to a wiki and eventually end up in a DB :) Network name | Country | City | point of contact | peering points | AS (if available) | IP Ranges (separated by ";") Funkfeuer Vienna | Austria | Vienna | admin at funkfeuer.at | VIX | AS35492 | 78.41.112.0/21; 193.238.156.0/22 ... insert yours :) a. From (spam-protected) Mon Dec 7 12:17:41 2009 From: (spam-protected) (:k) Date: Mon, 07 Dec 2009 12:17:41 +0100 Subject: [Nodedb-interop] changed summary text of our group In-Reply-To: <18785D98-CC0A-4B63-97E8-4C92E221A3E4@lo-res.org> References: <081D2FE6-4865-4986-A71D-945F57A26438@lo-res.org> <4B14532C.50706@tnode.com> <18785D98-CC0A-4B63-97E8-4C92E221A3E4@lo-res.org> Message-ID: <1260184661.4518.35.camel@rikk> Hi, do I get it right, that we are talking about a serverside app, which lets communities enter their credentials and automated systems (like firmware builders) just get that ptofile as simple key:value pairs? I'd suggest some code using couchdb or mongodb. If enough time we can have possibly something up til the congress. Or is this the place for discussing the IP scheme itself? thanx for clearance, kloschi -- You don’t have to burn books to destroy a culture. Just get people to stop reading them. ” — Ray Bradbury -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part URL: From (spam-protected) Mon Dec 7 13:45:39 2009 From: (spam-protected) (L. Aaron Kaplan) Date: Mon, 7 Dec 2009 13:45:39 +0100 Subject: [Nodedb-interop] why this list? goals and visions References: <789642C3-A611-4C6B-98B1-1603CB560B32@lo-res.org> Message-ID: sorry, this went out to klosch only. Wanted to reply-all ;-)) a. Begin forwarded message: > From: "L. Aaron Kaplan" > Date: December 7, 2009 12:20:23 PM GMT+01:00 > To: :k > Subject: Re: [Nodedb-interop] changed summary text of our group > > Hi ! > > Ok, a biref summary what started this list... > Ramon, Mitar, Joseph, Socrates and a few others (sorry if I dont remember every name now who was standig there at this moment) > were in Rome and we decided that it would be good to have some kind of common "language" between the node DBs. > The reasoning is that we could develop apps and services which could work on any of our community Wi-Fi networks. > > At this time Mitar presented their very interesting and good Lubljana node DB. > However, both Vienna, Athens and the Catalan network already have node DBs and it is hard to simply throw it away and use a new one. > > So Ramon had a suggestion some months ago already to define a common XML schema or something similar which can help us to have a common format. The idea being that if someone programs for that format, people can provide the data this way. > > So you see , we are just at the beginning of this idea and it would be good if everyone here can explain the structure node DBs to each other as a start. > ( I will post ours soon, (not the data, just the strucuture hehe) ). > > > > But of course , for this list , anything which lets our networks "talk" to each other is on topic. > See this mailing list as the "interoperability working group" :) > > best, > a. > > > > On Dec 7, 2009, at 12:05 PM, :k wrote: > >> Hi, >> >> do I get it right, that we are talking about a serverside app, which >> lets communities enter their credentials and automated systems (like >> firmware builders) just get that ptofile as simple key:value pairs? >> >> I'd suggest some code using couchdb or mongodb. If enough time we can >> have possibly something up til the congress. >> >> Or is this the place for discussing the IP scheme itself? >> >> >> thanx for clearance, >> kloschi >> >> >> >> >> >> -- >> You don’t have to burn books to destroy a culture. Just get people to >> stop reading them. ” >> — Ray Bradbury > From (spam-protected) Mon Dec 7 13:59:14 2009 From: (spam-protected) (L. Aaron Kaplan) Date: Mon, 7 Dec 2009 13:59:14 +0100 Subject: [Nodedb-interop] why this list? goals and visions In-Reply-To: References: <789642C3-A611-4C6B-98B1-1603CB560B32@lo-res.org> Message-ID: <24A4A745-5A94-4A64-B54F-77FE2F7099E8@lo-res.org> So here is the current funkfeuer DB (nicknamed "redeemer"). It was programmed and designed by Wolfgang Nagele (some of you might know him). It was a very quick and fast implementation which has a few key strengths: * it can generate DNS zone files * it can generate Asterisk VOIP config files based on the members tables * it can generate track when which IP as last pingable * it can generate smokeping entries * we have an internal whois service which connects to the DB * our map (map.funkfeuer.at/wien) connects to the DB and can display the status of each node However now after a few years we have a few more needs: * we use public IPs and in v4 world these are limited. So we need to keep track of the who "hordes" v4 IPs and must have a way to get them back and re-distribute them to new nodes * better network mgmt and planning: link calculations and planning algos are needed. We would like to be able to send mails to people with recommendations on which link would benefit them. Imagine a radio engineer expert system consulting you. Ok, I know this is far fetched... but working on it. *.... (many more needs) These needs will be addressed by a future version of our node DB. For now we have the following structure: ### All tables.... redeemer_wien=# \dt List of relations Schema | Name | Type | Owner --------+-----------------+-------+------------------- public | devices | table | redeemer.frontend public | ips | table | redeemer.frontend public | members | table | redeemer.frontend public | members_roles | table | redeemer.frontend public | nodes | table | redeemer.frontend public | roles | table | redeemer.frontend public | voip_extensions | table | redeemer.frontend public | voip_sip | table | redeemer.frontend (8 rows) ##### some tables in detail redeemer_wien=# \d members Table "public.members" Column | Type | Modifiers ------------------------+--------------------------+----------- id | bigint | not null nickname | character varying(100) | not null password | character varying(255) | not null firstname | character varying(50) | lastname | character varying(50) | street | character varying(255) | housenumber | character varying(10) | zip | character varying(10) | town | character varying(255) | telephone | character varying(25) | mobilephone | character varying(25) | fax | character varying(25) | email | character varying(50) | homepage | character varying(50) | created | timestamp with time zone | changed | timestamp with time zone | redeemer_wien=# \d nodes Table "public.nodes" Column | Type | Modifiers -------------+--------------------------+----------------------- id | bigint | not null name | character varying(250) | not null gps_lat_deg | double precision | gps_lat_min | double precision | gps_lat_sec | double precision | gps_lon_deg | double precision | gps_lon_min | double precision | gps_lon_sec | double precision | map | boolean | not null default true id_members | bigint | not null created | timestamp with time zone | changed | timestamp with time zone | redeemer_wien=# \d devices Table "public.devices" Column | Type | Modifiers ------------------+-----------------------------+------------------------ id | bigint | not null name | character varying(100) | not null antenna | character varying(255) | hardware | character varying(255) | ssid | character varying(255) | mac | character varying(17) | smokeping | boolean | not null default true last_seen | timestamp without time zone | id_nodes | bigint | id_members | bigint | created | timestamp with time zone | changed | timestamp with time zone | delete_mail | timestamp without time zone | delete_protected | boolean | not null default false comment | character varying(8000) | redeemer_wien=# \d ips Table "public.ips" Column | Type | Modifiers ----------------+------------------------+----------- id | bigint | not null ip | character varying(15) | not null cidr | character varying(2) | not null usage | character varying(100) | not null dns_forward | boolean | not null custom_forward | character varying(100) | dns_reverse | boolean | not null custom_reverse | character varying(100) | id_devices | bigint | id_members | bigint | id_nodes | bigint | redeemer_wien=# select * from roles; id | name ----+------------- 1 | Admin 2 | Map 3 | Club Member 4 | Mentor (4 rows) I hope I could give you an impression.