HECnet

hecnet@lists.dfupdate.se

15 participants
15568 discussions

Another sillyness. More information in the nodename database on MIM.

by mcguire＠neurotica.com

On 05/18/2013 12:45 PM, Johnny Billquist wrote: I like the idea of giving us all write access. Maybe you can set up regular dumps of the database for restoration in case someone screws up. I can certainly do that. It just becomes a question of people might need to reenter information in case a rollback has to go far. Also trickier to realize if "corruption" actually have happened perhaps. On the other hand, I could atleast have permissions that only allowed random people to modify data, not add new, nor delete. That's a really good idea. It would give some of us a chance to learn Datatrieve in a real-world scenario. I myself have never worked with it and would like to learn it; I learn best by doing. Indeed. Very true. Datatrieve is not that different from something like MySQL really. Different syntax, and some different capabilities (mostly more restricted), but otherwise not that strange. If you've ever played with such things. I've done a lot of database work, going back to Ingres and QUEL. I'm one of those weirdos who actually enjoys databases...I think most people find database work to be dry and boring, but I find it fascinating and stimulating. I've seen DTR applications used in production but have never had any exposure at all to the software...having something to actually *do* with it, like this node database for HECnet, is great stuff, and a great way to learn. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by bqt＠softjar.se

On 2013-05-18 18:45, Johnny Billquist wrote: On 2013-05-18 18:35, Dave McGuire wrote: On 05/18/2013 12:04 PM, Johnny Billquist wrote: Is there a way we can get write access to the db? That way we can keep our own info up to date. I was thinking about it. Pros and cons. Easier for updating. Potentially anyone erasing the whole thing. The granularity of permissions is by the whole table. It would perhaps be possible to do something that everyone had their own table, and then I'd just pull data from all of them for various tasks. But then I'd have potential name collision issues and what not... Actually, thinking a bit more, I could probably do some web interface with people having their own passwords and the ability to update just their data that way. Needs some thinking perhaps, but maybe the most doable. Anyone else have some ideas on how to do it? I like the idea of giving us all write access. Maybe you can set up regular dumps of the database for restoration in case someone screws up. I can certainly do that. It just becomes a question of people might need to reenter information in case a rollback has to go far. Also trickier to realize if "corruption" actually have happened perhaps. On the other hand, I could atleast have permissions that only allowed random people to modify data, not add new, nor delete. One thing I always like to have is some kind of uniformity. That is always harder to get with many people entering data. But I guess that can be addressed by having some explicit guidelines. Right now, the uniformity (as far as it goes) comes from just my head. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by b4＠gewt.net

On Sat, 18 May 2013, Dave McGuire wrote: On 05/18/2013 12:04 PM, Johnny Billquist wrote: Is there a way we can get write access to the db? That way we can keep our own info up to date. I was thinking about it. Pros and cons. Easier for updating. Potentially anyone erasing the whole thing. The granularity of permissions is by the whole table. It would perhaps be possible to do something that everyone had their own table, and then I'd just pull data from all of them for various tasks. But then I'd have potential name collision issues and what not... Actually, thinking a bit more, I could probably do some web interface with people having their own passwords and the ability to update just their data that way. Needs some thinking perhaps, but maybe the most doable. Anyone else have some ideas on how to do it? I like the idea of giving us all write access. Maybe you can set up regular dumps of the database for restoration in case someone screws up. It would give some of us a chance to learn Datatrieve in a real-world scenario. I myself have never worked with it and would like to learn it; I learn best by doing. I wouldn't mind learning Datatrieve either...I bet it'd beat MySQL for sure! -Dave -- Dave McGuire, AK4HZ New Kensington, PA -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by mcguire＠neurotica.com

