Re: Gotta start somewhere ... how many of us are really out there?
On 3/08/2006 2:25 PM, User Freebsd wrote: b. Duplicates. Ted seems to have this covered with the CPU ID thing ... Isn't this one of those things that BIOS vendors added a Disable flag to their BIOS setup's for in order to prevent the wide-spread privacy concerns that cropped up when it was first released? I'm fairly sure this is disabled on most of the systems I've built... The token-based system mentioned by Mikhail Goriachev sounded interesting, although I haven't done any further thinking past what was originally mentioned... c. Fakery. IMHO, not a *really* big issue ... I could see someone bothering to do it once or twice, but seems to be alot of work for little gain ... Agreed... I could probably add around 1,500 systems that could conceivably be setup to chime in with their numbers periodically; one of the pre-requisites for that would be that the access method be HTTP or HTTPS based so it could be relayed via a proxy... Another nice thing to include might be a hash of hardware inventory (a further opt-in thing beyond the basic checkins)... Mark alluded to this early in the piece, but it would be nice to be able to pull up something that said hang on, out of the X% of users on file, Y% are using Adaptec SCSI cards, in particular model XYZ... this would be very helpful when trying to get vendor support etc... Some form of hash calculated on these would allow you to detect if they had changed at all, and only re-send them in the event of a change... ... just thinking out loud ... ! -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Thu, 3 Aug 2006, Antony Mawer wrote: Agreed... I could probably add around 1,500 systems that could conceivably be setup to chime in with their numbers periodically; one of the pre-requisites for that would be that the access method be HTTP or HTTPS based so it could be relayed via a proxy... Another nice thing to include might be a hash of hardware inventory (a further opt-in thing beyond the basic checkins)... Mark alluded to this early in the piece, but it would be nice to be able to pull up something that said hang on, out of the X% of users on file, Y% are using Adaptec SCSI cards, in particular model XYZ... this would be very helpful when trying to get vendor support etc... Some form of hash calculated on these would allow you to detect if they had changed at all, and only re-send them in the event of a change... ... just thinking out loud ... ! 'k, so, how do we script this then? Getting a list of devices is actually pretty easy, and I've tried this on my 4.x machines also, so it isn't something that will be a problem on older versions: # pciconf -l [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x700d1022 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:7:0: class=0x060100 card=0x chip=0x74401022 rev=0x05 hdr=0x00 [EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:7:3: class=0x068000 card=0x74431022 chip=0x74431022 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:9:0: class=0x010400 card=0xc0351044 chip=0xa5111044 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:11:0:class=0x02 card=0x10018086 chip=0x100f8086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:16:0:class=0x060400 card=0x chip=0x74481022 rev=0x05 hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x0c0310 card=0x74491022 chip=0x74491022 rev=0x07 hdr=0x00 [EMAIL PROTECTED]:7:0: class=0x03 card=0x80081002 chip=0x47521002 rev=0x27 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x02 card=0x10408086 chip=0x12298086 rev=0x10 hdr=0x00 And, more specifically, we can get: # pciconf -l -v [EMAIL PROTECTED]:9:0: class=0x010400 card=0xc0351044 chip=0xa5111044 rev=0x01 hdr=0x00 vendor = 'Adaptec (Formerly: Distributed Processing Technology (DPT))' device = 'Raptor SmartRAID Controller' class= mass storage subclass = RAID So, with that one command, we can get a fair amount of hardware information ... but, how to feed that into a proper HTTP request? Storing all of that information would be cool, cause then we could build reports based on device driver / vendor / device / class and subclass ... but that might be a bit heavy to do in an HTTP request, no? I take it email isn't an option, in your case? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
--- User Freebsd [EMAIL PROTECTED] wrote: On Thu, 3 Aug 2006, Antony Mawer wrote: Agreed... I could probably add around 1,500 systems that could conceivably be setup to chime in with their numbers periodically; one of the pre-requisites for that would be that the access method be HTTP or HTTPS based so it could be relayed via a proxy... Another nice thing to include might be a hash of hardware inventory (a further opt-in thing beyond the basic checkins)... Mark alluded to this early in the piece, but it would be nice to be able to pull up something that said hang on, out of the X% of users on file, Y% are using Adaptec SCSI cards, in particular model XYZ... this would be very helpful when trying to get vendor support etc... Some form of hash calculated on these would allow you to detect if they had changed at all, and only re-send them in the event of a change... ... just thinking out loud ... ! 'k, so, how do we script this then? Getting a list of devices is actually pretty easy, and I've tried this on my 4.x machines also, so it isn't something that will be a problem on older versions: # pciconf -l [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x700d1022 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:7:0: class=0x060100 card=0x chip=0x74401022 rev=0x05 hdr=0x00 [EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:7:3: class=0x068000 card=0x74431022 chip=0x74431022 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:9:0: class=0x010400 card=0xc0351044 chip=0xa5111044 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:11:0:class=0x02 card=0x10018086 chip=0x100f8086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:16:0:class=0x060400 card=0x chip=0x74481022 rev=0x05 hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x0c0310 card=0x74491022 chip=0x74491022 rev=0x07 hdr=0x00 [EMAIL PROTECTED]:7:0: class=0x03 card=0x80081002 chip=0x47521002 rev=0x27 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x02 card=0x10408086 chip=0x12298086 rev=0x10 hdr=0x00 And, more specifically, we can get: # pciconf -l -v [EMAIL PROTECTED]:9:0: class=0x010400 card=0xc0351044 chip=0xa5111044 rev=0x01 hdr=0x00 vendor = 'Adaptec (Formerly: Distributed Processing Technology (DPT))' device = 'Raptor SmartRAID Controller' class= mass storage subclass = RAID So, with that one command, we can get a fair amount of hardware information ... but, how to feed that into a proper HTTP request? Storing all of that information would be cool, cause then we could build reports based on device driver / vendor / device / class and subclass ... but that might be a bit heavy to do in an HTTP request, no? I take it email isn't an option, in your case? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.org ICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] maybe it's just because I've been reading up on it but what about outputting the information in XML??? Then you could tag the Vendor, Name, basic info, number of users, etc. in a tagged form that could be then stored in a Dbase of some kind by vendor, working in FreeBSD X.Y, broken, etc. The XML should be easily outputted on the fly to XHTML so it can be reviewed by devolopers and what not. Just my too cents... definately thinking out loud -brian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Thu, 3 Aug 2006, [EMAIL PROTECTED] wrote: maybe it's just because I've been reading up on it but what about outputting the information in XML??? Then you could tag the Vendor, Name, basic info, number of users, etc. in a tagged form that could be then stored in a Dbase of some kind by vendor, working in FreeBSD X.Y, broken, etc. The XML should be easily outputted on the fly to XHTML so it can be reviewed by devolopers and what not. Just my too cents... 'k, right now, we are trying to get the data from the remote clients to a central server ... if you are thinking of using XML for this (not against it, I just know nothing about it), can you provide an example of what you are thinking, and how we'd script this to use HTTP to connect to the remote server? The hard part of all of this is that it cannot require *anything* except for the base system, so no php, no perl ... just pure shell commands ... it cannot require an administrator to install anything above the script itself ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
--- User Freebsd [EMAIL PROTECTED] wrote: On Thu, 3 Aug 2006, [EMAIL PROTECTED] wrote: maybe it's just because I've been reading up on it but what about outputting the information in XML??? Then you could tag the Vendor, Name, basic info, number of users, etc. in a tagged form that could be then stored in a Dbase of some kind by vendor, working in FreeBSD X.Y, broken, etc. The XML should be easily outputted on the fly to XHTML so it can be reviewed by devolopers and what not. Just my too cents... 'k, right now, we are trying to get the data from the remote clients to a central server ... if you are thinking of using XML for this (not against it, I just know nothing about it), can you provide an example of what you are thinking, and how we'd script this to use HTTP to connect to the remote server? The hard part of all of this is that it cannot require *anything* except for the base system, so no php, no perl ... just pure shell commands ... it cannot require an administrator to install anything above the script itself ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.org ICQ . 7615664 ok well I'm not much of a C programmer right now so I'll give you waht I think in psuedo-psuedo-psuedo-code write a small program that shell calls pciconf -lv and outputs this to a temporary file or buffers to memory. Then use maybe a tr (translate I think its tr, never really used the command) to change things like Vendor: foobar in the pciconf -lv output to vendorVendor: foorbar/vendor hardware Hardware: RAID controller /hardware or whatever XML tags you want to use using the acutal output data from pciconf -lv as a starting point take this tagged file and insert it into a properly defined XML file with the header defined and a proper root tag like [standard XML header info, may be system specific based on encoding and what not] server_information_(insert the output of uname -a here for completeness) output of the tr stuff could prolly be catted into this after the header is defined. /Server_information_`uname -a` making tr work line by line with exception handling for all the tags it might encounter is something I would have to look into more myself. Then you could write up a CSS or XSLT stylesheet so it will display this information to a webbrowser however your want. Once you have figured out what tags you want to use this shouldn't be too hard. I guess a script file would be the easiest way to accompish all this in hindsight,as all the commands I've used are standard shell commands. Putting it all together is going to take more thought then what I can give it at work right now. The stylesheet could be stored on a central server of your choosing and added to the header for the XML that the script file generates. If this is still not very understandable I will see if I can generate a shell program to get things started. myunderstanding is once the shell is installed it should be runable by anyone with access to pciconf, tr, cat, and maybe a few other commands like date and whatnot for documentation sake; which means any user should be able to run and install the script in their home/bin directory. As far as uploading this file to a database that is beyond the scope of my feable mind, but I don't think it would be too hard to accomplish if someone was more familiar with db or whatever other database you want to store this by. hope this gives you more of an idea as to what I was getting at, hopefully there will be more to come if I figure this thing out; I need to learn how to process XML for a little project I'm working on for a friend anyway. The good thing about this is once in XML I know there are stardard ways of serving the XML file with a webserver for display. What I don't know is how to make it searchable or concatenate all the hardware and what not so you can see a per device status as to its functionality in a particular snapshot of FreeBSD. -brian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 4/08/2006 4:58 AM, User Freebsd wrote: Getting a list of devices is actually pretty easy, and I've tried this on my 4.x machines also, so it isn't something that will be a problem on older versions: # pciconf -l [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 ... And, more specifically, we can get: # pciconf -l -v [EMAIL PROTECTED]:9:0: class=0x010400 card=0xc0351044 chip=0xa5111044 rev=0x01 hdr=0x00 vendor = 'Adaptec (Formerly: Distributed Processing Technology (DPT))' device = 'Raptor SmartRAID Controller' class= mass storage subclass = RAID All of the expanded 'vendor', 'device', 'class' and 'subclass' information is present in the non -v version of the command output. The numbers shown earlier can be used to derive the text information: class=0x010400 determines the class/subclass lines, using the table from here: http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340 card=0xc0351044 chip=0xa5111044 these make up the vendor and device lines, using the list in /usr/share/misc/pci_vendors (which is derived from the PCIDEVS.TXT listing). The last 4 hex digits of the card and chip lines are the vendor ID while the first 4 are the device ID. The card is often given by the vendor, while the chip identifies the actual part it uses to implement functionality. For instance, a Netcomm ethernet NIC may use a Realtek 8139 chip... so chip gives us the fact it's essentially a generic Realtek chipset, while the card tells us the vendor who manufactured the card perhaps their name for it. In short, there's no reason to have to transmit all the text names back to any server -- this can all be resolved at the server end, So, with that one command, we can get a fair amount of hardware information ... but, how to feed that into a proper HTTP request? Storing all of that information would be cool, cause then we could build reports based on device driver / vendor / device / class and subclass ... but that might be a bit heavy to do in an HTTP request, no? I take it email isn't an option, in your case? Email may be a viable alternative -- one concern with email is that various organisations SMTP servers blast their own disclaimer message and so on across the bottom of all out-going emails, which might complicate parsing of it on the server end. If you're only encoding purely the numeric details, this would make the information far lighter to transmit than having the whole text blurb. Just the pciconf -l version as-is: ~$ pciconf -l|wc -c 1545 So that's ~1500 bytes. Now strip out all the unnecessary text - the class=, card=, chip=, rev=, hdr=, extra spaces... something like: [EMAIL PROTECTED]:5:0: 01 34358086 00301000 08 00 [EMAIL PROTECTED]:5:1: 01 34358086 00301000 08 00 [EMAIL PROTECTED]:4:0: 02 10798086 10798086 03 00 [EMAIL PROTECTED]:4:1: 02 10798086 10798086 03 00 ~$ cat pciconf-stripped | wc -c 899 We've nearly halved the size of the information. Now it's still in ASCII, so you could further shave bits off by converting that to binary if you wanted to... With that amount of information, you'd probably be more inclined to want to use HTTP POST than HTTP GET. A quick glance suggests libfetch(3) doesn't support this; I haven't looked at the code enough to see if adding support for it would be trivial or not. -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Fri, 4 Aug 2006, Antony Mawer wrote: On 4/08/2006 4:58 AM, User Freebsd wrote: Getting a list of devices is actually pretty easy, and I've tried this on my 4.x machines also, so it isn't something that will be a problem on older versions: # pciconf -l [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 ... And, more specifically, we can get: # pciconf -l -v [EMAIL PROTECTED]:9:0: class=0x010400 card=0xc0351044 chip=0xa5111044 rev=0x01 hdr=0x00 vendor = 'Adaptec (Formerly: Distributed Processing Technology (DPT))' device = 'Raptor SmartRAID Controller' class= mass storage subclass = RAID All of the expanded 'vendor', 'device', 'class' and 'subclass' information is present in the non -v version of the command output. The numbers shown earlier can be used to derive the text information: class=0x010400 determines the class/subclass lines, using the table from here: http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340 card=0xc0351044 chip=0xa5111044 these make up the vendor and device lines, using the list in /usr/share/misc/pci_vendors (which is derived from the PCIDEVS.TXT listing). The last 4 hex digits of the card and chip lines are the vendor ID while the first 4 are the device ID. The card is often given by the vendor, while the chip identifies the actual part it uses to implement functionality. For instance, a Netcomm ethernet NIC may use a Realtek 8139 chip... so chip gives us the fact it's essentially a generic Realtek chipset, while the card tells us the vendor who manufactured the card perhaps their name for it. In short, there's no reason to have to transmit all the text names back to any server -- this can all be resolved at the server end, I was thinking of that ... my concern, and it may be totally invalid, but is it guaranteed to always translate the same? ie: [EMAIL PROTECTED]:8:0: class=0x02 card=0x10408086 chip=0x12298086 rev=0x10 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet Will that always translate the same regardless of running 4.x vs 5.x vs ... ? If so, you are right, that does greatly simplify things ... I just wasn't 100% certain ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 4/08/2006 10:29 AM, User Freebsd wrote: I was thinking of that ... my concern, and it may be totally invalid, but is it guaranteed to always translate the same? ie: ... Will that always translate the same regardless of running 4.x vs 5.x vs ... ? If so, you are right, that does greatly simplify things ... I just wasn't 100% certain ... The text may change slightly, but if anything, wouldn't it be better if all your stats consistently referred to the same device IDs with the same strings? A vendor name may be updated in the list (company gets bought out, renamed, etc), but I'm fairly sure nothing ever gets *removed* from the list - it just grows as new devices and vendors are added over time. The important information is the ID numbers -- the text attached to them will always be the same in meaning, even if the text may vary a few letters here or there (ie. a device ID that was a Pro/1000 NIC won't suddenly turn into a Realtek 8139 one day). The non-verbose information is all you need for building a stats database. Your stats database can have its own database of the pcidevs.txt imported periodically, and link the information up at display time. -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/3/06, Antony Mawer [EMAIL PROTECTED] wrote: On 4/08/2006 4:58 AM, User Freebsd wrote: Getting a list of devices is actually pretty easy, and I've tried this on my 4.x machines also, so it isn't something that will be a problem on older versions: # pciconf -l [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 ... And, more specifically, we can get: # pciconf -l -v [EMAIL PROTECTED]:9:0: class=0x010400 card=0xc0351044 chip=0xa5111044 rev=0x01 hdr=0x00 vendor = 'Adaptec (Formerly: Distributed Processing Technology (DPT))' device = 'Raptor SmartRAID Controller' class= mass storage subclass = RAID All of the expanded 'vendor', 'device', 'class' and 'subclass' information is present in the non -v version of the command output. The numbers shown earlier can be used to derive the text information: class=0x010400 determines the class/subclass lines, using the table from here: http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340 card=0xc0351044 chip=0xa5111044 these make up the vendor and device lines, using the list in /usr/share/misc/pci_vendors (which is derived from the PCIDEVS.TXT listing). The last 4 hex digits of the card and chip lines are the vendor ID while the first 4 are the device ID. The card is often given by the vendor, while the chip identifies the actual part it uses to implement functionality. For instance, a Netcomm ethernet NIC may use a Realtek 8139 chip... so chip gives us the fact it's essentially a generic Realtek chipset, while the card tells us the vendor who manufactured the card perhaps their name for it. In short, there's no reason to have to transmit all the text names back to any server -- this can all be resolved at the server end, So, with that one command, we can get a fair amount of hardware information ... but, how to feed that into a proper HTTP request? Storing all of that information would be cool, cause then we could build reports based on device driver / vendor / device / class and subclass ... but that might be a bit heavy to do in an HTTP request, no? I take it email isn't an option, in your case? Email may be a viable alternative -- one concern with email is that various organisations SMTP servers blast their own disclaimer message and so on across the bottom of all out-going emails, which might complicate parsing of it on the server end. If you're only encoding purely the numeric details, this would make the information far lighter to transmit than having the whole text blurb. Just the pciconf -l version as-is: ~$ pciconf -l|wc -c 1545 So that's ~1500 bytes. Now strip out all the unnecessary text - the class=, card=, chip=, rev=, hdr=, extra spaces... something like: [EMAIL PROTECTED]:5:0: 01 34358086 00301000 08 00 [EMAIL PROTECTED]:5:1: 01 34358086 00301000 08 00 [EMAIL PROTECTED]:4:0: 02 10798086 10798086 03 00 [EMAIL PROTECTED]:4:1: 02 10798086 10798086 03 00 ~$ cat pciconf-stripped | wc -c 899 We've nearly halved the size of the information. Now it's still in ASCII, so you could further shave bits off by converting that to binary if you wanted to... With that amount of information, you'd probably be more inclined to want to use HTTP POST than HTTP GET. A quick glance suggests libfetch(3) doesn't support this; I haven't looked at the code enough to see if adding support for it would be trivial or not. 899 bytes * (10^7) = 8.37258995 gigabytes... Remember... Once this code is pushed out to hosts you can't change it. 10 years from now we'll still have hosts sending in old data What was wrong with my netcat idea? uname -mr | nc statistics.freebsd.org 1234 It's one, short, line of code and you know exactly what it's doing. Simple, Easy, Done. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 4/08/2006 11:44 AM, Nikolas Britton wrote: 899 bytes * (10^7) = 8.37258995 gigabytes... Remember... Once this code is pushed out to hosts you can't change it. 10 years from now we'll still have hosts sending in old data What was wrong with my netcat idea? uname -mr | nc statistics.freebsd.org 1234 It's one, short, line of code and you know exactly what it's doing. Simple, Easy, Done. Part of the idea I mentioned earlier was using a hash of this information... so the first time you send it through, you generate a hash and store it... then in future you can iterate over the hardware list, hash it, compare it against your stored hash, and only send if the hardware inventory has changed... Not everywhere has unrestricted access out to the Internet via whatever port they want... I know of many sites that only allow HTTP, and only via a proxy... I guess there's two different goals here... the uname -mr gives vendors an idea of what install base is out there when they're considering developing drivers/platform support... the hardware inventory gives vendors, developers and users an idea of what existing hardware is in use... ... if someone could bring up a list and find out that 500,000 people were using such-and-such a driver, it may influence the decision as to whether or not to update said driver when architectural changes are being made that require updates to the drivers... instead of the current system of sending an email out and hoping the appropriate users spot it on the appropriate mailing list and pipe up... -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/3/06, Antony Mawer [EMAIL PROTECTED] wrote: On 4/08/2006 11:44 AM, Nikolas Britton wrote: 899 bytes * (10^7) = 8.37258995 gigabytes... Remember... Once this code is pushed out to hosts you can't change it. 10 years from now we'll still have hosts sending in old data What was wrong with my netcat idea? uname -mr | nc statistics.freebsd.org 1234 It's one, short, line of code and you know exactly what it's doing. Simple, Easy, Done. Part of the idea I mentioned earlier was using a hash of this information... so the first time you send it through, you generate a hash and store it... then in future you can iterate over the hardware list, hash it, compare it against your stored hash, and only send if the hardware inventory has changed... Not everywhere has unrestricted access out to the Internet via whatever port they want... I know of many sites that only allow HTTP, and only via a proxy... Ok how about: uname -mr | nc statistics.freebsd.org 80 Wow, that was easy! :-) -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Fri, 4 Aug 2006, Antony Mawer wrote: All of the expanded 'vendor', 'device', 'class' and 'subclass' information is present in the non -v version of the command output. The numbers shown earlier can be used to derive the text information: class=0x010400 determines the class/subclass lines, using the table from here: http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340 card=0xc0351044 chip=0xa5111044 these make up the vendor and device lines, using the list in /usr/share/misc/pci_vendors (which is derived from the PCIDEVS.TXT listing). The last 4 hex digits of the card and chip lines are the vendor ID while the first 4 are the device ID. The card is often given by the vendor, while the chip identifies the actual part it uses to implement functionality. For instance, a Netcomm ethernet NIC may use a Realtek 8139 chip... so chip gives us the fact it's essentially a generic Realtek chipset, while the card tells us the vendor who manufactured the card perhaps their name for it. In short, there's no reason to have to transmit all the text names back to any server -- this can all be resolved at the server end, 'k, looking at the above, and comparing it to what I'm getting from pciconf -l, I'm missing something ... namely: [EMAIL PROTECTED]:10:0:class=0x02 card=0x0027a0a0 chip=0x813910ec rev=0x10 hdr=0x00 Translates to: [EMAIL PROTECTED]:10:0:class=0x02 card=0x0027a0a0 chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class= network subclass = ethernet But, the last 4 hex of card/chip aren't teh same ... oh, wait, re-reading what you stated, is it safe to assume that chip= can be ignored ... nope, that doesn't follow either ... but I think I see it ... For the above, vendor *should* be Aopen Inc, not Realtek Semiconductor ... 'k, so, for the above: card=0x0027a0a0 - Aopen Inc (A0A0) chip=0x813910ec - Realtek Semiconductor (10EC) - 8139RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter (8139) And the 0027 is actually meaningless in this case ... So, what I'm looking for is vendor-device, but in some card= cases, there won't be a 'Device' listed ... As to class= ... what table am I supposed to be seeing at that URL? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 4/08/2006 1:31 PM, User Freebsd wrote:
'k, looking at the above, and comparing it to what I'm getting from
pciconf -l, I'm missing something ... namely:
[EMAIL PROTECTED]:10:0:class=0x02 card=0x0027a0a0 chip=0x813910ec
rev=0x10 hdr=0x00
Translates to:
[EMAIL PROTECTED]:10:0:class=0x02 card=0x0027a0a0 chip=0x813910ec
rev=0x10 hdr=0x00
vendor = 'Realtek Semiconductor'
device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter'
class= network
subclass = ethernet
But, the last 4 hex of card/chip aren't teh same ... oh, wait,
re-reading what you stated, is it safe to assume that chip= can be
ignored ... nope, that doesn't follow either ... but I think I see it ...
Looking through src/usr.sbin/pciconf/pciconf.c, it looks as though
pciconf only translates the chip= for what it displays. The DOS-based
PCI identification code that I've worked with in the past typically
referred chip as device, and card as sub-device... Internally,
pciconf uses the same references (snipped from the printf statement):
(p-pc_subdevice 16) | p-pc_subvendor,
(p-pc_device 16) | p-pc_vendor,
The aforementioned DOS utilities used to display lookups for both (where
appropriate); I vaguely recall coming to the conclusion that the
sub-device bit was not mandatory, but someone with more knowledge of the
ins and outs of the PCI specs may be able to state that more definitively...
In short, the chip field from pciconf looks like the most important
one.. the rev/hdr fields are less important for our needs - as far as
I'm aware they're generally used to denominate hardware revisions, so as
vendors revise their PCB layouts and components, they can be easily
differentiate between them -- this is most important when you're a
driver, trying to figure out what how you should treat a specific
device... The card one may fall into a nice-to-know but not necessary..
For the above, vendor *should* be Aopen Inc, not Realtek Semiconductor ...
'k, so, for the above:
card=0x0027a0a0
- Aopen Inc (A0A0)
chip=0x813910ec
- Realtek Semiconductor (10EC)
- 8139RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter (8139)
And the 0027 is actually meaningless in this case ...
So in your case, it's a Realtek 8139 adapter, most likely as part of an
AOpen motherboard or add-in card...
So, what I'm looking for is vendor-device, but in some card= cases,
there won't be a 'Device' listed ...
As to class= ... what table am I supposed to be seeing at that URL?
The class= line is a combination of two fields (the same as chip and
card are a combination of vendor and device fields) -- the class, and
subclass, of the device.
The URL http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340 shows the C
source for this table that's used to match them up... for instance:
CLASS SUBCLASSDESCRIPTION
{PCIC_NETWORK, -1, network},
{PCIC_NETWORK, PCIS_NETWORK_ETHERNET, ethernet},
{PCIC_NETWORK, PCIS_NETWORK_TOKENRING, token ring},
{PCIC_NETWORK, PCIS_NETWORK_FDDI, fddi},
{PCIC_NETWORK, PCIS_NETWORK_ATM, ATM},
{PCIC_NETWORK, PCIS_NETWORK_ISDN, ISDN},
The first line of the above defines the network device class; then it
defines several of the sub-classes of class network... ethernet, token
ring, etc. These are defined here:
http://fxr.watson.org/fxr/source/dev/pci/pcireg.h#L218
So this line:
{PCIC_NETWORK, PCIS_NETWORK_ETHERNET, ethernet},
actually reads:
{0x02, 0x00, ethernet},
So our class line:
class=0x02
Is made up of 2 hex digits for the device class, and 4 hex digits for
the device sub-class...
Savvy? ;-)
-Antony
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
- Original Message - From: Nikolas Britton [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] Cc: Robert Huff [EMAIL PROTECTED]; Xiao-Yong Jin [EMAIL PROTECTED]; freebsd-questions@freebsd.org; User Freebsd [EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 1:12 PM Subject: Re: Gotta start somewhere ... how many of us are really out there? On 8/1/06, Ted Mittelstaedt [EMAIL PROTECTED] wrote: Why not just add in the patch in kern/65627 and run the CPU serial number through your hash? Because you can still fake the dam thing, Why fake it when you can merely not supply it in the first place? There are valid uses for unique host ID's other than this marketing reporting scheme. I was merely pointing out to the OP that it is not particularly difficult (as he was arguing) to get unique ID's out of a FreeBSD system, I was not commenting on the scheme he wanted them for. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Atom Powers wrote: It's still going to take you at least a release to get it into the base install. But if you can find a way to use the portsnap data and get useful information out of the cvsup data you can probably get numbers now with an error margin as low as 8% to 15%. Hey, I said that a week ago! Guess I agree with you :-) Not quite convinced by the error margin, but as long as you count too low then I see no problem. If, as Nikolas pointed out, a URL-based reporting scheme can be bombarded with fakes, as a vendor I would not want to listen to any numbers it produced. But the question then goes back to: can you make any kind of count out of cvsup servers? Someone already said they thought you couldn't. At the end of the day, I think that unique IP address is as close as it's possible to get to host count. It will undercount NATed hosts and networks with single cvsup/portsnap distribution points, and will overcount variable IP addresses. The latter, I think matters the least as long as you do your stats over a short enough period (e.g. 1 month). That wouldn't overcount much and deliberate faking would be hard and limited (how many IP addresses can one faker get access to?). Then, as long as the methodology is clearly explained along with any stats, you'd have the ammunition to persuade vendors (we hope). --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/2/06, Alex Zbyslaw [EMAIL PROTECTED] wrote: Atom Powers wrote: It's still going to take you at least a release to get it into the base install. But if you can find a way to use the portsnap data and get useful information out of the cvsup data you can probably get numbers now with an error margin as low as 8% to 15%. Hey, I said that a week ago! Guess I agree with you :-) Not quite convinced by the error margin, but as long as you count too low then I see no problem. If, as Nikolas pointed out, a URL-based reporting scheme can be bombarded with fakes, as a vendor I would not want to listen to any numbers it produced. But the question then goes back to: can you make any kind of count out of cvsup servers? Someone already said they thought you couldn't. At the end of the day, I think that unique IP address is as close as it's possible to get to host count. It will undercount NATed hosts and networks with single cvsup/portsnap distribution points, and will overcount variable IP addresses. The latter, I think matters the least as long as you do your stats over a short enough period (e.g. 1 month). That wouldn't overcount much and deliberate faking would be hard and limited (how many IP addresses can one faker get access to?). Then, as long as the methodology is clearly explained along with any stats, you'd have the ammunition to persuade vendors (we hope). --Alex The problem with cvsup (I use cvsup.) is the error margin. The closer we get to release dates the more I use cvsup, It's a side effect of running -STABLE. anyways... back to the fakers... Lets think about the usage patterns of a typical faker vs NAT: Faker: * All from one IP address. * Sequential requests. * Scripted, so each request should be timed perfectly with the one before and the one after it. * Thousands of requests. NATed Boxes: * All from one IP address. * Parallel requests. * Not scripted, requests should be more random. * Hundreds of requests? Also I seem to remember a way to detect NATed boxes: http://www.google.com/search?client=operarls=enq=detecting+NATsourceid=operaie=utf-8oe=utf-8 -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Nikolas Britton wrote: On 8/2/06, Alex Zbyslaw [EMAIL PROTECTED] wrote: But the question then goes back to: can you make any kind of count out of cvsup servers? Someone already said they thought you couldn't. At the end of the day, I think that unique IP address is as close as it's possible to get to host count. It will undercount NATed hosts and networks with single cvsup/portsnap distribution points, and will overcount variable IP addresses. The latter, I think matters the least as long as you do your stats over a short enough period (e.g. 1 month). That wouldn't overcount much and deliberate faking would be hard and limited (how many IP addresses can one faker get access to?). The problem with cvsup (I use cvsup.) is the error margin. The closer we get to release dates the more I use cvsup, It's a side effect of running -STABLE. anyways... back to the fakers... Lets think about the usage patterns of a typical faker vs NAT: Faker: * All from one IP address. * Sequential requests. * Scripted, so each request should be timed perfectly with the one before and the one after it. * Thousands of requests. NATed Boxes: * All from one IP address. * Parallel requests. * Not scripted, requests should be more random. * Hundreds of requests? But if what you are counting is IP addresses then you faker has achieved nothing. You're not counting connections, but IP addresses. Yes, you undercount NATed and yes you undercount when distribution points are used, but I don't see any easy way to fake, at least not on the scale of a URL. Yes, if you happen to have 200 IP addresses, you could probably assign each in turn to your BSD box and cvsup, but this seems less likely to me, and is inherently limited. Sometimes I cvsup three times a day - in which case all are likely to come from same IP. Sometimes I cvsup once a month or less, in which case looking at statistics only over the last month will tend to flatten any effect from variable IPs. It's far from perfect, but unless you want each installation to have its own license number and a GenuineFreeBSD program which enforces unique license numbers somehow, I don't think there is a perfect answer. I'm guessing no-one in their right might does want this kind of enforcement ;-) --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/2/06, Alex Zbyslaw [EMAIL PROTECTED] wrote: Nikolas Britton wrote: On 8/2/06, Alex Zbyslaw [EMAIL PROTECTED] wrote: But the question then goes back to: can you make any kind of count out of cvsup servers? Someone already said they thought you couldn't. At the end of the day, I think that unique IP address is as close as it's possible to get to host count. It will undercount NATed hosts and networks with single cvsup/portsnap distribution points, and will overcount variable IP addresses. The latter, I think matters the least as long as you do your stats over a short enough period (e.g. 1 month). That wouldn't overcount much and deliberate faking would be hard and limited (how many IP addresses can one faker get access to?). The problem with cvsup (I use cvsup.) is the error margin. The closer we get to release dates the more I use cvsup, It's a side effect of running -STABLE. anyways... back to the fakers... Lets think about the usage patterns of a typical faker vs NAT: Faker: * All from one IP address. * Sequential requests. * Scripted, so each request should be timed perfectly with the one before and the one after it. * Thousands of requests. NATed Boxes: * All from one IP address. * Parallel requests. * Not scripted, requests should be more random. * Hundreds of requests? But if what you are counting is IP addresses then you faker has achieved nothing. You're not counting connections, but IP addresses. Yes, you undercount NATed and yes you undercount when distribution points are used, but I don't see any easy way to fake, at least not on the scale of a URL. Yes, if you happen to have 200 IP addresses, you could probably assign each in turn to your BSD box and cvsup, but this seems less likely to me, and is inherently limited. Sometimes I cvsup three times a day - in which case all are likely to come from same IP. Sometimes I cvsup once a month or less, in which case looking at statistics only over the last month will tend to flatten any effect from variable IPs. It's far from perfect, but unless you want each installation to have its own license number and a GenuineFreeBSD program which enforces unique license numbers somehow, I don't think there is a perfect answer. I'm guessing no-one in their right might does want this kind of enforcement ;-) This may sound dumb but why don't we just put a registration link on the FreeBSD main page... or registration in sysinstall. Isn't this how everyone else handles the problem? -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Nikolas Britton wrote: This may sound dumb but why don't we just put a registration link on the FreeBSD main page... or registration in sysinstall. Isn't this how everyone else handles the problem? Not on the home page, I would suggest, because a) opt-in registrations have really low take-up and b) you want to count systems, not users. Who would register once per machine they run? How could you tell if they were lying? I imagine I could *easily* rustle up a dozen or more email addresses and then claim, say 20? 100? hosts per address. Sysinstall is an option, but then you only get to count from the point where you get your change into a new release, and only count from that release forward. Every host running any older version is guaranteed to be missed. Eventually, you will start to get some kind of count, but again you will suffer from people who hate registering. Whether that will outnumber hosts lost to other counting methods, I could only guess. And anything upgraded using cvsup would be missed too. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Wed, 2 Aug 2006, Nikolas Britton wrote: This may sound dumb but why don't we just put a registration link on the FreeBSD main page... or registration in sysinstall. Isn't this how everyone else handles the problem? User A installs FreeBSD, registers, works with it for a week, finds he isn't getting anything done with it, wipes the drive and goes to something else ... User B installs FreeBSD 5.x, registers, works with it for a while and decides to CVSup to -CURRENT, so now we have an artificially high # of 6.x installs, and an artificially low # of 7.x installs ... nobody looks to be moving to 7.x, therefore why support it from a vendors perspective ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Wed, 2 Aug 2006, Peter A. Giessel wrote: On 2006/08/02 15:37, User Freebsd seems to have typed: On Wed, 2 Aug 2006, Nikolas Britton wrote: This may sound dumb but why don't we just put a registration link on the FreeBSD main page... or registration in sysinstall. Isn't this how everyone else handles the problem? I'd fill out a form to register FreeBSD, I did so with OpenOffice, and I did so with MacOSX, but I'm not going to let a DHD (dial home device) knowingly sit on my server. Thats one (of many) reasons I don't use Microsoft. I'll remove it before the installworld step if need be. Pine has a nice feature in it ... when you upgrade or install, the first thing it prompts you for when you start it up the first time is whether or not you wish to send a message in to be counted as a pine user ... its an opt-in sort of thing, but highly visible ... Maybe have something like this at the very end of the installworld? So that it isn't automatic, but it is an obvious step that ppl go through? It should also be included as part of sysinstall, again, opt-in ... do you want to have you install counted? ... sysinstall should report it as a fresh install, installworld as an upgrade ... The problem with something like this, mind you, is that the #s go up, but never come down (ie. someone retires a server), since there is no 'refresh timeout' ... The thing I was hoping for / looking at was some sort of update mechanism, so that retired servers would 'fade out' of the numbers ... the problem is that that requires *some sort* of DHD, whether it be in the form of something like uptimec, or a 'periodic monthly' report that goes out to say i'm still alive :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
User Freebsd wrote: On Wed, 2 Aug 2006, Nikolas Britton wrote: This may sound dumb but why don't we just put a registration link on the FreeBSD main page... or registration in sysinstall. Isn't this how everyone else handles the problem? User A installs FreeBSD, registers, works with it for a week, finds he isn't getting anything done with it, wipes the drive and goes to something else ... User B installs FreeBSD 5.x, registers, works with it for a while and decides to CVSup to -CURRENT, so now we have an artificially high # of 6.x installs, and an artificially low # of 7.x installs ... nobody looks to be moving to 7.x, therefore why support it from a vendors perspective ... Right, I've been following this thread from the start but didn't want to get involved, even though I felt this is important and necessary. I've come up with this token-based registration idea: Agent: Knock, knock... Server: Hi, give us your last 2 tokens... Agent: I don't have them... I'm a newborn. Server: Ok. Here's one for you $token1 and come back in 7 days. 7 days later (or more if it's a laptop) Agent: Knock, knock... Server: Hi, give us your last 2 tokens... Agent: I only have 1 token. Server: Ok. There you go $token2. Get back in 7 days. 7 days later (or more if it's a laptop) Agent: Knock, knock... Server: Hi, give us your last 2 tokens... Agent: Take them, $token1 and $token2. Server (compares tokens): Thanks, now give us some info about yourself. Agent: Ok, sending $information. Server: Thanks, this is another $token3 for you. Come back in 7 days. ... beyond this point the agent is officially registered but must maintain its rego by reporting every 7 days and keep providing latest 2 tokens ... In short, an agent must earn the registration. In this case it takes 2 weeks. Once it registers, it becomes a real number in the stats. If that agent stops reporting for a few months then it gets removed from the stats. If agent's computer upgrades, then it doesn't matter because it still sends $information (with updates) every time it reports. If another agent steals the tokens then it isn't an issue. The victim gets rejected until it collects new tokens. This is because stolen tokens already got registered. The burglar, in the other hand, stays with that stolen registration and resubmits its own $information (uname, dmesg, whatever), which overwrites victim's data. To strengthen the system and avoid token high-jacks we could increment the number and complexity of tokens. From users' point of view, there are no registration or scary configurations. The system takes over and does everything behind the scenes. For sure, the only necessary thing would be an enable_rego=YES or similar line in /etc/rc.conf. In order to cater for the demand, I reckon there would be enough people willing to donate servers and bandwidth (I'd be one of them). Agents also could detect the closest server on their own and report to it (fastest_cvsup[1] style)... Ok, I'll stop here for now. Cheers, Mikhail. [1] - http://www.freebsd.org/cgi/url.cgi?ports/sysutils/fastest_cvsup/pkg-descr -- Mikhail Goriachev Webanoide Telephone: +61 (0)3 62252501 Mobile Phone: +61 (0)4 38255158 E-Mail: [EMAIL PROTECTED] Web: http://www.webanoide.org PGP Key ID: 0x4E148A3B PGP Key Fingerprint: D96B 7C14 79A5 8824 B99D 9562 F50E 2F5D 4E14 8A3B ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Mikhail Goriachev [EMAIL PROTECTED] writes: User Freebsd wrote: On Wed, 2 Aug 2006, Nikolas Britton wrote: This may sound dumb but why don't we just put a registration link on the FreeBSD main page... or registration in sysinstall. Isn't this how everyone else handles the problem? User A installs FreeBSD, registers, works with it for a week, finds he isn't getting anything done with it, wipes the drive and goes to something else ... User B installs FreeBSD 5.x, registers, works with it for a while and decides to CVSup to -CURRENT, so now we have an artificially high # of 6.x installs, and an artificially low # of 7.x installs ... nobody looks to be moving to 7.x, therefore why support it from a vendors perspective ... Right, I've been following this thread from the start but didn't want to get involved, even though I felt this is important and necessary. I've come up with this token-based registration idea: Agent: Knock, knock... Server: Hi, give us your last 2 tokens... Agent: I don't have them... I'm a newborn. Server: Ok. Here's one for you $token1 and come back in 7 days. 7 days later (or more if it's a laptop) Agent: Knock, knock... Server: Hi, give us your last 2 tokens... Agent: I only have 1 token. Server: Ok. There you go $token2. Get back in 7 days. 7 days later (or more if it's a laptop) Agent: Knock, knock... Server: Hi, give us your last 2 tokens... Agent: Take them, $token1 and $token2. Server (compares tokens): Thanks, now give us some info about yourself. Agent: Ok, sending $information. Server: Thanks, this is another $token3 for you. Come back in 7 days. ... beyond this point the agent is officially registered but must maintain its rego by reporting every 7 days and keep providing latest 2 tokens ... In short, an agent must earn the registration. In this case it takes 2 weeks. Once it registers, it becomes a real number in the stats. If that agent stops reporting for a few months then it gets removed from the stats. If agent's computer upgrades, then it doesn't matter because it still sends $information (with updates) every time it reports. If another agent steals the tokens then it isn't an issue. The victim gets rejected until it collects new tokens. This is because stolen tokens already got registered. The burglar, in the other hand, stays with that stolen registration and resubmits its own $information (uname, dmesg, whatever), which overwrites victim's data. To strengthen the system and avoid token high-jacks we could increment the number and complexity of tokens. From users' point of view, there are no registration or scary configurations. The system takes over and does everything behind the scenes. For sure, the only necessary thing would be an enable_rego=YES or similar line in /etc/rc.conf. In order to cater for the demand, I reckon there would be enough people willing to donate servers and bandwidth (I'd be one of them). Agents also could detect the closest server on their own and report to it (fastest_cvsup[1] style)... Ok, I'll stop here for now. Cheers, Mikhail. [1] - http://www.freebsd.org/cgi/url.cgi?ports/sysutils/fastest_cvsup/pkg-descr You still can't avoid fakeries. In fact, I guess that unless one uses some kinds of Genuine Advantage things, you can not tell if the data is true. However, acquiring a unique id from the server is a good idea to prevent from duplication, if the bandwidth permits. Therefore, why not simplify it? 1. Require an ID from the server after installation if permitted by the user. 2. Provide the ID and `uname -mr` periodically or in a randomized time interval between one to two months. Or simply let the user decide when to run it. But states clearly that it'll overload the server if all the clients connect simultaneously. Let me say it again. There are three problems we are trying to solve. a. Bandwidth. b. Duplicates. c. Fakery. By randomizing the time interval, bandwidth can no longer be a problem. And the uniqueness is assured by the ID generated in the server. Finally, I can't see any open source solution could prevent some people from generating fake boxes, even with some serial number of the hardwares. Can we do some checks of the hardware serial numbers? Okay, even if we do, we are going to touch too much privacy. So just forget about it. -- Xiao-Yong ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
You still can't avoid fakeries. Except that the fake will not bother coming back 3 times at one week interval, just to plant his faked data. Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Olivier Nicole [EMAIL PROTECTED] writes: You still can't avoid fakeries. Except that the fake will not bother coming back 3 times at one week interval, just to plant his faked data. Yes, just put it in the crontab. Easy, isn't it? Olivier -- Xiao-Yong ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Wed, 2 Aug 2006, Xiao-Yong Jin wrote: Let me say it again. There are three problems we are trying to solve. a. Bandwidth. Bandwidth, IMHO, isn't that big of an issue ... the ramp up time for this, IMHO, will be slow, so the bandwidth usage will be a gradual increase ... b. Duplicates. Ted seems to have this covered with the CPU ID thing ... c. Fakery. IMHO, not a *really* big issue ... I could see someone bothering to do it once or twice, but seems to be alot of work for little gain ... The main problem that I see is finding a method of doing this that a majority of ppl can agree with ... and then convincing Core of the merits, a group that hasn't even voiced an opinion in this conversation yet ... :( Without Core endorsement, this whole thing is a still birth, unfortunately ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Mon, 31 Jul 2006, Xiao-Yong Jin wrote: Chris Whitehouse [EMAIL PROTECTED] writes: Alex Zbyslaw wrote: Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing sent from local host - will count systems from any version of FreeBSD, but will never count everything because sites with multiple hosts may easily have local propagation mechanisms. But you will get an order of magnitude. However, how do you deal with systems with variable IPs? I don't know enough about the internals of either portsnap or cvsup to know if there is some kind of unique id associated with hosts. If not, then you'd wildly over count for many home-based, variable IP systems. Maybe not so many, my non-static ip hasn't changed since I signed up 3 years ago despite turning off the modem for the odd day or two. Another network I look after also hasn't changed in a year. But one can't rely on that. You'll definitely see more than one ip associated with my laptop, if I move it around. A more reliable way that I can think of is generating a unique ID number when a system finishes installation or upon the first boot. However, it may involve some additional privacy problem. What do you think? How does Solaris generate its 'hostid'? Is it a hardware/sparc thing, or software? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Mon, 31 Jul 2006, Gerard Seibert wrote: Xiao-Yong Jin wrote: But one can't rely on that. You'll definitely see more than one ip associated with my laptop, if I move it around. A more reliable way that I can think of is generating a unique ID number when a system finishes installation or upon the first boot. However, it may involve some additional privacy problem. What do you think? Unquestionable a privacy problem. Perhaps even illegal in some jurisdictions without the end users knowledge and permission. 'k, I'm confused on this one ... could you elaborate on why this is a privacy issue? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
- Original Message - From: User Freebsd [EMAIL PROTECTED] To: Xiao-Yong Jin [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Sent: Monday, July 31, 2006 6:08 PM Subject: Re: Gotta start somewhere ... how many of us are really out there? On Mon, 31 Jul 2006, Xiao-Yong Jin wrote: Chris Whitehouse [EMAIL PROTECTED] writes: Alex Zbyslaw wrote: Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing sent from local host - will count systems from any version of FreeBSD, but will never count everything because sites with multiple hosts may easily have local propagation mechanisms. But you will get an order of magnitude. However, how do you deal with systems with variable IPs? I don't know enough about the internals of either portsnap or cvsup to know if there is some kind of unique id associated with hosts. If not, then you'd wildly over count for many home-based, variable IP systems. Maybe not so many, my non-static ip hasn't changed since I signed up 3 years ago despite turning off the modem for the odd day or two. Another network I look after also hasn't changed in a year. But one can't rely on that. You'll definitely see more than one ip associated with my laptop, if I move it around. A more reliable way that I can think of is generating a unique ID number when a system finishes installation or upon the first boot. However, it may involve some additional privacy problem. What do you think? How does Solaris generate its 'hostid'? Is it a hardware/sparc thing, or software? All Sparc processors have serial numbers, always had. Sun's compiler and some other programs of theirs are serialized and when you buy them you have to send in the cpu serial number to Sun who generates a key that will only allow the compiler to run on that system. If you move the compiler you have to get another key and certify to Sun with a legal document that you will not run it on the old system, etc. At least that was how it worked last I dealt with that about 7 years ago. I believe modern pentiums are also serialized. There's ways to do a unique ID nowadays. None of them are portable and so these methods are frowned on. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Aug 1, 2006, at 12:14 AM, Ted Mittelstaedt wrote: Sun's compiler and some other programs of theirs are serialized and when you buy them you have to send in the cpu serial number to Sun who generates a key that will only allow the compiler to run on that system. If you move the compiler you have to get another key and certify to Sun with a legal document that you will not run it on the old system, etc. At least that was how it worked last I dealt with that about 7 years ago. That aspect has probably changed now since Solaris 10 is free as are the dev tools... (Sun Studio) They have open sourced solaris and some of the more interesting things are supposedly being ported to FreeBSD. Dtrace (we have had announcements of that here) and also ZFS! (which is way cool -- I am implementing a Solaris ZFS based server to do nfs file system sharing to my FreeBSD machines). Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Ted Mittelstaedt wrote:
- Original Message - From: User Freebsd [EMAIL PROTECTED]
To: Xiao-Yong Jin [EMAIL PROTECTED]
Cc: freebsd-questions@freebsd.org
Sent: Monday, July 31, 2006 6:08 PM
Subject: Re: Gotta start somewhere ... how many of us are really out
there?
On Mon, 31 Jul 2006, Xiao-Yong Jin wrote:
Chris Whitehouse [EMAIL PROTECTED] writes:
Alex Zbyslaw wrote:
Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing
sent from local host - will count systems from any version of
FreeBSD, but will never count everything because sites with multiple
hosts may easily have local propagation mechanisms. But you will
get an order of magnitude. However, how do you deal with systems
with variable IPs? I don't know enough about the internals of
either portsnap or cvsup to know if there is some kind of unique id
associated with hosts. If not, then you'd wildly over count for
many home-based, variable IP systems.
Maybe not so many, my non-static ip hasn't changed since I signed up 3
years ago despite turning off the modem for the odd day or
two. Another network I look after also hasn't changed in a year.
But one can't rely on that. You'll definitely see more than one ip
associated with my laptop, if I move it around.
A more reliable way that I can think of is generating a unique ID
number when a system finishes installation or upon the first boot.
However, it may involve some additional privacy problem. What do you
think?
How does Solaris generate its 'hostid'? Is it a hardware/sparc
thing, or
software?
All Sparc processors have serial numbers, always had. Sun's compiler and
some other
programs of theirs are serialized and when you buy them you have to
send in
the
cpu serial number to Sun who generates a key that will only allow the
compiler
to run on that system. If you move the compiler you have to get
another key
and
certify to Sun with a legal document that you will not run it on the old
system, etc.
At least that was how it worked last I dealt with that about 7 years ago.
I believe modern pentiums are also serialized. There's ways to do a
unique
ID
nowadays. None of them are portable and so these methods are frowned on.
Ted
CPUID's on Intel processors can be found using something similar to the
program I made below...
/**
*
* Author: Garrett Cooper
* File: cpuid_test.cpp
*
* Version: 0.1
* Date: 2006.03.24
*
* This program is a simple C one that takes a IA32 logical
* processor [think real processor, core, or hyperthreading capable
processor's
* virtual processor(s)] and prints out its ID, via the embedded IA32 cpuid
* asm instruction.
*
* Reference:
http://www.intel.com/cd/ids/developer/asmo-na/eng/43851.htm?prn=y
*
* Note: If you compile using Cygwin, use this command to compile in order
* to use a DOS prompt to execute the file:
*
* gcc -mno-cygwin -o cpuid_test.exe cpuid_test.c
*
* This code will no work in MSVS I believe, because it follows GCC's
* convention for inline ASM code.
*
*
* Version: 0.2
* Date: 2006.03.27
*
* Inline C++ function was added so then the program wouldn't just print
out the
* compiling machine's cpuid when I distributed the binary.
*
* The proper command for compiling now is:
*
*gcc -mno-cygwin -o cpuid_test.exe cpuid_test.cpp
*
*/
#include stdio.h
#include stdlib.h
inline void print_cpuid() {
unsigned int id = 0;
asm(
mov $1, %%eax;
cpuid;
mov %%ebx, %0;
: =r (id)
);
printf(cpuid=%4xh\n,id);
}
int main() {
print_cpuid();
system(pause);
return 0;
}
You should be able to figure out the ID of your processor if it's a P3
or newer IIRC. This was part of the whole snafu with Intel and having
people's serial numbers be transmitted online, I think.
-Garrett
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/31/06, User Freebsd [EMAIL PROTECTED] wrote: On Mon, 31 Jul 2006, Xiao-Yong Jin wrote: Chris Whitehouse [EMAIL PROTECTED] writes: Alex Zbyslaw wrote: Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing sent from local host - will count systems from any version of FreeBSD, but will never count everything because sites with multiple hosts may easily have local propagation mechanisms. But you will get an order of magnitude. However, how do you deal with systems with variable IPs? I don't know enough about the internals of either portsnap or cvsup to know if there is some kind of unique id associated with hosts. If not, then you'd wildly over count for many home-based, variable IP systems. Maybe not so many, my non-static ip hasn't changed since I signed up 3 years ago despite turning off the modem for the odd day or two. Another network I look after also hasn't changed in a year. But one can't rely on that. You'll definitely see more than one ip associated with my laptop, if I move it around. A more reliable way that I can think of is generating a unique ID number when a system finishes installation or upon the first boot. However, it may involve some additional privacy problem. What do you think? How does Solaris generate its 'hostid'? Is it a hardware/sparc thing, or software? Generating a unique anonymous key is easy, proving why we need it is not. Ok, here it is, ifconfig | sha256 | md5 . 16^32 unique anonymous keys. Every host needs to have a NIC to send results so all ifconfig outputs will be different. Now... What does this solve and why do we need to add 32 extra bytes? (20 + 32) bytes * (10^7) = 495.910645 megabytes. The FreeBSD team would need a 6.6Mbit/s uplink to handle peak load assuming 50% of the hosts are set to UTC/GMT time and all trigger within 5 minutes of each other I'm not going to pay for that connection. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Nikolas Britton [EMAIL PROTECTED] writes: Generating a unique anonymous key is easy, proving why we need it is not. That's how we can tell the differences between server to server. Ok, here it is, ifconfig | sha256 | md5 . 16^32 unique anonymous keys. Every host needs to have a NIC to send results so all ifconfig outputs will be different. Now... What does this solve and why do we need to add 32 extra bytes? I guess we are not suppose to generate the key from ifconfig, which will change in some circumstances. (20 + 32) bytes * (10^7) = 495.910645 megabytes. The FreeBSD team would need a 6.6Mbit/s uplink to handle peak load assuming 50% of the hosts are set to UTC/GMT time and all trigger within 5 minutes of each other I'm not going to pay for that connection. That IS the problem. What about randomize it in a certain interval? -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ -- Xiao-Yong ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Tue, 1 Aug 2006, Nikolas Britton wrote: Generating a unique anonymous key is easy, proving why we need it is not. If you want to make accurate #s, you need to make sure that a host doesn't send in multiple reports, which means you need a unique key for each host ... IP doesn't work, since NAT'd networks would all use the same IP ... even non-NAT'd networks would have the risk of being on dynamic IPs, so that again doesn't work ... (20 + 32) bytes * (10^7) = 495.910645 megabytes. The FreeBSD team would need a 6.6Mbit/s uplink to handle peak load assuming 50% of the hosts are set to UTC/GMT time and all trigger within 5 minutes of each other I'm not going to pay for that connection. First question is ... what is 10^7? # of reporting hosts? Where are you getting that # from? Second, that is assuming *all* FreeBSD servers reported ... But, I'll say this right now ... *if* something like this could be implemented to give us accurate #s, I *would* be willing to absorb the bandwidth you are talking about to see it happen ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Tue, 1 Aug 2006, Nikolas Britton wrote: On 7/31/06, User Freebsd [EMAIL PROTECTED] wrote: On Mon, 31 Jul 2006, Xiao-Yong Jin wrote: Chris Whitehouse [EMAIL PROTECTED] writes: Alex Zbyslaw wrote: Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing sent from local host - will count systems from any version of FreeBSD, but will never count everything because sites with multiple hosts may easily have local propagation mechanisms. But you will get an order of magnitude. However, how do you deal with systems with variable IPs? I don't know enough about the internals of either portsnap or cvsup to know if there is some kind of unique id associated with hosts. If not, then you'd wildly over count for many home-based, variable IP systems. Maybe not so many, my non-static ip hasn't changed since I signed up 3 years ago despite turning off the modem for the odd day or two. Another network I look after also hasn't changed in a year. But one can't rely on that. You'll definitely see more than one ip associated with my laptop, if I move it around. A more reliable way that I can think of is generating a unique ID number when a system finishes installation or upon the first boot. However, it may involve some additional privacy problem. What do you think? How does Solaris generate its 'hostid'? Is it a hardware/sparc thing, or software? Generating a unique anonymous key is easy, proving why we need it is not. Ok, here it is, ifconfig | sha256 | md5 . 16^32 unique anonymous keys. Every host needs to have a NIC to send results so all ifconfig outputs will be different. Now... What does this solve and why do we need to add 32 extra bytes? 'k, so we'd be looking at something like: #!/bin/sh ID=`ifconfig | sha256 | md5` SYS=`uname -mr | sed 's/\ /+/g'` fetch http://www.hub.org/freebsd_stats.php?HOSTID=$ID\SYSTEM=$SYS URL would be different, mind you, just using that to test / example ... Actually, using ifconfig wouldn't work ... it would give unique, but as soon as you add another IP (ie. alias), the ID would change ... you'd need to do something like: ifconfig | grep ether | sha256 | md5 since the 'ether' would never change ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
User Freebsd writes: Actually, using ifconfig wouldn't work ... it would give unique, but as soon as you add another IP (ie. alias), the ID would change ... you'd need to do something like: ifconfig | grep ether | sha256 | md5 since the 'ether' would never change ... At least some cards (+ FreeBSD drivers) allow you to set the MAC address Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Tue, 1 Aug 2006, Robert Huff wrote: User Freebsd writes: Actually, using ifconfig wouldn't work ... it would give unique, but as soon as you add another IP (ie. alias), the ID would change ... you'd need to do something like: ifconfig | grep ether | sha256 | md5 since the 'ether' would never change ... At least some cards (+ FreeBSD drivers) allow you to set the MAC address Man, we definitely don't make a unique host id an easy thing to accomplish, do we? :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
User Freebsd wrote: Actually, using ifconfig wouldn't work ... it would give unique, but as soon as you add another IP (ie. alias), the ID would change ... you'd need to do something like: ifconfig | grep ether | sha256 | md5 since the 'ether' would never change ... I think you'd want ifconfig | grep ether | head -1 | sha256 | md5 otherwise you are reliant on *none* of the ethernet cards changing rather than just the first not changing. Also s/never/rarely/. I don't change my ethernet cards every day, but every once in a while it will happen. But I would have said that was good enough. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/1/06, Robert Huff [EMAIL PROTECTED] wrote:
User Freebsd writes:
Actually, using ifconfig wouldn't work ... it would give unique, but as
soon as you add another IP (ie. alias), the ID would change ... you'd need
to do something like:
ifconfig | grep ether | sha256 | md5
since the 'ether' would never change ...
At least some cards (+ FreeBSD drivers) allow you to set the
MAC address
You still don't get it! Maybe this simple perl program will illustrate
the problem:
my $number = 1;
my $randomkey = ;
while (0 == 0) {
$randomkey = `echo $number | md5`;
print fetch http://www.hub.org/freebsd_stats.php?HOSTID=$randomkey;;
$number++
}
Also by using only the mac address output of ifconfig you have limited
the pool of unique keys to 16^12 (281,474,976,710,656)!!! All I need
to do to find your mac address is compute all possible mac address
combinations into MD5 and then just simply match it up with yours.
Anonymity only works if the input is large then the output!!! Because
it's computationally impossible to compute all values of a 500+ byte
string etc. etc. The MD5 string maps back to at least (how do you
compute the collisions?) two SHA256 keys and the SHA256 maps back to
at least two ifconfig strings.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Why not just add in the patch in kern/65627 and run the CPU serial number through your hash? Ted - Original Message - From: User Freebsd [EMAIL PROTECTED] To: Robert Huff [EMAIL PROTECTED] Cc: Xiao-Yong Jin [EMAIL PROTECTED]; Nikolas Britton [EMAIL PROTECTED]; freebsd-questions@freebsd.org Sent: Tuesday, August 01, 2006 9:11 AM Subject: Re: Gotta start somewhere ... how many of us are really out there? On Tue, 1 Aug 2006, Robert Huff wrote: User Freebsd writes: Actually, using ifconfig wouldn't work ... it would give unique, but as soon as you add another IP (ie. alias), the ID would change ... you'd need to do something like: ifconfig | grep ether | sha256 | md5 since the 'ether' would never change ... At least some cards (+ FreeBSD drivers) allow you to set the MAC address Man, we definitely don't make a unique host id an easy thing to accomplish, do we? :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/1/06, Ted Mittelstaedt [EMAIL PROTECTED] wrote:
Why not just add in the patch in kern/65627 and run the CPU serial number
through
your hash?
Because you can still fake the dam thing, making the whole idea
useless!!! Am I the only one that can see this ... what the hell
people! I just showed you a working crack! Need to see it again?:
my $number = 1;
my $randomkey = ;
while (0 == 0) {
$randomkey = `echo $number | md5`;
print fetch http://www.hub.org/freebsd_stats.php?HOSTID=$randomkey;;
$number++
}
OUT:
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=e8b3fad8939670f85e0fce777cae8e0c
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=91e572785d190fec766a5b7caef16597
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=e8150443d9befbfba9ee6ca40af076e7
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=b1aefc59367a7d512104f2f63bf1afb8
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=bf883c70f506603c86c8785cca8eef5e
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=79e005d4f379e549eaff7106ede744b7
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=de09c238162dae88e9372102fe114be9
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=7ac8e65d693f525db9fabb061f15ac8b
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=14e16452a9bdff69e5177ee4de0631e0
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=5432cc5903e4ff9b556561c5b553220b
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=263aaf7d4910cce7b66e2e4438d65ab2
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=083d41d985775a53c2ada0c66b1a7d4c
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=3e1b6b0b9c5c4d478b4a161c6e1c5d46
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=1aed1b7d4add59bedfd21df56e15cd90
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=233196bee8136806b7570532d1d34349
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=56753858102f51b756c93bd5c0dbfaa5
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=baea3619ea55ee516e3c556ffb7fd287
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=cf49ffbeb51fd9864386388a68f41059
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=f5c052e568711a4cb61890d7114d1f43
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=5796f413c62eb369fa15c37fffb748f8
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=4574ee7d3334a609c5b4de66f1527eca
Surrounded by #$%^*$@ idiots.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Tue, 1 Aug 2006, Nikolas Britton wrote:
On 8/1/06, Ted Mittelstaedt [EMAIL PROTECTED] wrote:
Why not just add in the patch in kern/65627 and run the CPU serial number
through
your hash?
Because you can still fake the dam thing, making the whole idea
useless!!! Am I the only one that can see this ... what the hell
people! I just showed you a working crack! Need to see it again?:
my $number = 1;
my $randomkey = ;
while (0 == 0) {
$randomkey = `echo $number | md5`;
print fetch http://www.hub.org/freebsd_stats.php?HOSTID=$randomkey;;
$number++
}
OUT:
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=e8b3fad8939670f85e0fce777cae8e0c
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=91e572785d190fec766a5b7caef16597
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=e8150443d9befbfba9ee6ca40af076e7
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=b1aefc59367a7d512104f2f63bf1afb8
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=bf883c70f506603c86c8785cca8eef5e
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=79e005d4f379e549eaff7106ede744b7
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=de09c238162dae88e9372102fe114be9
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=7ac8e65d693f525db9fabb061f15ac8b
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=14e16452a9bdff69e5177ee4de0631e0
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=5432cc5903e4ff9b556561c5b553220b
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=263aaf7d4910cce7b66e2e4438d65ab2
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=083d41d985775a53c2ada0c66b1a7d4c
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=3e1b6b0b9c5c4d478b4a161c6e1c5d46
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=1aed1b7d4add59bedfd21df56e15cd90
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=233196bee8136806b7570532d1d34349
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=56753858102f51b756c93bd5c0dbfaa5
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=baea3619ea55ee516e3c556ffb7fd287
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=cf49ffbeb51fd9864386388a68f41059
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=f5c052e568711a4cb61890d7114d1f43
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=5796f413c62eb369fa15c37fffb748f8
fetch
http://www.hub.org/freebsd_stats.php?HOSTID=4574ee7d3334a609c5b4de66f1527eca
Surrounded by #$%^*$@ idiots.
Actually, must have missed this the first time through, thanks ... but,
why would we need to run the CPU serial number through the hash, if its
already unique to each CPU?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Tue, 1 Aug 2006, Nikolas Britton wrote:
On 8/1/06, Robert Huff [EMAIL PROTECTED] wrote:
User Freebsd writes:
Actually, using ifconfig wouldn't work ... it would give unique, but as
soon as you add another IP (ie. alias), the ID would change ... you'd
need
to do something like:
ifconfig | grep ether | sha256 | md5
since the 'ether' would never change ...
At least some cards (+ FreeBSD drivers) allow you to set the
MAC address
You still don't get it! Maybe this simple perl program will illustrate
the problem:
my $number = 1;
my $randomkey = ;
while (0 == 0) {
$randomkey = `echo $number | md5`;
print fetch http://www.hub.org/freebsd_stats.php?HOSTID=$randomkey;;
$number++
}
Also by using only the mac address output of ifconfig you have limited
the pool of unique keys to 16^12 (281,474,976,710,656)!!! All I need
to do to find your mac address is compute all possible mac address
combinations into MD5 and then just simply match it up with yours.
Anonymity only works if the input is large then the output!!! Because
it's computationally impossible to compute all values of a 500+ byte
string etc. etc. The MD5 string maps back to at least (how do you
compute the collisions?) two SHA256 keys and the SHA256 maps back to
at least two ifconfig strings.
Thing is, we aren't so much looking for anonymity as we are uniqueness,
but, wouldn't the CPU serial id not be both?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/1/06, User Freebsd [EMAIL PROTECTED] wrote:
On Tue, 1 Aug 2006, Nikolas Britton wrote:
On 8/1/06, Robert Huff [EMAIL PROTECTED] wrote:
User Freebsd writes:
Actually, using ifconfig wouldn't work ... it would give unique, but as
soon as you add another IP (ie. alias), the ID would change ... you'd
need
to do something like:
ifconfig | grep ether | sha256 | md5
since the 'ether' would never change ...
At least some cards (+ FreeBSD drivers) allow you to set the
MAC address
You still don't get it! Maybe this simple perl program will illustrate
the problem:
my $number = 1;
my $randomkey = ;
while (0 == 0) {
$randomkey = `echo $number | md5`;
print fetch http://www.hub.org/freebsd_stats.php?HOSTID=$randomkey;;
$number++
}
Also by using only the mac address output of ifconfig you have limited
the pool of unique keys to 16^12 (281,474,976,710,656)!!! All I need
to do to find your mac address is compute all possible mac address
combinations into MD5 and then just simply match it up with yours.
Anonymity only works if the input is large then the output!!! Because
it's computationally impossible to compute all values of a 500+ byte
string etc. etc. The MD5 string maps back to at least (how do you
compute the collisions?) two SHA256 keys and the SHA256 maps back to
at least two ifconfig strings.
Thing is, we aren't so much looking for anonymity as we are uniqueness,
but, wouldn't the CPU serial id not be both?
Ok.. lets start from the top, again. Why do we need uniqueness?
--
BSD Podcasts @:
http://bsdtalk.blogspot.com/
http://freebsdforall.blogspot.com/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Tue, 1 Aug 2006, Nikolas Britton wrote: Ok.. lets start from the top, again. Why do we need uniqueness? We want to count each host reporting *once* ... without uniqueness per host, how are you going to know whether to update a hosts record, instead of add it as a new host? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/1/06, User Freebsd [EMAIL PROTECTED] wrote: On Tue, 1 Aug 2006, Nikolas Britton wrote: Ok.. lets start from the top, again. Why do we need uniqueness? We want to count each host reporting *once* ... without uniqueness per host, how are you going to know whether to update a hosts record, instead of add it as a new host? But no matter what you do you can never guaranty a hosts uniqueness... What you want to do is akin to DRM and there is no way to do this in the open source world. What is wrong with a total host count? If all hosts are reporting in once per month then whats the problem?... just simple addition: DATA: 6.1-STABLE i386 6.0-RELEASE i386 6.1-RELEASE-p2 AMD Using that sample data above we had a total of 3 hosts report in during the month of X. After that you can break the data down, for example there are two I386 system for every one AMD system etc. etc. etc. We don't need to tracking each host to get a count of new systems... Just take the total from month X and subtract it from month Y to get Z, the new hosts that reported in. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 8/1/06, User Freebsd [EMAIL PROTECTED] wrote: On Tue, 1 Aug 2006, Nikolas Britton wrote: Ok.. lets start from the top, again. Why do we need uniqueness? We want to count each host reporting *once* ... without uniqueness per host, how are you going to know whether to update a hosts record, instead of add it as a new host? Maybe I lost the point here, but are you trying to track every FreeBSD host or are you just trying to show that there is a large user-base? If you are just trying to show a large user base then you don't have to keep any kind of uid. Your numbers are going to be off by at least 20% to 30% just from people opting not to opt in; the error margin from duplicate hosts is going to be smaller than that, especially if you use freely available public data, like IP address, to track duplicates. On the other hand, if you want to keep tabs on every host out there, how often it has connected, it's uid, etc. Well, that smells too strongly of big brother for my tastes. Even if it is anonymous. It's still going to take you at least a release to get it into the base install. But if you can find a way to use the portsnap data and get useful information out of the cvsup data you can probably get numbers now with an error margin as low as 8% to 15%. Achem's Razor anybody? ( The simplest solution is the best solution. ) -- -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Tue, 1 Aug 2006, Nikolas Britton wrote: On 8/1/06, User Freebsd [EMAIL PROTECTED] wrote: On Tue, 1 Aug 2006, Nikolas Britton wrote: Ok.. lets start from the top, again. Why do we need uniqueness? We want to count each host reporting *once* ... without uniqueness per host, how are you going to know whether to update a hosts record, instead of add it as a new host? But no matter what you do you can never guaranty a hosts uniqueness... What you want to do is akin to DRM and there is no way to do this in the open source world. What is wrong with a total host count? If all hosts are reporting in once per month then whats the problem?... just simple addition: DATA: 6.1-STABLE i386 6.0-RELEASE i386 6.1-RELEASE-p2 AMD I guess I'm just trying to make it as accurate as possible, and fear someone fetch bombing just to artificially increase the #s ... but, then again, if they did do that, even with a unique value, it wouldn't take much to create a random one for that purpose ... So, ya, I guess a unique id would be pretty useless ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Hi, Just my 2 satangs. It's nice to try to get a overall figure, but something that could be easier to indentify and would have some importance too, is the VIP users. If we can say that Google is using FreeBSD for their search engine farm, even if there are only 2000 machines, it may have more importance than the 200,000 John Doe's machines. olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
User Freebsd wrote: On Sun, 30 Jul 2006, Colin Percival wrote: Approximately 15000 portsnap snapshots (i.e., /var/db/portsnap or /usr/local/portsnap directories) are being kept updated on systems which send HTTP requests to portsnap*.freebsd.org. Of these, about 4300 are running FreeBSD 6.0, 4500 are running FreeBSD 6.1, 2400 are running FreeBSD 6-STABLE, 300 are running FreeBSD 5.5, and the remaining 3500 are using copies of portsnap installed from the ports tree (presumably on earlier FreeBSD releases, since the portsnap port won't install if portsnap is already part of the FreeBSD base system). 'k, *this* sounds like it might be perfect ... would it be possible to get a copy of the portsnap logs to see about setting up some sort of auto-parse? Maybe setup some statistics and graphs? You mean something like http://www.daemonology.net/portsnap/stats.html ? BTW, is portsnap meant to replace cvsup, or ... ? Or are we still only getting half the picture if we look at portsnap only? There are still a lot of people (particularly on pre-6.0 systems) who are using CVSup rather than portsnap for updating their ports trees. Colin Percival ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Colin Percival wrote: There are still a lot of people (particularly on pre-6.0 systems) who are using CVSup rather than portsnap for updating their ports trees. Also, I would guess that some people who run multiple FreeBSD systems, use some sort of local propagation of either the entire ports tree, or locally compiled packages. I work as a sysadmin at the students computer lab at the mathematics department at the Norwegian university of science and technology, and we take this approach. Not that the maths department is a large one, but we have fifty-some workstations and a couple of servers running FreeBSD. Only one or two of which would show up in the portsnap stats. Svein Halvor signature.asc Description: OpenPGP digital signature
Re: Gotta start somewhere ... how many of us are really out there?
Colin Percival wrote: There are still a lot of people (particularly on pre-6.0 systems) who are using CVSup rather than portsnap for updating their ports trees. Even when I upgrade to 6 I think it unlikely I'll be switching to portsnap for 2 main reasons: 1) I know csvup; I have config files I understand; there is local documentation which I don't want to have to update. This may change at some point if I have time to become familiar with portsnap and its advantages are important enough. 2) As long as portsnap overwrites local changes to the ports tree, it's not for me. If you want to count by port tree download, ignoring cvsup, would, I think be a mistake. It seems to me that nothing done *now*, will ever give you a count of how many FreeBSD systems there are *now* and that there are disadvantages and advantages to all the systems proposed. Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing sent from local host - will count systems from any version of FreeBSD, but will never count everything because sites with multiple hosts may easily have local propagation mechanisms. But you will get an order of magnitude. However, how do you deal with systems with variable IPs? I don't know enough about the internals of either portsnap or cvsup to know if there is some kind of unique id associated with hosts. If not, then you'd wildly over count for many home-based, variable IP systems. And then there's NAT'ed systems too :-( Putting something into the base system (e.g. periodic), if off by default will find many people not bothered to turn it on, but if on by default could easily upset people over privacy concerns. Also, you'll miss every system which doesn't upgrade to whatever latest version has the counting. It's clear from reading this list for a while that there are plenty of hosts out there not running the latest version, with good reasons for that. But what percentage, it's impossible to tell without some kind of counting :-) --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Mon, 31 Jul 2006, Colin Percival wrote: User Freebsd wrote: On Sun, 30 Jul 2006, Colin Percival wrote: Approximately 15000 portsnap snapshots (i.e., /var/db/portsnap or /usr/local/portsnap directories) are being kept updated on systems which send HTTP requests to portsnap*.freebsd.org. Of these, about 4300 are running FreeBSD 6.0, 4500 are running FreeBSD 6.1, 2400 are running FreeBSD 6-STABLE, 300 are running FreeBSD 5.5, and the remaining 3500 are using copies of portsnap installed from the ports tree (presumably on earlier FreeBSD releases, since the portsnap port won't install if portsnap is already part of the FreeBSD base system). 'k, *this* sounds like it might be perfect ... would it be possible to get a copy of the portsnap logs to see about setting up some sort of auto-parse? Maybe setup some statistics and graphs? You mean something like http://www.daemonology.net/portsnap/stats.html ? Not really ... more interested in a simpler graph / #s that denote # of distinct hosts for each version of FreeBSD each month ... depending on the amount of data you can pull out of the logs, getting #s per country, and #s per top level domain (ie. yahoo.com) would be cool too ... Also: gathering the access logs for portsnap.daemonology.net, portsnap1.freebsd.org, and portsnap2.freebsd.org Are those the *only* portsnap servers, or are there more? Again, the idea is to get a complete, and as accurate as possible, picture ... There are still a lot of people (particularly on pre-6.0 systems) who are using CVSup rather than portsnap for updating their ports trees. Actually, I'm ashamed to say that I'm still using CVSup also ... going to work on getting myself switched over too ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Mon, 31 Jul 2006, Svein Halvor Halvorsen wrote: Colin Percival wrote: There are still a lot of people (particularly on pre-6.0 systems) who are using CVSup rather than portsnap for updating their ports trees. Also, I would guess that some people who run multiple FreeBSD systems, use some sort of local propagation of either the entire ports tree, or locally compiled packages. I work as a sysadmin at the students computer lab at the mathematics department at the Norwegian university of science and technology, and we take this approach. Not that the maths department is a large one, but we have fifty-some workstations and a couple of servers running FreeBSD. Only one or two of which would show up in the portsnap stats. Ya, that is the part that throws the #s out completely ... its those 'ghost machines' that would be nice to see counted somehow ... How about something as innoculous as: fetch http://statsserver.domain/aliveping.php?version=`uname -mr`hostname=`hostname` run as part of periodic daily ... ? uname -mr would have to be properly formatted for a URL, but that would give a distinct IP / hostname for indexing, and OS version, take neglible bandwidth to run, and, I believe, doesn't give out any *sensitive* information ... Then have a daily_statistics_enable=YES in /etc/defaults/perodic.conf, so that ppl can opt out of it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Sun, 30 Jul 2006, Chad Leigh -- Shire.Net LLC wrote: On Jul 30, 2006, at 8:42 PM, User Freebsd wrote: On Sun, 30 Jul 2006, Colin Percival wrote: User Freebsd wrote: We can also collect the access information of the cvsup server and portsnap server, can't we? What does that give? Approximately 15000 portsnap snapshots (i.e., /var/db/portsnap or /usr/local/portsnap directories) are being kept updated on systems which send HTTP requests to portsnap*.freebsd.org. Of these, about 4300 are running FreeBSD 6.0, 4500 are running FreeBSD 6.1, 2400 are running FreeBSD 6-STABLE, 300 are running FreeBSD 5.5, and the remaining 3500 are using copies of portsnap installed from the ports tree (presumably on earlier FreeBSD releases, since the portsnap port won't install if portsnap is already part of the FreeBSD base system). BTW, is portsnap meant to replace cvsup, or ... ? Or are we still only getting half the picture if we look at portsnap only? You are getting some fraction of the picture. We don't use portsnap (and cvsup we do use but not that often), for example. We use cvsup here, daily, to update the ports tree ... and based on someone else's post (alex?), finding out that portsnap overwrites the ports tree, which I'm taking to mean it will remove anything I add to it, makes changing over for me a no-op :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
OT: portsnap [was Re: Gotta start somewhere ... how many of us are really out there?]
User Freebsd wrote: We use cvsup here, daily, to update the ports tree ... and based on someone else's post (alex?), finding out that portsnap overwrites the ports tree, which I'm taking to mean it will remove anything I add to it, makes changing over for me a no-op :( Caveat: I don't maintain or use portsnap! The overwrite behaviour was correct last time I checked (several months ago) and was deemed difficult to correct because of the way portsnap worked. The 6.1 man page still says: update Update a ports tree extracted using the extract command. You must run this command to apply changes to your ports tree after downloading updates via the fetch or cron commands. Again, note that in the parts of the ports tree which are being updated, any local changes or additions will be removed. Not insurmountable if you religiously keep all changes in some other repository (tar, cvs?) but I personally do not see enough benefit. That would mean to me that counting would have to include cvsup, even if that under-counted. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
User Freebsd wrote: On Mon, 31 Jul 2006, Svein Halvor Halvorsen wrote: Colin Percival wrote: There are still a lot of people (particularly on pre-6.0 systems) who are using CVSup rather than portsnap for updating their ports trees. Also, I would guess that some people who run multiple FreeBSD systems, use some sort of local propagation of either the entire ports tree, or locally compiled packages. I work as a sysadmin at the students computer lab at the mathematics department at the Norwegian university of science and technology, and we take this approach. Not that the maths department is a large one, but we have fifty-some workstations and a couple of servers running FreeBSD. Only one or two of which would show up in the portsnap stats. Ya, that is the part that throws the #s out completely ... its those 'ghost machines' that would be nice to see counted somehow ... How about something as innoculous as: fetch http://statsserver.domain/aliveping.php?version=`uname -mr`hostname=`hostname` run as part of periodic daily ... ? uname -mr would have to be properly formatted for a URL, but that would give a distinct IP / hostname for indexing, and OS version, take neglible bandwidth to run, and, I believe, doesn't give out any *sensitive* information ... Then have a daily_statistics_enable=YES in /etc/defaults/perodic.conf, so that ppl can opt out of it ... But this will then only count from the first version(s) of FreeBSD which contain the periodic job. Then every machine running an earlier release would be a ghost. I think the bottom line I see is that whatever you do, you cannot count everything. *If* some kind of counting could be done *now* using portsnap and cvsup servers that are amenable, then you reasonably quickly start getting some kind of count. The some kind of optional periodic job can also be rolled out and many months down the line it would start to produce potentially more reliable (i.e. higher :-)) figures, assuming ppl were amenable to running it. But if you have to wait for 6.3 or 7.0 or whatever, and then wait for the majority to adopt it, that's longer than I think you want to wait for some kind of answer. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Mon, 31 Jul 2006, Alex Zbyslaw wrote: But this will then only count from the first version(s) of FreeBSD which contain the periodic job. Then every machine running an earlier release would be a ghost. Agreed, but any active counting will fail dealing with older machines, regardless ... this is something that should have been implemented / started *ages* ago ... we will never have # of sales figures we can market ourselves to vendors based on, but, we also have nothing in the way of # of deployments figures ... I think the bottom line I see is that whatever you do, you cannot count everything. *If* some kind of counting could be done *now* using portsnap and cvsup servers that are amenable, then you reasonably quickly start getting some kind of count. cvsup, i don't believe, will give us any #s, mainly since it doesn't seem to really provide any information: # grep 68851 /var/log/cvsup Apr 29 23:15:08 postgresql cvsupd[68851]: +4338 [EMAIL PROTECTED] (turbine.word-to-the-wise.com) [SNAP_16_1h/17.0] Apr 29 23:15:13 postgresql cvsupd[68851]: =4338 [96Kin+3Kout] pgsql/cvs Apr 29 23:15:13 postgresql cvsupd[68851]: -4338 [97Kin+3Kout] Finished successfully The some kind of optional periodic job can also be rolled out and many months down the line it would start to produce potentially more reliable (i.e. higher :-)) figures, assuming ppl were amenable to running it. But if you have to wait for 6.3 or 7.0 or whatever, and then wait for the majority to adopt it, that's longer than I think you want to wait for some kind of answer. ... true, but if we *never* do anything, we'll never have numbers ... even if there is a 12 month or more adoption curve, that adoption period has to start *somewhere* ... As far as ppl amenable to running it ... if the purpose was properly explained, with periodic reminders on the lists as to what the Stats Project was all about, and as long as the information being sent out is fully explain (ie. make sure ppl realize that nothing of a sensitive nature is being sent out), I think adoption would be alot easier ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Alex Zbyslaw wrote: Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing sent from local host - will count systems from any version of FreeBSD, but will never count everything because sites with multiple hosts may easily have local propagation mechanisms. But you will get an order of magnitude. However, how do you deal with systems with variable IPs? For the portsnap usage statistics, I'm measuring how many days of updates were downloaded per day. In the long run this will be equal to the number of systems using portsnap, whether they update daily or monthly, and whether they have a fixed IP address or a different IP address every time. The only problem I've seen with this method is that it is rather sensitive to holidays: There is a dip in measured portsnap usage in late December, folllowed by a sharp spike in early January before the measured usage returns to normal, since many systems were not being updated over the Christmas holiday, and then suddenly needed to catch up in early January (and since they were downloading several weeks of updates, they each looked like several machines). Colin Percival ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Alex Zbyslaw wrote: Colin Percival wrote: Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing sent from local host - will count systems from any version of FreeBSD, but will never count everything because sites with multiple hosts may easily have local propagation mechanisms. But you will get an order of magnitude. However, how do you deal with systems with variable IPs? I don't know enough about the internals of either portsnap or cvsup to know if there is some kind of unique id associated with hosts. If not, then you'd wildly over count for many home-based, variable IP systems. Maybe not so many, my non-static ip hasn't changed since I signed up 3 years ago despite turning off the modem for the odd day or two. Another network I look after also hasn't changed in a year. Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Chris Whitehouse wrote: Maybe not so many, my non-static ip hasn't changed since I signed up 3 years ago despite turning off the modem for the odd day or two. Another network I look after also hasn't changed in a year. Yes, my IP changed just once in the last 5 years and that was when a new company bought out my cable service provider. Neither power outages nor turning it off manually has changed the IP address. -- +==+ |\ _,,,---,,_ | Gerard Seibert Zzz /,`.-'`'-. ;-;;,_ | [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-'| icq: 95653152 FAX: (845) 228-1602 '---''(_/--' `-'\_) | //This Space Available// +==+ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Chris Whitehouse [EMAIL PROTECTED] writes: Alex Zbyslaw wrote: Counting portsnap and cvsup accesses is non-intrusive - i.e. nothing sent from local host - will count systems from any version of FreeBSD, but will never count everything because sites with multiple hosts may easily have local propagation mechanisms. But you will get an order of magnitude. However, how do you deal with systems with variable IPs? I don't know enough about the internals of either portsnap or cvsup to know if there is some kind of unique id associated with hosts. If not, then you'd wildly over count for many home-based, variable IP systems. Maybe not so many, my non-static ip hasn't changed since I signed up 3 years ago despite turning off the modem for the odd day or two. Another network I look after also hasn't changed in a year. But one can't rely on that. You'll definitely see more than one ip associated with my laptop, if I move it around. A more reliable way that I can think of is generating a unique ID number when a system finishes installation or upon the first boot. However, it may involve some additional privacy problem. What do you think? -- Xiao-Yong ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Xiao-Yong Jin wrote: But one can't rely on that. You'll definitely see more than one ip associated with my laptop, if I move it around. A more reliable way that I can think of is generating a unique ID number when a system finishes installation or upon the first boot. However, it may involve some additional privacy problem. What do you think? Unquestionable a privacy problem. Perhaps even illegal in some jurisdictions without the end users knowledge and permission. -- +==+ |\ _,,,---,,_ | Gerard Seibert Zzz /,`.-'`'-. ;-;;,_ | [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-'| icq: 95653152 FAX: (845) 228-1602 '---''(_/--' `-'\_) |//This Space Available// +==+ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/31/06, User Freebsd [EMAIL PROTECTED] wrote: On Mon, 31 Jul 2006, Svein Halvor Halvorsen wrote: Colin Percival wrote: There are still a lot of people (particularly on pre-6.0 systems) who are using CVSup rather than portsnap for updating their ports trees. Also, I would guess that some people who run multiple FreeBSD systems, use some sort of local propagation of either the entire ports tree, or locally compiled packages. I work as a sysadmin at the students computer lab at the mathematics department at the Norwegian university of science and technology, and we take this approach. Not that the maths department is a large one, but we have fifty-some workstations and a couple of servers running FreeBSD. Only one or two of which would show up in the portsnap stats. Ya, that is the part that throws the #s out completely ... its those 'ghost machines' that would be nice to see counted somehow ... How about something as innoculous as: fetch http://statsserver.domain/aliveping.php?version=`uname -mr`hostname=`hostname` run as part of periodic daily ... ? uname -mr would have to be properly formatted for a URL, but that would give a distinct IP / hostname for indexing, and OS version, take neglible bandwidth to run, and, I believe, doesn't give out any *sensitive* information ... DAILY! Are you out of your mind? and we don't need to collect hostnames. Can we just start with something simple like: 'uname -mr | nc statistics.freebsd.org port' in the monthly periodic. On the server side you can make some custom program to collect these and the ip address (not that it's needed). This will work in the mean time: 'nc -klo port statistics_data_file' Then have a daily_statistics_enable=YES in /etc/defaults/perodic.conf, so that ppl can opt out of it ... -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
My calculations are off, I though the monthly periodic was relative to the system install date. Here are the new numbers: Lets say each client sends 20 bytes and their are 10^7 clients for a total of 190.7MB per month. Now... Lets say 50% (10^6.7) of those clients are set to UTC and all of them trigger on the first of the month within 5 minutes of each other (10^6 per minute). This equates to 16706 clients per second. We would need 326KB/s or 2610Kbit/s to handle this load. This is a problem, even half of that is a problem. On 7/29/06, Nikolas Britton [EMAIL PROTECTED] wrote: On 7/29/06, User Freebsd [EMAIL PROTECTED] wrote: On Fri, 28 Jul 2006, Ted Mittelstaedt wrote: You might think this sounds harmless but folks have done this kind of thing in the past with other products and wreaked havoc on the Internet. You can start by referencing dlink ntp fiasco in google to get an idea of what can happen to these kinds of well meaning attempts. Let sleeping dogs lie. 'k, you lost me on how this relates to the fiasco ... I did a quick search on Google for it, and, unless I didn't find the right reference, the 'fiasco' had to do with DLink setting up their software to ping PHKs NTP Server, without getting permissions first, and, thereby, flooding him with NTP requests ... People just don't realize just how very big the Internet is. That is the problem, yes ... nobody knows how big the FreeBSD community is ... :) I have to agree with Marc on this one. The extra load required to send all of this data is not much: Lets say each client sends 20 bytes and their are 10^7 clients for a total of 190.7MB per month or 6.25MB per day . Now... Lets say 50% (10^6.7) of those clients are set to UTC and 50% of those clients (10^6.4) trigger the monthly periodic over a 5 day period (10^5.7 each day) and all of them phone home within 5 minutes of each other (10^5 per minute) for a total of 1666.67 clients per second. We would need 32.6KB/s or 260.4Kbit/s to handle this load spike... I did the calculations for 10 million clients, but I highly doubt FreeBSD has 5 million so this is a non issue. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Fri, 28 Jul 2006, Nikolas Britton wrote: My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. What about sending something as simple as uname -mr? 'k ... uname -mr 6.1-STABLE i386 The only way this idea will work is if we put some code in the base system that sends something generic every few months. for example. Send 'uname -mr' to stats.freebsd.org every 3 months. It would be very easy to 'opt out', perhaps stats_enable=NO in rc.conf. Alternatively we could make it 'opt in' at install time. The installer could add stats_enable=YES to rc.conf when someone answers yes. The actual code to implement this is trivial, something like a few lines of shell script and a config file that lists the next send date. This config file can be checked during the monthly periodic and if needed trigger the stats script to send the anonymous data and update the next send date in the config file. If the stats script can't find a path out it should update the next send date and then die. Why not just have it as part of the monthly_periodic itself ... have it send a copy to a central address as well as to the admin itself, with the message containing a note on how to disable it in /etc/rc.conf, and have it opt_in by default? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Fri, 28 Jul 2006, Nikolas Britton wrote: The only way this idea will work is if we put some code in the base system that sends something generic every few months. for example. Send 'uname -mr' to stats.freebsd.org every 3 months. It would be very easy to 'opt out', perhaps stats_enable=NO in rc.conf. Alternatively we could make it 'opt in' at install time. The installer could add stats_enable=YES to rc.conf when someone answers yes. The actual code to implement this is trivial, something like a few lines of shell script and a config file that lists the next send date. This config file can be checked during the monthly periodic and if needed trigger the stats script to send the anonymous data and update the next send date in the config file. If the stats script can't find a path out it should update the next send date and then die. Btw, you'd need to include something else in the mix to differentiate various hosts ... maybe MAC address or something like that? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Sat, 29 Jul 2006, Nikolas Britton wrote: Yes and no. Not all cvsup servers are under the control of the FreeBSD project but you are right, they could log the release tag and more. Also don't forget about website stats, mailing list subscriptions, and ftp servers. None of which actually give you even close to accurate #s, unfortunately ... for instance, website stats ... if you were to look at the ones for freebsd.org, how many would be Windows Browsers :( And then we are only talking about desktops, not servers ... As to stuff like CVSup logs ... how many large deployments have one central CVSup 'downloader' while the rest in the org just feed off of that? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Fri, 28 Jul 2006, Ted Mittelstaedt wrote: You might think this sounds harmless but folks have done this kind of thing in the past with other products and wreaked havoc on the Internet. You can start by referencing dlink ntp fiasco in google to get an idea of what can happen to these kinds of well meaning attempts. Let sleeping dogs lie. 'k, you lost me on how this relates to the fiasco ... I did a quick search on Google for it, and, unless I didn't find the right reference, the 'fiasco' had to do with DLink setting up their software to ping PHKs NTP Server, without getting permissions first, and, thereby, flooding him with NTP requests ... People just don't realize just how very big the Internet is. That is the problem, yes ... nobody knows how big the FreeBSD community is ... :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Sat, 29 Jul 2006, Xiao-Yong Jin wrote: People like me who only use FreeBSD on the laptop would certainly give much shorter uptimes. Okay, I just wanna say, it's very strange to a mobile/desktop user. Again, I wasn't thinking so much about uptimes as the fact that the information is updated regularly ... We can also collect the access information of the cvsup server and portsnap server, can't we? What does that give? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
User Freebsd wrote: We can also collect the access information of the cvsup server and portsnap server, can't we? What does that give? Approximately 15000 portsnap snapshots (i.e., /var/db/portsnap or /usr/local/portsnap directories) are being kept updated on systems which send HTTP requests to portsnap*.freebsd.org. Of these, about 4300 are running FreeBSD 6.0, 4500 are running FreeBSD 6.1, 2400 are running FreeBSD 6-STABLE, 300 are running FreeBSD 5.5, and the remaining 3500 are using copies of portsnap installed from the ports tree (presumably on earlier FreeBSD releases, since the portsnap port won't install if portsnap is already part of the FreeBSD base system). Colin Percival ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Sun, 30 Jul 2006, Colin Percival wrote: User Freebsd wrote: We can also collect the access information of the cvsup server and portsnap server, can't we? What does that give? Approximately 15000 portsnap snapshots (i.e., /var/db/portsnap or /usr/local/portsnap directories) are being kept updated on systems which send HTTP requests to portsnap*.freebsd.org. Of these, about 4300 are running FreeBSD 6.0, 4500 are running FreeBSD 6.1, 2400 are running FreeBSD 6-STABLE, 300 are running FreeBSD 5.5, and the remaining 3500 are using copies of portsnap installed from the ports tree (presumably on earlier FreeBSD releases, since the portsnap port won't install if portsnap is already part of the FreeBSD base system). 'k, *this* sounds like it might be perfect ... would it be possible to get a copy of the portsnap logs to see about setting up some sort of auto-parse? Maybe setup some statistics and graphs? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Sun, 30 Jul 2006, Colin Percival wrote: User Freebsd wrote: We can also collect the access information of the cvsup server and portsnap server, can't we? What does that give? Approximately 15000 portsnap snapshots (i.e., /var/db/portsnap or /usr/local/portsnap directories) are being kept updated on systems which send HTTP requests to portsnap*.freebsd.org. Of these, about 4300 are running FreeBSD 6.0, 4500 are running FreeBSD 6.1, 2400 are running FreeBSD 6-STABLE, 300 are running FreeBSD 5.5, and the remaining 3500 are using copies of portsnap installed from the ports tree (presumably on earlier FreeBSD releases, since the portsnap port won't install if portsnap is already part of the FreeBSD base system). BTW, is portsnap meant to replace cvsup, or ... ? Or are we still only getting half the picture if we look at portsnap only? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Jul 30, 2006, at 8:42 PM, User Freebsd wrote: On Sun, 30 Jul 2006, Colin Percival wrote: User Freebsd wrote: We can also collect the access information of the cvsup server and portsnap server, can't we? What does that give? Approximately 15000 portsnap snapshots (i.e., /var/db/portsnap or /usr/local/portsnap directories) are being kept updated on systems which send HTTP requests to portsnap*.freebsd.org. Of these, about 4300 are running FreeBSD 6.0, 4500 are running FreeBSD 6.1, 2400 are running FreeBSD 6-STABLE, 300 are running FreeBSD 5.5, and the remaining 3500 are using copies of portsnap installed from the ports tree (presumably on earlier FreeBSD releases, since the portsnap port won't install if portsnap is already part of the FreeBSD base system). BTW, is portsnap meant to replace cvsup, or ... ? Or are we still only getting half the picture if we look at portsnap only? You are getting some fraction of the picture. We don't use portsnap (and cvsup we do use but not that often), for example. Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/29/06, User Freebsd [EMAIL PROTECTED] wrote: On Fri, 28 Jul 2006, Nikolas Britton wrote: On 7/28/06, Atom Powers [EMAIL PROTECTED] wrote: My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. What about sending something as simple as uname -mr? 'k ... $ uname -mr 6.1-STABLE i386 The only way this idea will work is if we put some code in the base system that sends something generic every few months. for example. Send 'uname -mr' to stats.freebsd.org every 3 months. It would be very easy to 'opt out', perhaps stats_enable=NO in rc.conf. Alternatively we could make it 'opt in' at install time. The installer could add stats_enable=YES to rc.conf when someone answers yes. The actual code to implement this is trivial, something like a few lines of shell script and a config file that lists the next send date. This config file can be checked during the monthly periodic and if needed trigger the stats script to send the anonymous data and update the next send date in the config file. If the stats script can't find a path out it should update the next send date and then die. Why not just have it as part of the monthly_periodic itself ... have it send a copy to a central address as well as to the admin itself, with the message containing a note on how to disable it in /etc/rc.conf, and have it opt_in by default? Works for me, their are thousands of easy ways to do it and my example was just one of them. The hard parts going to be convincing core to let you do this. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: On Fri, 28 Jul 2006, Atom Powers wrote: My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. It is definitely your perogative, but I'm curious as to why not? You have the source code for the client, so its not some sort of 'spyware' that is sitting running on your machine ... The over riding question here is not why not but why. A package like this doesn't help the server run faster or better. It is another piece of code that has to be audited and maintained. I take a very minimalist approach to my systems. How about this, ask the portsnap mirrors how many connections they get. Since portsnap is already in the base system and is now the preferred ports update method, you can get a much better aproximation (although still very under-represented) of how many hosts are out there. -- -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/29/06, User Freebsd [EMAIL PROTECTED] wrote: On Fri, 28 Jul 2006, Ted Mittelstaedt wrote: You might think this sounds harmless but folks have done this kind of thing in the past with other products and wreaked havoc on the Internet. You can start by referencing dlink ntp fiasco in google to get an idea of what can happen to these kinds of well meaning attempts. Let sleeping dogs lie. 'k, you lost me on how this relates to the fiasco ... I did a quick search on Google for it, and, unless I didn't find the right reference, the 'fiasco' had to do with DLink setting up their software to ping PHKs NTP Server, without getting permissions first, and, thereby, flooding him with NTP requests ... People just don't realize just how very big the Internet is. That is the problem, yes ... nobody knows how big the FreeBSD community is ... :) I have to agree with Marc on this one. The extra load required to send all of this data is not much: Lets say each client sends 20 bytes and their are 10^7 clients for a total of 190.7MB per month or 6.25MB per day . Now... Lets say 50% (10^6.7) of those clients are set to UTC and 50% of those clients (10^6.4) trigger the monthly periodic over a 5 day period (10^5.7 each day) and all of them phone home within 5 minutes of each other (10^5 per minute) for a total of 1666.67 clients per second. We would need 32.6KB/s or 260.4Kbit/s to handle this load spike... I did the calculations for 10 million clients, but I highly doubt FreeBSD has 5 million so this is a non issue. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/29/06, Atom Powers [EMAIL PROTECTED] wrote: On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: On Fri, 28 Jul 2006, Atom Powers wrote: My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. It is definitely your perogative, but I'm curious as to why not? You have the source code for the client, so its not some sort of 'spyware' that is sitting running on your machine ... The over riding question here is not why not but why. A package like this doesn't help the server run faster or better. It is another piece of code that has to be audited and maintained. I take a very minimalist approach to my systems. It takes me 100milliseconds to ping www.freebsd.org. Even if you used FreeBSD for the rest of your natural life you would only use up 72 seconds of it. Is that not a good trade off for what we get in return? -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/29/06, Nikolas Britton [EMAIL PROTECTED] wrote: On 7/29/06, Atom Powers [EMAIL PROTECTED] wrote: On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: On Fri, 28 Jul 2006, Atom Powers wrote: My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. It is definitely your perogative, but I'm curious as to why not? You have the source code for the client, so its not some sort of 'spyware' that is sitting running on your machine ... The over riding question here is not why not but why. A package like this doesn't help the server run faster or better. It is another piece of code that has to be audited and maintained. I take a very minimalist approach to my systems. It takes me 100milliseconds to ping www.freebsd.org. Even if you used FreeBSD for the rest of your natural life you would only use up 72 seconds of it. Is that not a good trade off for what we get in return? What if we find the userbase is very large and vendors take notice and decide to support FreeBSD? This could potential save us thousands of man hours! 100milliseconds OR hours on the phone with vendor support? If the statistics don't have the desired effect we can always back it out later and you will always have the choice to not run the stats client I don't see any bad side effects here. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: Towards that end, as a starter, I would like to encourage everyone out there running 1 or more FreeBSD boxes to go to http://www.mreriksson.net/uptimes register all of your hosts, and install /usr/ports/sysutils/uptimec and get it running ... Heh. You won't get more than a tiny percentage of hosts that way; I believe most of us, even those on this list (which is nowhere close to the total user base), don't care to be listed. My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. -- -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On Fri, 28 Jul 2006, Atom Powers wrote: On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: Towards that end, as a starter, I would like to encourage everyone out there running 1 or more FreeBSD boxes to go to http://www.mreriksson.net/uptimes register all of your hosts, and install /usr/ports/sysutils/uptimec and get it running ... Heh. You won't get more than a tiny percentage of hosts that way; I believe most of us, even those on this list (which is nowhere close to the total user base), don't care to be listed. My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. It is definitely your perogative, but I'm curious as to why not? You have the source code for the client, so its not some sort of 'spyware' that is sitting running on your machine ... I could see if it was some closed-source client ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/28/06, Atom Powers [EMAIL PROTECTED] wrote: On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: Towards that end, as a starter, I would like to encourage everyone out there running 1 or more FreeBSD boxes to go to http://www.mreriksson.net/uptimes register all of your hosts, and install /usr/ports/sysutils/uptimec and get it running ... Heh. You won't get more than a tiny percentage of hosts that way; I believe most of us, even those on this list (which is nowhere close to the total user base), don't care to be listed. My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. What about sending something as simple as uname -mr? uname -mr 6.1-STABLE i386 The only way this idea will work is if we put some code in the base system that sends something generic every few months. for example. Send 'uname -mr' to stats.freebsd.org every 3 months. It would be very easy to 'opt out', perhaps stats_enable=NO in rc.conf. Alternatively we could make it 'opt in' at install time. The installer could add stats_enable=YES to rc.conf when someone answers yes. The actual code to implement this is trivial, something like a few lines of shell script and a config file that lists the next send date. This config file can be checked during the monthly periodic and if needed trigger the stats script to send the anonymous data and update the next send date in the config file. If the stats script can't find a path out it should update the next send date and then die. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
Nikolas Britton [EMAIL PROTECTED] writes: On 7/28/06, Atom Powers [EMAIL PROTECTED] wrote: On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: Towards that end, as a starter, I would like to encourage everyone out there running 1 or more FreeBSD boxes to go to http://www.mreriksson.net/uptimes register all of your hosts, and install /usr/ports/sysutils/uptimec and get it running ... People like me who only use FreeBSD on the laptop would certainly give much shorter uptimes. Okay, I just wanna say, it's very strange to a mobile/desktop user. Heh. You won't get more than a tiny percentage of hosts that way; I believe most of us, even those on this list (which is nowhere close to the total user base), don't care to be listed. My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. What about sending something as simple as uname -mr? uname -mr 6.1-STABLE i386 That's it. The only way this idea will work is if we put some code in the base system that sends something generic every few months. for example. Send 'uname -mr' to stats.freebsd.org every 3 months. It would be very easy to 'opt out', perhaps stats_enable=NO in rc.conf. Alternatively we could make it 'opt in' at install time. The installer could add stats_enable=YES to rc.conf when someone answers yes. The actual code to implement this is trivial, something like a few lines of shell script and a config file that lists the next send date. This config file can be checked during the monthly periodic and if needed trigger the stats script to send the anonymous data and update the next send date in the config file. If the stats script can't find a path out it should update the next send date and then die. We can also collect the access information of the cvsup server and portsnap server, can't we? -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Xiao-Yong ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
- Original Message - From: Nikolas Britton [EMAIL PROTECTED] To: Atom Powers [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org; User Freebsd [EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:39 PM Subject: Re: Gotta start somewhere ... how many of us are really out there? On 7/28/06, Atom Powers [EMAIL PROTECTED] wrote: On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: Towards that end, as a starter, I would like to encourage everyone out there running 1 or more FreeBSD boxes to go to http://www.mreriksson.net/uptimes register all of your hosts, and install /usr/ports/sysutils/uptimec and get it running ... Heh. You won't get more than a tiny percentage of hosts that way; I believe most of us, even those on this list (which is nowhere close to the total user base), don't care to be listed. My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. What about sending something as simple as uname -mr? uname -mr 6.1-STABLE i386 The only way this idea will work is if we put some code in the base system that sends something generic every few months. for example. Send 'uname -mr' to stats.freebsd.org every 3 months. It would be very easy to 'opt out', perhaps stats_enable=NO in rc.conf. Alternatively we could make it 'opt in' at install time. The installer could add stats_enable=YES to rc.conf when someone answers yes. The actual code to implement this is trivial, something like a few lines of shell script and a config file that lists the next send date. This config file can be checked during the monthly periodic and if needed trigger the stats script to send the anonymous data and update the next send date in the config file. If the stats script can't find a path out it should update the next send date and then die. You might think this sounds harmless but folks have done this kind of thing in the past with other products and wreaked havoc on the Internet. You can start by referencing dlink ntp fiasco in google to get an idea of what can happen to these kinds of well meaning attempts. Let sleeping dogs lie. People just don't realize just how very big the Internet is. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 7/28/06, Xiao-Yong Jin [EMAIL PROTECTED] wrote: Nikolas Britton [EMAIL PROTECTED] writes: On 7/28/06, Atom Powers [EMAIL PROTECTED] wrote: On 7/28/06, User Freebsd [EMAIL PROTECTED] wrote: Towards that end, as a starter, I would like to encourage everyone out there running 1 or more FreeBSD boxes to go to http://www.mreriksson.net/uptimes register all of your hosts, and install /usr/ports/sysutils/uptimec and get it running ... People like me who only use FreeBSD on the laptop would certainly give much shorter uptimes. Okay, I just wanna say, it's very strange to a mobile/desktop user. Heh. You won't get more than a tiny percentage of hosts that way; I believe most of us, even those on this list (which is nowhere close to the total user base), don't care to be listed. My shop runs 30+ FreeBSD hosts, and I have several more for personal use. But of those there are maybe 2-3 that I would be ok with listing and exactly zero that I will actually list. It's not that I don't want to help, but I'm not going to run a process like that on a production server. What about sending something as simple as uname -mr? uname -mr 6.1-STABLE i386 That's it. The only way this idea will work is if we put some code in the base system that sends something generic every few months. for example. Send 'uname -mr' to stats.freebsd.org every 3 months. It would be very easy to 'opt out', perhaps stats_enable=NO in rc.conf. Alternatively we could make it 'opt in' at install time. The installer could add stats_enable=YES to rc.conf when someone answers yes. The actual code to implement this is trivial, something like a few lines of shell script and a config file that lists the next send date. This config file can be checked during the monthly periodic and if needed trigger the stats script to send the anonymous data and update the next send date in the config file. If the stats script can't find a path out it should update the next send date and then die. We can also collect the access information of the cvsup server and portsnap server, can't we? Yes and no. Not all cvsup servers are under the control of the FreeBSD project but you are right, they could log the release tag and more. Also don't forget about website stats, mailing list subscriptions, and ftp servers. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
