Initial vroiam sa intreb ce parere are lumea de idee, daca este dispusa sa ajute...
Personal cred ca e o idee pozitiva, implementarea ar mai trebui ajustata.
Vezi si mai jos...
On 8/6/06, Ion-Mihai IOnut Tetcu <[EMAIL PROTECTED]> wrote:
Da si nu prea; se mai poate modifica /var/run/dmesg.boot in timp (e.g. mai schimbi o placa). Mai degraba sa fie generat un ID unic la prima rulare si stocat undeva in /var/spool.
E.g.:
uid_file="/var/db/host.uid"
if [ -r "$uid_file" ] ; then
read UID <$uid_file
else
UID=`dd if=/dev/random bs=1 count=16 2>/dev/null | md5`
echo $UID >$uid_file
fi
Hmm, o sa le caut si eu.
Dar tot nu inteleg de ce are nevoie sa ramana acolo, doar ca sa prinda eventualele fault-uri ?
Si daca eu imi schimb adresa de raportare (ceea ce usually I do) ? Ar trebui mai degraba:
monthly_statistics_mailto="[EMAIL PROTECTED],${monthly_statistics_mailto}"
Regards,On Sun, 6 Aug 2006 14:11:25 +0300
"Adrian Penisoara" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Iata o initiativa de a se calcula niste statistici privint
> utilizarea FreeBSD. Poate fi util comunitatii pentru suportul
> comercial, dar trebuie avut grija cum e realizat.
>
> Date: Sun, 6 Aug 2006 03:34:08 +0000 (UTC)
> Subject: cvs commit: ports/sysutils Makefile ports/sysutils/bsdstats
> Log:
> Initial port for bsdstats script
>
> Submitted by: John Nielsen <[EMAIL PROTECTED]>
>
> Package description:
>
> The purpose of this port is to attempt to produce reasonably accurate
> statistics on FreeBSD deployment, to be used for both marketing, and
> advocacy purposes by the project.
>
> The major problem that we are trying to address is vendors who do not
> feel that FreeBSD presents enough of a market to bother supporting.
>
> WWW: http://bsdstats.hub.org
>
>
> sysutils/bsdstats/files/300.statistics:
>
> monthly_statistics_mailto=" [EMAIL PROTECTED],root"
> if [ -r /etc/defaults/periodic.conf ]
> then
> . /etc/defaults/periodic.conf
> source_periodic_confs
> fi
>
> oldmask=$(umask)
> umask 066
>
> case "$monthly_statistics_enable" in
> [Yy][Ee][Ss])
> HN=`/bin/hostname`
> SYS=`/usr/bin/uname -r`
> ARCH=`/usr/bin/uname -m`
> /usr/bin/fetch -qo /tmp/getid
> http://bsdstats.hub.org/scripts/getid.php?hn=$HN\&sys=$SYS\&arch=$ARCH
> ;;
> *) rc=0;;
> esac
>
> umask $oldmask
>
>
> Ce parere aveti ? Imi pare ca cel putin $HN ar trebui modificat sa nu
> contina numele masinii, ci doar domeniul, e.g.:
>
> HN=`hostname -s`
> HN=`hostname | sed -e "s/^${HN}/XXX/"`
>
> Daca se doreste a identifica "unique hists", fie se foloseste IP
> source, fie se poate genera un ID unic in momentul primei executii si
> se adauga la URL-ul din fetch.
Sa detectezi ce sistem de operare e folosit de o masina e relativ usor,
deci nu cred ca e o problema din p.d.v. al securitatii. IP source nu
merge pentru ca sunt destula masini dupa un NAT. Ideea unui id unic
insa mi se pare OK. md5 /var/run/dmesg.boot ?
Da si nu prea; se mai poate modifica /var/run/dmesg.boot in timp (e.g. mai schimbi o placa). Mai degraba sa fie generat un ID unic la prima rulare si stocat undeva in /var/spool.
E.g.:
uid_file="/var/db/host.uid"
if [ -r "$uid_file" ] ; then
read UID <$uid_file
else
UID=`dd if=/dev/random bs=1 count=16 2>/dev/null | md5`
echo $UID >$uid_file
fi
> Si nu am inteles de ce monthly_statistics_mailto contine o adresa
> privata -- testing ?
E al tipului care a pus in practica idea; cred ca sunt niste mailuiri
de la el pe advocacy@ in ultimile 2 saptamani.
Hmm, o sa le caut si eu.
Dar tot nu inteleg de ce are nevoie sa ramana acolo, doar ca sa prinda eventualele fault-uri ?
Si daca eu imi schimb adresa de raportare (ceea ce usually I do) ? Ar trebui mai degraba:
monthly_statistics_mailto="[EMAIL PROTECTED],${monthly_statistics_mailto}"
Adrian Penisoara
Ady (@rofug.ro)