Holy crap!! On 05/18/2013 11:06 AM, H Vlems wrote: A list of my systems: 44.1 HELIUM VAXstation 3100-M48 VMS 7.2 44.2 XENON VAXstation 4000-60 VMS 7.2 44.3 ARGON VAXstation 4000-90A VMS 7.3 44.4 NEON Asus Eee pc Fedora 14 44.5 ZILVER VAXstation 4000-60 VMS 7.3 44.6 JODIUM VAXstation 2000 VMS 5.5-1 44.7 RADON VAXstation 3100 VMS 5.5-1 44.8 ASTAAT DECserver 100 44.9 OSMIUM Digital Server 5305 5/533 VMS 8.3 44.10 CHLOOR VAXstation 4000-90A VMS 7.2 44.11 ZWAVEL microVAX 3100-10e VMS 6.1 44.12 INDIUM VXT2000+ 44.13 ERBIUM AlphaServer 800 5/500 Tru64 5.0 44.14 BROOM AlpaServer 1200 5/400 VMS 7.3-2 44.15 FOSFOR VAXstation 4000-60 VMS 7.3 44.16 COBALT VAXstation 4000-60 VMS 7.3 44.17 KOPER VAXstation 2000 VMS 5.5-1 44.18 CERIUM VAX 4000-100A VMS 7.3 44.19 IJZER Compaq XP1000 6/500 VMS 8.3 44.20 CHROOM VAX 4000-100A VMS 7.3 44.21 NIKKEL VAXstation 4000-90A VMS 7.3 44.22 ZINK VAXstation 4000 VLC VMS 7.3 44.23 LOOD microVAX 3100-30 VMS 7.3 44.24 CURIUM Multia VX42 4/233 VMS 7.3 44.25 KWIK VAXstation 4000-60 VMS 7.3 44.26 AURUM Integrity rx2600 VMS 8.4 44.27 RADIUM HP dc5000 sff Windows XP 44.28 TIN AlphaServer 1200 5/533 VMS 8.3 44.29 FLUOR AlphaServer 1000A 5/333 VMS 7.3-2 44.30 BOOR VAXstation 4000-60 VMS 7.1 44.31 SELEEN microVAX 3100-20e VMS 6.1 44.32 ARSEEN microVAX 3100-20e VMS 6.1 44.33 CARBON DEC AXP 3000-300X VMS 1.5-1H1 44.34 OXYGEN DEC AXP 3000-300X VMS 6.1 44.35 TITAAN AlphaServer DS20E 6/666 VMS 8.3 44.36 URAAN AlphaServer 1000A 5/333 VMS 8.3 44.37 BARIUM AlphaServer 1200 5/533 VMS 8.3 44.38 CESIUM Digital Server 5305 5/533 VMS 8.3 44.39 KALIUM AlphaServer 300 Tru64 5.1a 44.40 SODIUM Digital Server 5305 5/533 VMS 8.3 44.41 AZOTE <not in use> 44.42 VISMUT AlphaServer 800 5/333 Tru64 5.1a 44.43 OZON AlphaServer DS10 6/466 VMS 8.4 44.1023 A44RTR simh VAXserver 3900 VMS 6.1 -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by b4＠gewt.net

On Sat, 18 May 2013, Johnny Billquist wrote: On 2013-05-18 15:00, Brian Hechinger wrote: Is there a way we can get write access to the db? That way we can keep our own info up to date. I was thinking about it. Pros and cons. Easier for updating. Potentially anyone erasing the whole thing. The granularity of permissions is by the whole table. It would perhaps be possible to do something that everyone had their own table, and then I'd just pull data from all of them for various tasks. But then I'd have potential name collision issues and what not... Actually, thinking a bit more, I could probably do some web interface with people having their own passwords and the ability to update just their data that way. Needs some thinking perhaps, but maybe the most doable. Anyone else have some ideas on how to do it? You could do separate mini-dbs for each area that each person can modify. Johnny -brian On May 17, 2013, at 12:03, Johnny Billquist <bqt at softjar.se> wrote: On 2013-05-17 16:18, Bob Armstrong wrote: On 2013-05-16 18:28, Johnny Billquist wrote: This is a totally volontary thing. I've finally come to the point where I think that there are a few more pieces of data on nodes that would be nice/useful to have from time to time. Much of the information you want (all of it, I think) is already in the INFO.TXT file - $ type legato""::info.txt .... ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES 2.1 |LEGATO|Bob Armstrong |bob at jfcl.com |simh |OpenVMS 7.3|Milpitas, CA, US|DCN Multinet Ro uter 2.2 |POCO | | |MicroVAX-2000 | | |6MB, RD54, TK50 2.4 |MEZZO | | |PDP-11/53 |RSTS | |3.5MB, 2xRA73,TK70, SCSI 2.6 |LARGO | | |VAX-11/730 |VMS 4.7 | |R80, 2xRA81, RL02, RX02, TU80 2.7 |CODA | | |DS20E |OpenVMS 8.3| | 2.9 |DIVISI| | |VAX-8350 |VMS 5.5-2 | |16MB, RA81, RA82, TU81+ 2.10 |ADAGIO| | |VAXserver 3900 |VMS 6.0 | |RA81, RX50, 2xRD54, Kennedy 9610, RRD50, RF31, 2xRF71, RF72, SQ703, Exabyte 8505 2.11 |LENTO | | |PDP-11/73 |RSX-11M+ | |2xRD32, RX50, RL02, Kennedy 9600 2.12 |JENSEN| | |DEC 2000 axp |OpenVMS 7.3| | 2.13 |ZITI | | |eBox-3310 |Ubuntu | | 2.14 |MULTIA| | |Multia UDB |OpenVMS 7.3| | 2.15 |PAVANE| | |DECstation 3100 |Ultrix | |MIPS box w/DECnet-Ultrix 2.16 |SKETTI| | |HP ProLiant ML110G4 |Ubuntu | | 2.18 |DSRVB1| | |DECserver-200/MC | | | 2.19 |DSRVB2| | |DECserver-200/MC | | | FWIW, keeping a central database up to date is going to be a nightmare - that's why we invented the INFO.TXT files; so each sysadmin could locally update his own information. Yes. I know... :-) Which I said this is all voluntary and so on. I've just felt that the INFO.TXT is not really working that well either. At least not from my point of view. I'm willing to try different things. I could consider some automatic scraping and population of the nodename database from some distributed sources as well, if we can come up with something that seems reasonable. Oh, and thanks. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by bqt＠softjar.se

