Jesper,
Nice job.
Can this work be a separate RPM so it can be modified and adjusted
without touching the base SME Server?
If implemented who's in responsible/in charge of the collected data?
Would there be an Opt in/ Opt out option? (Laws)
Thinking out loud here.
-HF
On 10-3-2014 22:22, Jesper Knudsen wrote:
All,
I have now created both the script (Perl) that gathers data on all the
SME servers and also the Backend (PHP, MySQL) that collects and store
the data. Supports SME 7x and 8x (tested) and most likely also 9x.
Currently the data that is collected is:
·InstallEpoch
·ReleaseVersion
·SystemID
The backend also stores the sending IP to make the GeoIP lookups and
some maintenance data (timestamps, etc.).
I would be happy to finish this including the presentation of data
(maybe with help from Tony?) using Google maps and whatever is needed.
I have all the code, so I just need some servers to send relevant data
and we are moving...
Would be useful to use a Contribs.org or Koozali.org URL but I can
also just use my own domain for now. Maybe a DNS A-record called
stats.contribs.org pointing to my server for now and when it has been
debugged and is live it gets migrated to an "official" server?
Anyways, let me know if you would want to fire of the script on your
servers so the DB gets some data to work with.
_To see and try, login into your server and do:_
cd /tmp
wget http://sme.swerts-knudsen.dk/downloads/SMEReport.pl
chmod +x SMEReport.pl
# Manual checkin
./SMEReport.pl -debug
mv SMEReport.pl /etc/cron.weekly
Regards,
Jesper
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of
*Hsing-Foo Wang
*Sent:* 10. marts 2014 16:45
*To:* [email protected]
*Subject:* Re: [discussion] Install statistics for SME Server [SMOLT]
Right, I was looking for the install epoch and there it is ;-)
Now for the GeoIP data? otherwise it would be difficult to map
geographically right?
On 10-3-2014 16:39, Jesper Knudsen wrote:
The config DB seems to have the answers and this could/should
obviously just be reused. The SystemID is generated using
Data::UUID which promises it to be unique. As I see it we have our
data in the database.
# config show sysconfig
sysconfig=configuration
InstallEpoch=1372281536
KeyboardType=pc
Keytable=dk
Language=en_US
PreviousSystemMode=serveronly
Registration=none
ReleaseVersion=8.1
SystemID=d0a6d2e7-f4be-4ebf-ae5a-7507775690ab
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of
*Hsing-Foo Wang
*Sent:* 10. marts 2014 15:40
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [discussion] Install statistics for SME Server [SMOLT]
I hope Shad would be willing to speak up, for he is fully aware
and maintained all 'phone home' and install UUID, EPOCH stuff.
Hopefully it will prevent us from re-inventing the wheel.
On 10-3-2014 15:22, Jesper Knudsen wrote:
I agree that a unique ID would be beneficial in the long run
and would also eliminate discussions on polluted data -- I was
only trying to make a point that we do not need an opt-in for
the suggested data.
I have used the MAC address before for that purpose -- before
VMs it was unique but now we need to combined with something
more. Maybe the UUID for the root device (found via blkid).
f.ex:
/dev/mapper/main-root:
UUID="a41a9845-53be-489b-969c-bee4d387af3d" TYPE="ext3"
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of
*Jonathan Martens
*Sent:* 10. marts 2014 09:58
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [discussion] Install statistics for SME Server
[SMOLT]
On 9-3-2014 23:33, Jesper Knudsen wrote:
The only think that this would "reveal" beyond what a YUM
update does is a unique ID and install date (why do we
need that?). I do not think we need an opt-in for that.
Basically, as long as the data gathering is so simple I do
not even think a unique ID is needed -- we are not looking
for exact science here but marketing number and if a few
servers are behind the same router/IP that will, or should
not, disturb the picture much.
We could and should properly make an opt-in solution if we
decided to gather more detailed (and usefull??) data as I
suggested.
Greetings,
Jesper
Although a unique key does not sound as a requirement for you,
I know it makes extension to the data model much easier, I
think it is not such a big hassle to create one for every
server. I could imagine that in the future we would like to
now the install base on a per version base and would like to
have an update when a machine changes version number for
instance, this would be hard to do without a unique id. In
other words without the unique ID you do not know if you get
duplicates and statistics data is polluted easily, which IMHO
defeats the purpose of this exercise.
Kind regards,
Jonathan
_______________________________________________
Discussion about project organisation and overall direction
To unsubscribe, [email protected]
<mailto:[email protected]>
Searchable archive
athttp://lists.contribs.org/mailman/public/discussion/
_______________________________________________
Discussion about project organisation and overall direction
To unsubscribe, [email protected]
<mailto:[email protected]>
Searchable archive athttp://lists.contribs.org/mailman/public/discussion/
_______________________________________________
Discussion about project organisation and overall direction
To unsubscribe, e-mail [email protected]
Searchable archive at http://lists.contribs.org/mailman/public/discussion/
_______________________________________________
Discussion about project organisation and overall direction
To unsubscribe, e-mail [email protected]
Searchable archive at http://lists.contribs.org/mailman/public/discussion/
