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…