On 2013-05-18 18:35, Dave McGuire wrote: On 05/18/2013 12:04 PM, Johnny Billquist wrote: Is there a way we can get write access to the db? That way we can keep our own info up to date. I was thinking about it. Pros and cons. Easier for updating. Potentially anyone erasing the whole thing. The granularity of permissions is by the whole table. It would perhaps be possible to do something that everyone had their own table, and then I'd just pull data from all of them for various tasks. But then I'd have potential name collision issues and what not... Actually, thinking a bit more, I could probably do some web interface with people having their own passwords and the ability to update just their data that way. Needs some thinking perhaps, but maybe the most doable. Anyone else have some ideas on how to do it? I like the idea of giving us all write access. Maybe you can set up regular dumps of the database for restoration in case someone screws up. I can certainly do that. It just becomes a question of people might need to reenter information in case a rollback has to go far. Also trickier to realize if "corruption" actually have happened perhaps. On the other hand, I could atleast have permissions that only allowed random people to modify data, not add new, nor delete. It would give some of us a chance to learn Datatrieve in a real-world scenario. I myself have never worked with it and would like to learn it; I learn best by doing. Indeed. Very true. Datatrieve is not that different from something like MySQL really. Different syntax, and some different capabilities (mostly more restricted), but otherwise not that strange. If you've ever played with such things. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by b4＠gewt.net

On Sat, 18 May 2013, H Vlems wrote: A list of my systems: 44.1 HELIUM VAXstation 3100-M48 VMS 7.2 44.2 XENON VAXstation 4000-60 VMS 7.2 44.3 ARGON VAXstation 4000-90A VMS 7.3 44.4 NEON Asus Eee pc Fedora 14 44.5 ZILVER VAXstation 4000-60 VMS 7.3 44.6 JODIUM VAXstation 2000 VMS 5.5-1 44.7 RADON VAXstation 3100 VMS 5.5-1 44.8 ASTAAT DECserver 100 44.9 OSMIUM Digital Server 5305 5/533 VMS 8.3 44.10 CHLOOR VAXstation 4000-90A VMS 7.2 44.11 ZWAVEL microVAX 3100-10e VMS 6.1 44.12 INDIUM VXT2000+ 44.13 ERBIUM AlphaServer 800 5/500 Tru64 5.0 44.14 BROOM AlpaServer 1200 5/400 VMS 7.3-2 44.15 FOSFOR VAXstation 4000-60 VMS 7.3 44.16 COBALT VAXstation 4000-60 VMS 7.3 44.17 KOPER VAXstation 2000 VMS 5.5-1 44.18 CERIUM VAX 4000-100A VMS 7.3 44.19 IJZER Compaq XP1000 6/500 VMS 8.3 44.20 CHROOM VAX 4000-100A VMS 7.3 44.21 NIKKEL VAXstation 4000-90A VMS 7.3 44.22 ZINK VAXstation 4000 VLC VMS 7.3 44.23 LOOD microVAX 3100-30 VMS 7.3 44.24 CURIUM Multia VX42 4/233 VMS 7.3 44.25 KWIK VAXstation 4000-60 VMS 7.3 44.26 AURUM Integrity rx2600 VMS 8.4 44.27 RADIUM HP dc5000 sff Windows XP 44.28 TIN AlphaServer 1200 5/533 VMS 8.3 44.29 FLUOR AlphaServer 1000A 5/333 VMS 7.3-2 44.30 BOOR VAXstation 4000-60 VMS 7.1 44.31 SELEEN microVAX 3100-20e VMS 6.1 44.32 ARSEEN microVAX 3100-20e VMS 6.1 44.33 CARBON DEC AXP 3000-300X VMS 1.5-1H1 44.34 OXYGEN DEC AXP 3000-300X VMS 6.1 44.35 TITAAN AlphaServer DS20E 6/666 VMS 8.3 44.36 URAAN AlphaServer 1000A 5/333 VMS 8.3 44.37 BARIUM AlphaServer 1200 5/533 VMS 8.3 44.38 CESIUM Digital Server 5305 5/533 VMS 8.3 44.39 KALIUM AlphaServer 300 Tru64 5.1a 44.40 SODIUM Digital Server 5305 5/533 VMS 8.3 44.41 AZOTE <not in use> 44.42 VISMUT AlphaServer 800 5/333 Tru64 5.1a 44.43 OZON AlphaServer DS10 6/466 VMS 8.4 44.1023 A44RTR simh VAXserver 3900 VMS 6.1 Now that's quite a few systems! -----Oorspronkelijk bericht----- Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens Sampsa Laine Verzonden: zaterdag, mei 2013 16:00 Aan: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Another sillyness. More information in the nodename database on MIM. My boxes: London based boxes: 8.401 CHIMPY: DS10, OpenVMS 8.3 8.400 GORVAX: SIMH, OpenVMS 7.3 8.403 RHESUS: rx2600, OpenVMS 8.4E (also offers a variety of services, see http://rhesus.sampsa.com/) 47.100 HILANT Cluster in Hila, Finland, composed of: 47.556 KUHAVX SIMH running VMS 7.3 47.555 LABVAX - = - 47.727 SHAMS - = - 47.559 HPIVAX - = - (Raspberry Pi) 47.113 SIIRI MicroVAX 3400, VMS 7.3 47.700 K4VX1 VAXstation 4000/90, VMS 7.3 47.701 K4VX2 VAXstation 4000/60, VMS 7.3 On 17 May 2013, at 17:03, Johnny Billquist <bqt at softjar.se> wrote: On 2013-05-17 16:18, Bob Armstrong wrote: On 2013-05-16 18:28, Johnny Billquist wrote: This is a totally volontary thing. I've finally come to the point where I think that there are a few more pieces of data on nodes that would be nice/useful to have from time to time. Much of the information you want (all of it, I think) is already in the INFO.TXT file - $ type legato""::info.txt .... ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES 2.1 |LEGATO|Bob Armstrong |bob at jfcl.com |simh |OpenVMS 7.3|Milpitas, CA, US|DCN Multinet Ro uter 2.2 |POCO | | |MicroVAX-2000 | | |6MB, RD54, TK50 2.4 |MEZZO | | |PDP-11/53 |RSTS | |3.5MB, 2xRA73,TK70, SCSI 2.6 |LARGO | | |VAX-11/730 |VMS 4.7 | |R80, 2xRA81, RL02, RX02, TU80 2.7 |CODA | | |DS20E |OpenVMS 8.3| | 2.9 |DIVISI| | |VAX-8350 |VMS 5.5-2 | |16MB, RA81, RA82, TU81+ 2.10 |ADAGIO| | |VAXserver 3900 |VMS 6.0 | |RA81, RX50, 2xRD54, Kennedy 9610, RRD50, RF31, 2xRF71, RF72, SQ703, Exabyte 8505 2.11 |LENTO | | |PDP-11/73 |RSX-11M+ | |2xRD32, RX50, RL02, Kennedy 9600 2.12 |JENSEN| | |DEC 2000 axp |OpenVMS 7.3| | 2.13 |ZITI | | |eBox-3310 |Ubuntu | | 2.14 |MULTIA| | |Multia UDB |OpenVMS 7.3| | 2.15 |PAVANE| | |DECstation 3100 |Ultrix | |MIPS box w/DECnet-Ultrix 2.16 |SKETTI| | |HP ProLiant ML110G4 |Ubuntu | | 2.18 |DSRVB1| | |DECserver-200/MC | | | 2.19 |DSRVB2| | |DECserver-200/MC | | | FWIW, keeping a central database up to date is going to be a nightmare - that's why we invented the INFO.TXT files; so each sysadmin could locally update his own information. Yes. I know... :-) Which I said this is all voluntary and so on. I've just felt that the INFO.TXT is not really working that well either. At least not from my point of view. I'm willing to try different things. I could consider some automatic scraping and population of the nodename database from some distributed sources as well, if we can come up with something that seems reasonable. Oh, and thanks. Johnny -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by bqt＠softjar.se

On 2013-05-18 18:19, Ian McLaughlin wrote: Johnny, If you still keep ownership of adding new nodes to the system (a sane human gatekeeper has merits), then just allow people to edit their own area entries. That way a user can't accidentally remove a machine (or a whole bunch) - the worst that can happen is screwing up the meta data (machine type, OS, etc). Yeah, that would be ideal. The question only being how to implement it... Would people think a web interface would work? Or I could write a program running on MIM that people could use... Or I could possible scrape files in know locations to manage the updating, if that would make more sense. (The last one would probably be really easy from my point of view...) Johnny Ian On 2013-05-18, at 9:04 AM, Johnny Billquist <bqt at softjar.se> wrote: On 2013-05-18 15:00, Brian Hechinger wrote: Is there a way we can get write access to the db? That way we can keep our own info up to date. I was thinking about it. Pros and cons. Easier for updating. Potentially anyone erasing the whole thing. The granularity of permissions is by the whole table. It would perhaps be possible to do something that everyone had their own table, and then I'd just pull data from all of them for various tasks. But then I'd have potential name collision issues and what not... Actually, thinking a bit more, I could probably do some web interface with people having their own passwords and the ability to update just their data that way. Needs some thinking perhaps, but maybe the most doable. Anyone else have some ideas on how to do it? Johnny -brian On May 17, 2013, at 12:03, Johnny Billquist <bqt at softjar.se> wrote: On 2013-05-17 16:18, Bob Armstrong wrote: On 2013-05-16 18:28, Johnny Billquist wrote: This is a totally volontary thing. I've finally come to the point where I think that there are a few more pieces of data on nodes that would be nice/useful to have from time to time. Much of the information you want (all of it, I think) is already in the INFO.TXT file - $ type legato""::info.txt .... ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES 2.1 |LEGATO|Bob Armstrong |bob at jfcl.com |simh |OpenVMS 7.3|Milpitas, CA, US|DCN Multinet Ro uter 2.2 |POCO | | |MicroVAX-2000 | | |6MB, RD54, TK50 2.4 |MEZZO | | |PDP-11/53 |RSTS | |3.5MB, 2xRA73,TK70, SCSI 2.6 |LARGO | | |VAX-11/730 |VMS 4.7 | |R80, 2xRA81, RL02, RX02, TU80 2.7 |CODA | | |DS20E |OpenVMS 8.3| | 2.9 |DIVISI| | |VAX-8350 |VMS 5.5-2 | |16MB, RA81, RA82, TU81+ 2.10 |ADAGIO| | |VAXserver 3900 |VMS 6.0 | |RA81, RX50, 2xRD54, Kennedy 9610, RRD50, RF31, 2xRF71, RF72, SQ703, Exabyte 8505 2.11 |LENTO | | |PDP-11/73 |RSX-11M+ | |2xRD32, RX50, RL02, Kennedy 9600 2.12 |JENSEN| | |DEC 2000 axp |OpenVMS 7.3| | 2.13 |ZITI | | |eBox-3310 |Ubuntu | | 2.14 |MULTIA| | |Multia UDB |OpenVMS 7.3| | 2.15 |PAVANE| | |DECstation 3100 |Ultrix | |MIPS box w/DECnet-Ultrix 2.16 |SKETTI| | |HP ProLiant ML110G4 |Ubuntu | | 2.18 |DSRVB1| | |DECserver-200/MC | | | 2.19 |DSRVB2| | |DECserver-200/MC | | | FWIW, keeping a central database up to date is going to be a nightmare - that's why we invented the INFO.TXT files; so each sysadmin could locally update his own information. Yes. I know... :-) Which I said this is all voluntary and so on. I've just felt that the INFO.TXT is not really working that well either. At least not from my point of view. I'm willing to try different things. I could consider some automatic scraping and population of the nodename database from some distributed sources as well, if we can come up with something that seems reasonable. Oh, and thanks. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol --- Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=9E0D27F0BFD411E28… -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by mcguire＠neurotica.com

On 05/18/2013 12:04 PM, Johnny Billquist wrote: Is there a way we can get write access to the db? That way we can keep our own info up to date. I was thinking about it. Pros and cons. Easier for updating. Potentially anyone erasing the whole thing. The granularity of permissions is by the whole table. It would perhaps be possible to do something that everyone had their own table, and then I'd just pull data from all of them for various tasks. But then I'd have potential name collision issues and what not... Actually, thinking a bit more, I could probably do some web interface with people having their own passwords and the ability to update just their data that way. Needs some thinking perhaps, but maybe the most doable. Anyone else have some ideas on how to do it? I like the idea of giving us all write access. Maybe you can set up regular dumps of the database for restoration in case someone screws up. It would give some of us a chance to learn Datatrieve in a real-world scenario. I myself have never worked with it and would like to learn it; I learn best by doing. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 2 months

Another sillyness. More information in the nodename database on MIM.

by ian＠platinum.net

Johnny, If you still keep ownership of adding new nodes to the system (a sane human gatekeeper has merits), then just allow people to edit their own area entries. That way a user can't accidentally remove a machine (or a whole bunch) - the worst that can happen is screwing up the meta data (machine type, OS, etc). Ian On 2013-05-18, at 9:04 AM, Johnny Billquist <bqt at softjar.se> wrote: On 2013-05-18 15:00, Brian Hechinger wrote: Is there a way we can get write access to the db? That way we can keep our own info up to date. I was thinking about it. Pros and cons. Easier for updating. Potentially anyone erasing the whole thing. The granularity of permissions is by the whole table. It would perhaps be possible to do something that everyone had their own table, and then I'd just pull data from all of them for various tasks. But then I'd have potential name collision issues and what not... Actually, thinking a bit more, I could probably do some web interface with people having their own passwords and the ability to update just their data that way. Needs some thinking perhaps, but maybe the most doable. Anyone else have some ideas on how to do it? Johnny -brian On May 17, 2013, at 12:03, Johnny Billquist <bqt at softjar.se> wrote: On 2013-05-17 16:18, Bob Armstrong wrote: On 2013-05-16 18:28, Johnny Billquist wrote: This is a totally volontary thing. I've finally come to the point where I think that there are a few more pieces of data on nodes that would be nice/useful to have from time to time. Much of the information you want (all of it, I think) is already in the INFO.TXT file - $ type legato""::info.txt .... ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES 2.1 |LEGATO|Bob Armstrong |bob at jfcl.com |simh |OpenVMS 7.3|Milpitas, CA, US|DCN Multinet Ro uter 2.2 |POCO | | |MicroVAX-2000 | | |6MB, RD54, TK50 2.4 |MEZZO | | |PDP-11/53 |RSTS | |3.5MB, 2xRA73,TK70, SCSI 2.6 |LARGO | | |VAX-11/730 |VMS 4.7 | |R80, 2xRA81, RL02, RX02, TU80 2.7 |CODA | | |DS20E |OpenVMS 8.3| | 2.9 |DIVISI| | |VAX-8350 |VMS 5.5-2 | |16MB, RA81, RA82, TU81+ 2.10 |ADAGIO| | |VAXserver 3900 |VMS 6.0 | |RA81, RX50, 2xRD54, Kennedy 9610, RRD50, RF31, 2xRF71, RF72, SQ703, Exabyte 8505 2.11 |LENTO | | |PDP-11/73 |RSX-11M+ | |2xRD32, RX50, RL02, Kennedy 9600 2.12 |JENSEN| | |DEC 2000 axp |OpenVMS 7.3| | 2.13 |ZITI | | |eBox-3310 |Ubuntu | | 2.14 |MULTIA| | |Multia UDB |OpenVMS 7.3| | 2.15 |PAVANE| | |DECstation 3100 |Ultrix | |MIPS box w/DECnet-Ultrix 2.16 |SKETTI| | |HP ProLiant ML110G4 |Ubuntu | | 2.18 |DSRVB1| | |DECserver-200/MC | | | 2.19 |DSRVB2| | |DECserver-200/MC | | | FWIW, keeping a central database up to date is going to be a nightmare - that's why we invented the INFO.TXT files; so each sysadmin could locally update his own information. Yes. I know... :-) Which I said this is all voluntary and so on. I've just felt that the INFO.TXT is not really working that well either. At least not from my point of view. I'm willing to try different things. I could consider some automatic scraping and population of the nodename database from some distributed sources as well, if we can come up with something that seems reasonable. Oh, and thanks. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol --- Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=9E0D27F0BFD411E28…

12 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet