[Folding@Home] Announce: Client monitor voor Linux

[smoking2000]

Het moest een keer gebeuren, anders gebeurt het nooit. Uitstel leidt tot afstel, zei een wijs persoon ooit eens. Tevens heb ik de release-policy van de 1.0 release van FCI afgekeken van Debian: "Release when it's ready".

FCI v1.8.4 is uit! En staat op de download pagina.

"And there was much rejoicing."

Voor Fatal Error Group draai ik de 1.x code al tijden voor onze FCI server (IPv6), waar je het in actie kunt zien.

New and Improved in Folding@Home Client Info v1.x:

• Client-side
  • De meest informatieve F@H client files, via fci-client.pl
  • Inhoud van de queue.dat, via fci-client.pl icm qd's XML output
  • Betere Operating System detectie
  • Supported OSes: Linux (Debian, Ubuntu, Fedora, CentOS, Gentoo, Arch, Slackware, Mandriva, OpenSUSE), FreeBSD, OpenBSD, Mac OS X & Windows (XP, Vista)
• Server-side
  • XML backend, voor diverse client- en server-side tools
  • De mod_perl webapp is veel efficiënter door modularisatie
  • Scheduling van specifieke scripts ipv real-time parsing bij elke request naar de website
  • Backwardscompatible met fci-clients >= v0.5.5
  • Automatische archivering van project images via de geuploade current.xyz files
  • Gebruik van de extra info beschikbaar in de andere clients files
  • PPD informatie op verschillende niveaus
  • PPD grafieken van de WUs in de queue.dat
  • Time Per Frame informatie
  • Gebruik van EXTREME Overclocking Folding@Home Stats XML user summaries
  • Links naar fahstats.com user summaries
  • Supported OSes: Linux (Debian, Ubuntu, Fedora, CentOS, Gentoo, Arch, Slackware, Mandriva), FreeBSD & OpenBSD

En meer!

Er zijn een aantal Perl modules nodig om FCI te draaien en te installeren, maar dit staat gedocumenteerd.
Er is ook een installer, install.pl. Na het installeren van de Perl modules kan je de FCI client installeren met:

code:

perl install.pl --client

Meer informatie voor de gesupported OSen staat in hun individuele INSTALL file:

• Linux (Debian, Mepis, Ubuntu, Fedora, CentOS, Gentoo, Arch, Slackware, Mandriva, OpenSUSE),
• FreeBSD,
• OpenBSD,
• Mac OS X &
• Windows (XP, Vista, 7)

Voor hulp, vragen, suggesties, patches, en meer. Laat het me weten, en ik implementeer het in de volgende release.

Onderstaande posts zijn nog gemaakt ten tijde van de 0.x branche van FCI, gebruik deze link om direct naar de eerste post met betrekking tot de 1.x branche te navigeren.

[Voor 237% gewijzigd door smoking2000 op 13-01-2012 13:56. Reden: v1.8.4]

[SandStar]

Ik ga het dit weekend meteen uitproberen

[Tootoo]

Ik moet nog even 3 maandjes wachten, dan ga ik het ook zeker eens uitproberen Op mijn laptop stond linux, maar reisferfs is 2 dagen geleden gecrashed. Resultaat: reinstall en gezien ik geen cds bij me had (alleen een cd voor ftp installatie, geen optie hier met max 40 kB/s download) is het nu windows geworden...

Maar ik hou het in de gaten en het ziet er leuk uit! Keep up the good work

[smoking2000]

Nieuwe versie gereleased:
fci-0.1.2
2005-01-29

* TODO: created todo list
* README: added url to fci announcement at Gathering of Tweakers and add contact email
* INSTALL: rewrote permission related part in the Server Installation part
* www/index.pl: rewrote permission check routines and small fixes
* www/client-data/: set correct permission for fresh installs
* client/fci-client.pl: small fixes
* helper-scripts/download-stanford-files.pl: small fixes

Tevens is de demo site nu gemirrored op een server met wat meer CPU power, wat wel nodig is als de 2 stats files van Stanford real-time geparsed worden.
In v0.2 komt de mogelijkheid om statische html paginas te genereren ipv het load intensive real-time mod_perl script.

[SandStar]

Wat voor server raad je aan?

Ik gebruik momenteel een P3 540 met 640mb ram als server. Maar als ik hoor dat het best intensief kan zijn vraag ik mij of hoe mn server dat gaat trekken...

[smoking2000]

ik draai het zelf op een AMD 2400+/1280MB, daar draait het prima real-time op.
De server waar de site op draait is een PIII 500/768MB, en dat is best intensief (enkele seconden wachten op pagina waar de stanford pagina's voor geparsed moesten worden (usernames, teams)).
Iets ala 1 Ghz zou ook nog best ala minute de pagina's real-time moeten kunnen genereren.

Probeer het eens uit zou ik zeggen, ik kan verder niet goed beoordelen wat nodig is. Meer testdata kan ik goed gebruiken

V0.2 kan je binnen 2 maanden uiterlijk verwachten, daar zal dit probleem in getackeled worden.

[smoking2000]

SandStar schreef op zondag 30 januari 2005 @ 20:51:
Wat voor server raad je aan?

Ik gebruik momenteel een P3 540 met 640mb ram als server. Maar als ik hoor dat het best intensief kan zijn vraag ik mij of hoe mn server dat gaat trekken...

2 maanden was de deadline die ik mezelf gesteld had, maar gister heb ik het script geschreven en vandaag is het echt klaar, iets eerder dan geplanned

Statische HTML is nu dus ook mogelijk

Ik heb het getest met een site waar 2 clients hun gegevens naar hebben geupload, met 2 verschillende usernames in hetzelfde team. Server: PIII 500Mhz, 768 MB RAM.
Voorheen deed een de server er 30 sec. over om de Usernames pagina real-time te genereren, en 20 sec. om de Gedetailleerde Username pagina real-time te genereren. (Deze zijn het meest load intensief)
Het script doet er 50 sec. over om de gehele site te converteren naar html.

De release:
fci-0.2
2005-02-01

* TODO: updated
* README: fixed typo
* INSTALL: add section for generating static html pages
* www/teams.plc: fixed username url
* helper-scripts/create-static-html-from-mod_perl.pl: created script to save the static html to disc

[SandStar]

http://pr0ner.no-ip.org/folding/index.pl

Working

Morgen ff static html versie uitproberen
en clients toe gaan voegen...

prachtig programma!

edit: 2e client toegevoegd, wel te merken in load...
static html eerst maar toevoegen en daarna rest van clients

benieuwd of ik het ook op windows bakken aan praat krijg

[Voor 37% gewijzigd door SandStar op 07-02-2005 00:39]

[smoking2000]

SandStar schreef op maandag 07 februari 2005 @ 00:19:
http://pr0ner.no-ip.org/folding/index.pl

Working

Morgen ff static html versie uitproberen
en clients toe gaan voegen...

prachtig programma!

edit: 2e client toegevoegd, wel te merken in load...
static html eerst maar toevoegen en daarna rest van clients

benieuwd of ik het ook op windows bakken aan praat krijg

Thanks!

Ik kan alvast verklappen dat in v0.3 waar ik atm mee bezig ben ook de mogelijkheid zit om je queue.dat te parsen, dmv qd.
Dit zal er wel voor zorgen dat de client niet meer onder Windows zal werken in eerste instantie, later zal in de windows versie van qd ook integreren.

In principe hoef je alleen het path naar de betreffende files te weizigen naar "the Windows way", om het onder Windows met ActivePerl of Cygwin te laten werken. Dit kan of door het script te editten of dmv commandline parameters.
In v0.3 of later wil ik dit in een configuratie parameter oid plaatsen, of gewoon met een aparte Windows release, zodat het "out of the box" werkt.

_{Mental note: wacht met posten als je net je bed uitgerolt bent}

[Voor 24% gewijzigd door smoking2000 op 07-02-2005 11:20]

[SandStar]

smoking2000 schreef op maandag 07 februari 2005 @ 07:22:
[...]

Thanks!

Ik kan alvast verklappen dat in v0.3 waar ik atm mee bezig ben ook de mogelijkheid zit om je queue.dat te parsen, dmv qd.
Dit zal er wel voor zorgen dat de client niet meer onder Windows zal werken in eerste instantie, later zal in de windows versie van qd ook integreren.

In principe hoef je alleen het path naar de betreffende files te weizigen naar "the Windows way", om het onder Windows met ActivePerl of Cygwin te laten werken. Dit kan of door het script te editten of dmv commandline parameters.
In v0.3 of later wil ik dit in een configuratie parameter oid plaatsen, of gewoon met een aparte Windows release, zodat het "out of the box" werkt.

_{Mental note: wacht met posten als je net je bed uitgerolt bent}

Dus voor windows alleen ActivePerl nodig? Daar zitten die losse zooi zoals Getopt::Mixed in?

Ik ga morgenavond mn windows clients toevoegen

[smoking2000]

SandStar schreef op maandag 07 februari 2005 @ 17:36:
[...]


Dus voor windows alleen ActivePerl nodig? Daar zitten die losse zooi zoals Getopt::Mixed in?

Ik ga morgenavond mn windows clients toevoegen

Ik weet niet welke modules er standaard in ActivePerl zit, maar ik neem aan niet meer dan een UNIX installatie van Perl. Dus de non-standard modules als GetOpt::Mixed zal je nog even van CPAN moeten halen en compileren.

[smoking2000]

Nieuwe versie gereleased:
fci-0.3

* qd geintegreerd met fci-client.pl voor het parsen van queue.dat en server-side de parsing van de qd output toegevoegd, verder weinig spannende ontwikkelingen

[SandStar]

smoking2000 schreef op maandag 07 februari 2005 @ 19:45:
[...]

Ik weet niet welke modules er standaard in ActivePerl zit, maar ik neem aan niet meer dan een UNIX installatie van Perl. Dus de non-standard modules als GetOpt::Mixed zal je nog even van CPAN moeten halen en compileren.

compilen voor windows... das iets nieuws...
* SandStar opent google maar

[SandStar]

Is het misschien een idee om in een volgende release een kleine beveiliging in te bouwen dat niet iedereen zn stats op je server kan dumpen? Dat je clients een '--password ****' meesturen ofzow.

De load valt wonderbaarlijk mee! Ik draai het nog steeds op een P3 540Mhz met 640MB ram en zo'n 6 clients en het is met realtime perl nog prima te doen. In het begin was het pittig traag maar hij lijkt te boel lekker te cachen ofzow...

Windows clients toevoegen ben ik nog niet aan toegekomen, wel uitgevonden hoe het zou moeten werken. Gaan we vanavond aan werken.

Ook maar ff upgraden van 0.2 naar 0.4

[smoking2000]

SandStar schreef op donderdag 10 februari 2005 @ 15:32:
Is het misschien een idee om in een volgende release een kleine beveiliging in te bouwen dat niet iedereen zn stats op je server kan dumpen? Dat je clients een '--password ****' meesturen ofzow.

De load valt wonderbaarlijk mee! Ik draai het nog steeds op een P3 540Mhz met 640MB ram en zo'n 6 clients en het is met realtime perl nog prima te doen. In het begin was het pittig traag maar hij lijkt te boel lekker te cachen ofzow...

Windows clients toevoegen ben ik nog niet aan toegekomen, wel uitgevonden hoe het zou moeten werken. Gaan we vanavond aan werken.

Ook maar ff upgraden van 0.2 naar 0.4

HTTP Auth & SSL staan in de TODO, dit wil ik als eerst gaan implementeren. Zat ik gister aan te denken (great minds think alink )

Is een minimale aanpassing, maar ik wil het beheer makkelijker maken met een configure frontend, waar dit ook in komt te hangen.

Even snel een side note: 0.4 is een beetje snel gereleased, het kan zijn dat hier en daar nog kleine dingen niet helemaal correct zitten. Hier bedoel ik voornamelijk de permissie check op de server.

Tevens de meegeleverde qd alleen voor Linux, maar ook hier geldt met een minimale aanpassing moet ook de Windows binary werken.

Thanks voor het meedenken, en ik verwacht 0.5 eind volgende week oid, iig HTTP auth moet dan mogelijk zijn, SSL kan wat langer op zich laten wachten.

[SandStar]

unitinfo.txt = Name: p1140_RIBO_FSpeptide_EXT
psummary = p1140_RIBO_FSpeptide_EXT_nospring

ook iets op te vinden?

edit:
windows client aan de praat gekregen (l4gg3r)

[Voor 38% gewijzigd door SandStar op 10-02-2005 21:07]

[smoking2000]

Hmmm... dat zou afgavangen moeten zijn op regel 411:

code:

elsif($name ne '' && $wu_name =~ /^$name/) {

$wu_name is hier p1140_RIBO_FSpeptide_EXT_nospring en $name is hier p1140_RIBO_FSpeptide_EXT, de regex zou hem moeten pakken...

Zou je kunnen kijken of je de bovenstaande regel daadwerkelijk in index.pl hebt staan in de subrouting parse_psummary().
Ik heb namelijk wel een paar bugs gefixt en opnieuw gereleased als 0.2 ipv het te releases als een nieuwe bugfix release, misschien dat je nog een oude 0.2 hebt...

[update]
Ik heb net even in je client-data/project-list gekeken en daar staat het volgende in:

code:

p1134_RIBO_FSpeptide_EXT:pr0ner
p874_p53dimer874:c4mp3r
p1801_Collagen_PPG10_refolding:tux
p1122_ribo_solvent2:Apollo
p874_p53dimer874:Zeus-1
p1801_Collagen_PPG10_refolding:Zeus-2
:l4gg3r

Om de een of andere reden heeft de server de projectname niet opgeslagen bij het uploaden. Misschien was het project nog niet in de psummary.html van Stanford toe het werdt geupload?

Een tijdelijke fix is om zelf even client-data/project-list aan te passen, door de regel

code:

:l4gg3r

te vervangen met

code:

p1140_RIBO_FSpeptide_EXT_nospring:l4gg3r

Maar de kans is groot dat bij de volgende upload die regel weer fout gegenereerd wordt. Als het bovenstaande probleem niet van toepassing is.

Een iets betere oplossing is de de volgende regel toe te voegen aan generate_project_list() in index.pl

code:

$wu_info{wu_name} = $unitinfo{name} if(!$wu_info{wu_name});

net boven de regel

code:

$data .= "$wu_info{wu_name}:$client\n";

[/update]

[Voor 52% gewijzigd door smoking2000 op 11-02-2005 07:39]

[smoking2000]

v0.5 released
fci-0.5

Nu met bugfixes, authenticatie en configuratie interface

[SandStar]

We hebben weer wat te doen morgenavond

[smoking2000]

v0.5.1 released
fci-0.5.1

Er zat een nare bug in het script wat van de dynamische pagina's static html maakt.
De URL werden niet goed herschreven, waardoor de halve site vol zat met broken links

[SandStar]

wil niet

http://pr0ner.no-ip.org/folding/index.pl

als ik naar clients ga zie ik ten eerste niet waar ze mee bezig zijn en ten tweede als ik daar via een omweg wel ben zie ik alleen maar een opsomming van de files .xyz etc etc

wat doe ik verkeerd?

[smoking2000]

SandStar schreef op woensdag 16 februari 2005 @ 18:47:
wil niet

http://pr0ner.no-ip.org/folding/index.pl

als ik naar clients ga zie ik ten eerste niet waar ze mee bezig zijn en ten tweede als ik daar via een omweg wel ben zie ik alleen maar een opsomming van de files .xyz etc etc

wat doe ik verkeerd?

Je doet niets verkeerd, ik heb per ongeluk www/clients.plc overschreven met www/settings/clients.plc.
De clients.plc die er nu stond was dus die uit de configuratie interface, en niet de normale.

Ik heb het meteen gefixt: fci-0.5.2

[SandStar]

windows systeem:

Error: cannot read xyz file

Verwijzing gaat ergens niet goed denk ik... misschien optie om xyz upload te disablen als het niet gaat werken op windows clients?

edit 1:
En met deze gaat ie op zn bek bij "cannot read client directory"
fci-client.pl --url http://pr0ner.no-ip.org/folding/index.pl --client l4gg3r --dir "C:\Program Files\FAH\" --config "C:\Program Files\FAH\client.cfg" --unitinfo "C:\Program Files\FAH\unitinfo.txt"

Werkte nog bij 0.2

edit 2:

code:

$cfg{unitinfo_file} = $cfg{folding_dir}.'unitinfo.txt';
$cfg{config_file}   = $cfg{folding_dir}.'client.cfg';
$cfg{xyz_file}      = $cfg{folding_dir}.'/work/current.xyz';

# get command line parameters
Getopt::Mixed::init("url=s client=s dir=s config=s unitinfo=s xyz=s useragent=s username=s password=s verbose help update-qd qd-url=s");
while (my ($option, $value) = nextOption()) {
    if($option eq 'help') {
        print_usage();
        Getopt::Mixed::cleanup();
        exit;
    }
    if($option eq 'dir') {
        $cfg{folding_dir} = $value;

        $cfg{unitinfo_file} = $cfg{folding_dir}.'unitinfo.txt';
        $cfg{config_file}   = $cfg{folding_dir}.'client.cfg';
        $cfg{xyz_file}      = $cfg{folding_dir}.'/work/current.xyz';

en zo doet ie het weer wel.
/work ipv work gedaan....
en met:

code:

--dir "C:\Program Files\FAH"

Hoewel het parsen van unitinfo.txt nog steeds niet lekker gaat denk ik... zie site

[Voor 113% gewijzigd door SandStar op 16-02-2005 23:29]

[smoking2000]

l4gg3r was 1 van je Windows machines toch?

Dan denk ik dat ik al weet wat er aan de hand is, met het parsen van de files hield ik geen rekening met het feit dat Windows \r\n als linefeed character gebruikt waar Linux slecht \n gebruikt.

Ik heb de subroutines aangepast, en een nieuwe index.pl online gezet, zou je deze willen uitproberen?
index.pl.gz

Je zal wel even op l4gg3r opnieuw fci-client.pl moet runnen, de routines die ik heb aangepast worden namelijk aangeroepen bij een nieuwe upload.

[Voor 16% gewijzigd door smoking2000 op 17-02-2005 10:37. Reden: extra info]

[SandStar]

smoking2000 schreef op donderdag 17 februari 2005 @ 07:42:
l4gg3r was 1 van je Windows machines toch?

Dan denk ik dat ik al weet wat er aan de hand is, met het parsen van de files hield ik geen rekening met het feit dat Windows \r\n als linefeed character gebruikt waar Linux slecht \n gebruikt.

Ik heb de subroutines aangepast, en een nieuwe index.pl online gezet, zou je deze willen uitproberen?
index.pl.gz

Je zal wel even op l4gg3r opnieuw fci-client.pl moet runnen, de routines die ik heb aangepast worden namelijk aangeroepen bij een nieuwe upload.

Fixed

[smoking2000]

* smoking2000 huppeld blij rond dat het werkt

Meteen maar een nieuwe bugfix-release uitgebracht: fci-0.5.3

[Voor 56% gewijzigd door smoking2000 op 17-02-2005 13:56]

[SandStar]

smoking2000 schreef op donderdag 17 februari 2005 @ 13:46:
* smoking2000 huppeld blij rond dat het werkt

Meteen maar een nieuwe bugfix-release uitgebracht: fci-0.5.3

Ik zie net dat je de wijziging omtrend /work/yxz ipv work/xyz niet hebt doorgevoerd.
Zonder dit werkt het niet op windows clients....
Of misschien heb je het wel doorgevoerd maar de datum op fci-client.pl is nog steeds hetzelfde.

Ik weet alleen niet of die verandering een nadelig effect heeft op *nix clients....

[SandStar]

Iets anders:
qd heeft dus om de zoveel tijd een nieuwe .dat file nodig en de client heeft de optie om dit ook te downloaden.
Is het reëel om dit elk uur te laten doen, net als de client updates, of is het verstandig om dit als een dagelijkse taak te laten runnen. Ik kan me voorstellen dat het na een tijdje pittig wat bandbreedte gaat trekken voor de host.
Idee misschien om dan de server waar fci op draait zelf een mirror te laten draaien van de .dat file? Zo beperk je een beetje de load op andermans server...

[smoking2000]

SandStar schreef op donderdag 17 februari 2005 @ 15:06:
[...]
Ik zie net dat je de wijziging omtrend /work/yxz ipv work/xyz niet hebt doorgevoerd.
Zonder dit werkt het niet op windows clients....
Of misschien heb je het wel doorgevoerd maar de datum op fci-client.pl is nog steeds hetzelfde.

Ik weet alleen niet of die verandering een nadelig effect heeft op *nix clients....

Ik heb uberhaupt nog geen veranderingen doorgevoerd welke specifiek voor Windows clients zijn. Ik wil twee releases voor fci-client.pl maken, een Windows en Linux release.
Zo moet er bijvoorbeeld een andere binary van qd meegeleverd worden per OS, en moeten de directory paths in het OS speciefieke formaat, \ als separator onder Windows en / onder Linux enz.
Er wordt aan gewerkt

SandStar schreef op donderdag 17 februari 2005 @ 15:39:
Iets anders:
qd heeft dus om de zoveel tijd een nieuwe .dat file nodig en de client heeft de optie om dit ook te downloaden.
Is het reëel om dit elk uur te laten doen, net als de client updates, of is het verstandig om dit als een dagelijkse taak te laten runnen. Ik kan me voorstellen dat het na een tijdje pittig wat bandbreedte gaat trekken voor de host.
Idee misschien om dan de server waar fci op draait zelf een mirror te laten draaien van de .dat file? Zo beperk je een beetje de load op andermans server...

Exact hierover heb ik gesproken met Dick Howell, de autheur van qd, hij heeft mij gevraagt om maximaal een paar keer per dag de beschikbaarheid van een nieuwe versie te checken, gezien de site op zijn DSL verbinding gehost wordt.
Om die reden heb ik ook geen auto-update functie ingebouwt, wat ik wel wou, maar het als manual update heb gelaten.
Hij heeft wel een aanbod staan van Wiebo Westerhof om zijn files te mirroren op de folding-community site, mocht een autoupdate functie waardevol genoeg zijn wil hij daar best op ingaan. Ik denk persoonlijk dat dit niet nodig is, omdat er niet zo drastisch vaak een nieuwe update is.

Hij released automatisch een nieuwe release van qd en qdinfo.dat als zijn script een verandering in de psummaryC.html detecteerd. qdinfo.dat is slecht een tabel met de info uit die html file, exact die infomatie staat ook in de source van qd. Dus qd zou niet perse geupdate hoeven worden, tenzij er een grote verandering is en er een nieuwe "funcional revision" uitkomt. Als er geen nieuwe "funtional revision" release is, is slechts een geupdate versie van de qdinfo.dat gemaakt en is tevens diezelfde informatie geupdate in qd.

Momenteel download fci-client.pl zowel qd, als qdinfo.dat als je fci-client.pl runt met de --update-qd parameter. Dit wordt iig veranderd zodat alleen qdinfo.dat wordt gedownload, tenzij een nieuwe functional revision is, dan zal ook qd gedownload worden. Tevens bespaard deze aanpak bandbreedte gezien qdinfo.dat een redelijk kleine file is. Dit wil ik centraal gaan regelen, zodat niet elke fci-client.pl zijn server hoeft te belasten.

Persoonlijk vind ik het geen probleem om mijn client fijn te laten draaien, en zodra ik merk dat er informatie mist in de output van qd, om dan handmatig even een update te draaien.
Daarintegen ben ik wel op de hoogte van de fijne details van de code die de verwerking van die output handled, waardoor ik beter inzicht heb wanneer een update nodig is. Dus dit is niet een oplossing die voor iedereen zal werken.

Ik ben er nog niet helemaal uit hoe ik dit wil oplossen. Ik denk dat ik een script op de fci server laat draaien welke dagelijks checkt of er een nieuwe versie is, en indien dat het geval de benodigde files download, fci-client.pl zal ik dan de fci server laten checken ipv degeen die qd host.
Als ik merk dat fci zo veel gebruikt wordt dat de fci server er onder gaat lijden (welke op een 8Mbit/1Mbit DSL lijn van een van de founders van Fatal Error Group gehost wordt), dan zal ik met Dick overleggen of hij toch zijn files zou willen mirroren op folding-community.
Maar tot die tijd vind ik dat ik hem niet kan opzadelen met extra bandbreedte gebruik of andersinds, alleen omdat ik besloten heb om zijn programma in die van mij te gebruiken.

Dit alles wil ik in v0.6 geregeld hebben, iig het Windows/Linux client verhaal.

[SandStar]

Ah das duidelijke taal!

En ik doelde op een update functie op de server waar de clients naartoe reporten en niet zozeer jouw server. Dus dat mn eigen server checked voor updates van qd en deze doorgeeft aan zijn eigen clients.

Morgen weer een lading clients toevoegen... Tot nu toe doet mn P3 540mhz het nog prima met realtime perl

[smoking2000]

fci-0.6 released.

* fci-client.pl zou nu ook onder Windows moeten werken met de --windows parameter. (note: niet kunnen test bij gebrek aan Windows machines in mijn netwerk)
* Herschreven qd update routines, efficientere downloads, de qd files worden nu op de fci-server gedownload waarvan de clients op hun beurt weer updaten, naar aanleiding van Sandstar's suggestie
* qd files update script toegevoegd in de configuratie interface
* download-qd-file.pl script toegevoegt voor automatische updates, max. 1x per dag svp.

[Voor 18% gewijzigd door smoking2000 op 19-02-2005 00:29. Reden: download-qd-file.pl vergeten]

[SandStar]

Mijn zondagmiddag is weer gevuld
Ziet er weer veelbelovend uit!

[SandStar]

code:

[05:06:31] - Calling './FahCore_96.exe -dir work/ -suffix 05 -checkpoint 15 -forceasm -verbose -lifeline 6355 -version 502'

[05:06:31]
[05:06:31] *------------------------------*
[05:06:31] Folding@Home QMD Core
[05:06:31] Version 1.00 (Jan 14, 2005)
[05:06:31]
[05:06:31] Preparing to commence simulation
[05:06:31] - Assembly optimizations manually forced on.
[05:06:31] - Not checking prior termination.
[05:06:31] - Expanded 104467 -> 331637 (decompressed 317.4 percent)
[05:06:31]
[05:06:31] Project: 1900 (Run 0, Clone 6, Gen 0)
[05:06:31]
[05:06:31] Entering M.D.
[05:07:27] Protein: p1900_32_water_molecules

Nieuwe core @ Folding@home
Momenteel heeft mn server (c4mp3r) er 1 te pakken...
Wordt alleen 'nog' niet herkend door fci

Als je meer info wilt over die core moet je ff gil geven hier op mailen....

[smoking2000]

Waar miste je de info van/over deze core?

fci zelf haalt die info namelijk nergens vandaan, dat wordt door qd uit je queue.dat file of een van de andere files in work directory gehaalt.

Ik heb ff gekeken op je fci pagina, het ziet er nu goed uit.

[SandStar]

smoking2000 schreef op zondag 20 februari 2005 @ 15:38:
Waar miste je de info van/over deze core?

fci zelf haalt die info namelijk nergens vandaan, dat wordt door qd uit je queue.dat file of een van de andere files in work directory gehaalt.

Ik heb ff gekeken op je fci pagina, het ziet er nu goed uit.

Check c4mp3r, deze staat al uren op 100%
Maar als je verder klikt en de qd output bekijkt zie je iets heel anders....

code:

ndex 5  (Current) 

 Status :   folding now 
 Progress   :   3%  
 Expected   :   Wed Feb 23 17:15:27 2005    
 Project    :   1900    
 Speed  :   5.48 times minimum required speed   

    
 Server :   171.64.122.113:8080 
 Work Unit  :   p1900_32_water_molecules    
 Type   :   Folding@Home    
 WU Info    :   Folding: run 0, clone 6, generation 0   
 Benchmark  :   98  
 Miscellaneous  :   500, 300    
    
 Issued :   Sun Feb 20 06:06:05 2005    
 Begun  :   Sun Feb 20 06:06:07 2005    
 Expected   :   Wed Feb 23 17:15:27 2005    
 Expires    :   Fri Mar 11 06:06:07 2005 (19 days)  
    
 Core URL   :   http://www.stanford.edu/~pande/Linux/x86/beta/Core_96.fah (V1.00)   
    
 Collection Server  :   171.65.103.100  
 Packet Size Limit  :   5241856 bytes   
    
 Username   :   SandStar    
 Team   :   92 - Dutch Power Cows   
 ID :   223C3CE75DB6604A    
 Machine ID :   1   
    
 WU Filename    :   work/wudata_05.dat  
 WU Filesize    :   104979  
    
 Assignment Info    
 Byte Order :   little-endian (le)  
 Timestamp  :   Sun Feb 20 06:06:05 2005    
 Checksum   :   A2F3EAB3

[Voor 51% gewijzigd door SandStar op 20-02-2005 15:43]

[smoking2000]

Wat staat er in de unitinfo.txt van c4mp3r in de Folding@Home client directory?

Als dat hetzelfde is als wat er in client-data/unitinfo.c4mp3r staat is er niets aan de hand en heeft je client nog geen nieuwe unitinfo.txt geschreven.

Is de content anders, verwijder de file client-data/unitinfo.c4mp3r en doe een nieuwe upload. Je zou ook kunnen kijken of de permissies goed zijn, de file en directory zouden writable moeten zijn voor de Apache daemon.

[SandStar]

smoking2000 schreef op zondag 20 februari 2005 @ 17:50:
Wat staat er in de unitinfo.txt van c4mp3r in de Folding@Home client directory?

Als dat hetzelfde is als wat er in client-data/unitinfo.c4mp3r staat is er niets aan de hand en heeft je client nog geen nieuwe unitinfo.txt geschreven.

Is de content anders, verwijder de file client-data/unitinfo.c4mp3r en doe een nieuwe upload. Je zou ook kunnen kijken of de permissies goed zijn, de file en directory zouden writable moeten zijn voor de Apache daemon.

nieuwe core maakt nog geen unitinfo.txt aan. Bug gemeld bij stanford
Ligt idd niet aan jouw programma.

[Tootoo]

Het lijkt erop dat jullie 2 dit topic soort van beheersen geloof ik

[Schapie]

Het is dat ik geen beschikking heb over een werkende linux webserver (en de ervaring om dit op tezetten) anders had ik het ook al gedaan ziet er namelijk erg netjes uit.

Ik zal dit topic blijven volgen (deed ik al sinds het begin) en als ik weer wat tijd heb om in mijn linux bak te steken zal ik hier ook eens mee gaan experimenteren.

(Gebruik nu btw dcmonitor dit is een windows based monitor. Het mooie hiervan is dat de html pagina's die deze genereert precies op het scherm van mijn oude ipaq passen. (accu is overleden))

[SandStar]

Ik ga eens kijken of ik mn server een beetje kan upgraden...

Dan kan ik misschien mn server wel voor dpc leden openstellen

[smoking2000]

Tootoo schreef op zondag 20 februari 2005 @ 21:51:
Het lijkt erop dat jullie 2 dit topic soort van beheersen geloof ik

Het topic is lichtelijk ontwikkeld tot support channel

Schapie schreef op zondag 20 februari 2005 @ 22:15:
Het is dat ik geen beschikking heb over een werkende linux webserver (en de ervaring om dit op tezetten) anders had ik het ook al gedaan ziet er namelijk erg netjes uit.

Ik zal dit topic blijven volgen (deed ik al sinds het begin) en als ik weer wat tijd heb om in mijn linux bak te steken zal ik hier ook eens mee gaan experimenteren.

(Gebruik nu btw dcmonitor dit is een windows based monitor. Het mooie hiervan is dat de html pagina's die deze genereert precies op het scherm van mijn oude ipaq passen. (accu is overleden))

Dat is misschien wel een goed idee, een optie inbouwen voor een pda en/of textonly browser vriendelijke webpagina's.
Momenteel ben ik bezig met de HTTP handler te herschrijven, voor betere onderhoudbaarheid, fault-tolerance en bug gevoeligheid

SandStar schreef op zondag 20 februari 2005 @ 23:18:
Ik ga eens kijken of ik mn server een beetje kan upgraden...

Dan kan ik misschien mn server wel voor dpc leden openstellen

Werkt de --windows optie naar behoeve in de nieuwe fci-client.pl of heb ik toch nog iets over het hoofd gezien bij het compatible maken met Windows?

[SandStar]

ik was zondag nog een beetje brak om er echt voor te gaan zitten ben ik bang...
Als ik vanavond klaar ben met werken ga ik een poging wagen

[SandStar]

Error: Invalid URL or HTTP error! <http://pr0ner.no-ip.org/folding/index.plqd-files/qdinfo.dat>

Er mist dus ergens een "/"

(windows client dus met --windows)

code:

if($option eq 'url') {
        $cfg{url}       = $value;
        $cfg{qd_url}        = $cfg{url}.'/qd-files/';
        $cfg{url}          .= 'index.pl';
    }

Als ik em zo aanpas werkt ie wel maar komen we bij volgende error:

Cannot write file! <C:\Program Files\FAH\qdinfo.dat>
Cannot read file! <C:\Program Files\qdinfo.dat>

er wordt blijkbaar niets gedownload

En als ik de --update-qd eruit laat wordt het nog erger:

Cannot read Folding@Home client directory! <C:\Program Files\Folding@Home\>

Terwijl ik run met: --dir "C:\Program Files\FAH"

Verander ik dit in: --dir "C:\Program Files\FAH\"

Error: Cannot read Folding@Home client directory! <C:\Program Files\FAH" --config C:\Program>

[Voor 126% gewijzigd door SandStar op 22-02-2005 17:00]

[smoking2000]

Wat is het exacte commando waarmee je fci-client.pl aanroept, dus inclusief command-line parameters?

De volgorde van parameters is namelijk ook van belang bij het parsen ervan.

Ik ga er zodra ik thuis kom, diepgaander naar kijken.

[SandStar]

fci-client.pl --url http://pr0ner.no-ip.org/folding --client l4gg3r --dir "C:\Program Files\FAH" --config "C:\Program Files\FAH\client.cfg" --unitinfo "C:\Program Files\FAH\unitinfo.txt" --username ****** --password ***** --update-qd --windows --verbose

Ik merkte ook dat ik -url http://pr0ner.no-ip.org/folding/index.pl moest veranderen omdat de client zelf "index.pl" erachter knalt.

[smoking2000]

SandStar schreef op dinsdag 22 februari 2005 @ 17:24:
fci-client.pl --url http://pr0ner.no-ip.org/folding --client l4gg3r --dir "C:\Program Files\FAH" --config "C:\Program Files\FAH\client.cfg" --unitinfo "C:\Program Files\FAH\unitinfo.txt" --username ****** --password ***** --update-qd --windows --verbose

Ik merkte ook dat ik -url http://pr0ner.no-ip.org/folding/index.pl moest veranderen omdat de client zelf "index.pl" erachter knalt.

De GetOpts::Mixed module parsed hier de parameters niet helemaal goed, en gaat nat op de quotes.

In de source van Mixed.pm kan ik niet echt iets vinden wat het zou kunnen veroorzaken, de code handled quotes verder prima.

Ik heb ook nog door de ActiveState Programmer Network gezocht, of hier iets over te vinden is maar helaas.

Ik zal morgen op mn werk even een XP bak voorzien van Perl om het zelf te testen.

De cannot read/write file, zijn best straight forward, de rechten staan echt goed?

[SandStar]

smoking2000 schreef op dinsdag 22 februari 2005 @ 20:49:
[...]

De GetOpts::Mixed module parsed hier de parameters niet helemaal goed, en gaat nat op de quotes.

In de source van Mixed.pm kan ik niet echt iets vinden wat het zou kunnen veroorzaken, de code handled quotes verder prima.

Ik heb ook nog door de ActiveState Programmer Network gezocht, of hier iets over te vinden is maar helaas.

Ik zal morgen op mn werk even een XP bak voorzien van Perl om het zelf te testen.

De cannot read/write file, zijn best straight forward, de rechten staan echt goed?

rechten op een XP bak? ik log remote in als administrator dus dat moet goed gaan....

[smoking2000]

Met betrekking tot het quotes issue, als je --dir "C:\Program Files\FAH\\" gebruikt werkt het wel, de dubbele backslash wordt geinterpreteerd als zijnde 1 backslash.

Ik ga fci-client.pl aanpassen zodat je niet expliciet de laatste directorydelimiter hoeft aan te geven, maar dat deze door de client wordt toegevoegt als de bestandsnamen samengesteld worden.
Tevens zal ik de URL handling aanpassen zodat je weer gewoon de volledige URL inclusief index.pl moet gebruiken, wat duidelijker is voor de gebruikers. In de code zal ik qd-url samenstelling anders afhandelen.

Met betrekking tot de read/write issues, de betreffende user moet full control over de directory hebben om het te laten werken. Dit schijnt een bekend issue te zijn met Perl onder Windows.

Vanavond heb ik een nieuwe versie online, waarin de quotes issue en de qd-update issue gefixt zijn.

[Voor 8% gewijzigd door smoking2000 op 23-02-2005 14:52]

[smoking2000]

fci-0.6.1 released.

Veel gefixte code mbt Windows compatibiliteit.

--update-qd werkt nog niet helemaal, hij update prima, alleen de qd.exe die op disc wordt weggeschreven is 96 bits groter dan het origineel op de server.
Dit probleem is er niet als je fci-client.pl onder Linux draait.
Ik ben nog aan het uitzoeken waar die extra bits vandaan komen, maar verder werkt fci-client.pl nu prima onder Windows

[update]
Met dank aan ele op #wos weet ik nu dat het verschil door de cr/lf encoding komt, ik zal even opzoek moeten naar een functie/module om de gedownloaded qd data binary save weg te schrijven.
[/update]

[Voor 19% gewijzigd door smoking2000 op 23-02-2005 22:50]

[SandStar]

smoking2000 schreef op woensdag 23 februari 2005 @ 21:23:
fci-0.6.1 released.

Veel gefixte code mbt Windows compatibiliteit.

--update-qd werkt nog niet helemaal, hij update prima, alleen de qd.exe die op disc wordt weggeschreven is 96 bits groter dan het origineel op de server.
Dit probleem is er niet als je fci-client.pl onder Linux draait.
Ik ben nog aan het uitzoeken waar die extra bits vandaan komen, maar verder werkt fci-client.pl nu prima onder Windows

[smoking2000]

fci-0.6.2 released.

--update-qd bug onder Windows nog even gefixt voor het slapen gaan, bleek geen grote ingreep.

---

fci-0.6.3 released.

Typo gefixt in nieuwe code welke de --update-qd bug onder Windows fixt

_{Mental note: niet meer even snel voor het slapen gaan een release doen}

[Voor 42% gewijzigd door smoking2000 op 24-02-2005 10:21. Reden: fci-0.6.3 added]

[SandStar]

code:

[Thu Mar  3 23:13:10 2005] [error] Can't load '/usr/lib/perl5/site_perl/5.8.5/i686-linux/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/perl5/site_perl/5.8.5/i686-linux/auto/Image/Magick/Magick.so: undefined symbol: InheritException at /usr/lib/perl5/5.8.5/i686-linux/DynaLoader.pm line 230.\n at /var/www/localhost/htdocs/folding/index.pl line 13\nCompilation failed in require at /var/www/localhost/htdocs/folding/index.pl line 13.\nBEGIN failed--compilation aborted at /var/www/localhost/htdocs/folding/index.pl line 13.\n
Subroutine menu_item redefined at (eval 11) line 95.
Subroutine submenu_item redefined at (eval 11) line 103.

Module perlmagick is gewoon geïnstalleerd....
Enige suggestie waar de fout kan zitten?

Edit:
ik heb misschien zelf al iets gevonden... uno momento

Edit2:
ok was een fout aan mijn kant. imagemagick was niet met alle opties gecompiled.
Worden nu perfect afbeeldingen gemaakt van mn wu's.
Geeft alleen wel een pittige extra load. ff kijken hoe mn server daarop reageerd.

[Voor 20% gewijzigd door SandStar op 04-03-2005 00:26]

[smoking2000]

SandStar schreef op donderdag 03 maart 2005 @ 23:16:

code:

[Thu Mar  3 23:13:10 2005] [error] Can't load '/usr/lib/perl5/site_perl/5.8.5/i686-linux/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/perl5/site_perl/5.8.5/i686-linux/auto/Image/Magick/Magick.so: undefined symbol: InheritException at /usr/lib/perl5/5.8.5/i686-linux/DynaLoader.pm line 230.\n at /var/www/localhost/htdocs/folding/index.pl line 13\nCompilation failed in require at /var/www/localhost/htdocs/folding/index.pl line 13.\nBEGIN failed--compilation aborted at /var/www/localhost/htdocs/folding/index.pl line 13.\n
Subroutine menu_item redefined at (eval 11) line 95.
Subroutine submenu_item redefined at (eval 11) line 103.

Module perlmagick is gewoon geïnstalleerd....
Enige suggestie waar de fout kan zitten?

Edit:
ik heb misschien zelf al iets gevonden... uno momento

Edit2:
ok was een fout aan mijn kant. imagemagick was niet met alle opties gecompiled.
Worden nu perfect afbeeldingen gemaakt van mn wu's.
Geeft alleen wel een pittige extra load. ff kijken hoe mn server daarop reageerd.

Ziet er goed uit! Dus toch maar X.org op je server gecompiled of heb je een manier gevonden om alleen de libraries te compilen?

Mogelijk is het binnenkort mogelijk om geanimeerde moleculen te genereren, maar dat hangt ervan af of de autheur van PDB2MGIF, Andreas Bohne, mij inzicht kan verschaffen hoe dit te realiseren is.

[SandStar]

smoking2000 schreef op vrijdag 04 maart 2005 @ 09:37:
[...]

Ziet er goed uit! Dus toch maar X.org op je server gecompiled of heb je een manier gevonden om alleen de libraries te compilen?

Mogelijk is het binnenkort mogelijk om geanimeerde moleculen te genereren, maar dat hangt ervan af of de autheur van PDB2MGIF, Andreas Bohne, mij inzicht kan verschaffen hoe dit te realiseren is.

idd Xorg gecompiled. Doe er verder niks mee dus echt in de weg zal het denk ik niet zitten.
Ben nu wel actief aan het zoeken naar een serververvanging want mn P3 500 gaat nu toch soms wel een beetje over zn nek bij die plaatjes....

[smoking2000]

Wat is jou definitie van "over zn nek" gaan?

Duurt het lang voordat een upload klaar is of iets anders?

In geval van lang duurende uploads zou ik de mogelijkheid kunnen inbouwen om heftige verwerkingen via een cronjob te laten doen ipv realtime tijdens de upload. Dat zou moeten schelen in de merkbare performance. Of nemen de fci handelingen zoveel CPU cycles inbeslag dat de overige processen niet echt aan de beurt komen?

[SandStar]

smoking2000 schreef op vrijdag 04 maart 2005 @ 12:15:
Wat is jou definitie van "over zn nek" gaan?

Duurt het lang voordat een upload klaar is of iets anders?

In geval van lang duurende uploads zou ik de mogelijkheid kunnen inbouwen om heftige verwerkingen via een cronjob te laten doen ipv realtime tijdens de upload. Dat zou moeten schelen in de merkbare performance. Of nemen de fci handelingen zoveel CPU cycles inbeslag dat de overige processen niet echt aan de beurt komen?

"over zn nek gaan" is misschien niet juiste term maar ik bedoel dat hij per upload zo'n 2 seconden bezig is en een pagina openen is zo ongeveer 6 seconden. Maar het is een P3 500, daar kan je ook geen wonderen van verwachten.

Verder heeft het niet echt nadelige gevolgen voor rest van mn server. Ik denk ook niet dat je iets hoeft te veranderen.

[Tootoo]

SandStar schreef op vrijdag 04 maart 2005 @ 12:47:
[...]


"over zn nek gaan" is misschien niet juiste term maar ik bedoel dat hij per upload zo'n 2 seconden bezig is en een pagina openen is zo ongeveer 6 seconden. Maar het is een P3 500, daar kan je ook geen wonderen van verwachten.

Verder heeft het niet echt nadelige gevolgen voor rest van mn server. Ik denk ook niet dat je iets hoeft te veranderen.

Het duurt dan nog wel een anderhalve maand, maar ik wil als ik weer terug ben wel gaan kijken hoe freebsd werkt op mijn eigen bak. Mocht dat goed zijn, dan kunnen we dat wel als server gebruiken Will keep you all updated

[smoking2000]

SandStar schreef op vrijdag 04 maart 2005 @ 12:47:
[...]


"over zn nek gaan" is misschien niet juiste term maar ik bedoel dat hij per upload zo'n 2 seconden bezig is en een pagina openen is zo ongeveer 6 seconden. Maar het is een P3 500, daar kan je ook geen wonderen van verwachten.

Verder heeft het niet echt nadelige gevolgen voor rest van mn server. Ik denk ook niet dat je iets hoeft te veranderen.

Je zou het script voor statische html paginas kunnen gebruiken, dan staan je pagina die je wilt bekijken in een flits op je scherm. De uploads zullen niet sneller gaan, maar "casual browsing" zal drastisch sneller zijn.

Is het zo'n probleem dat je uploads 2 seconden duren, doe je de uploads met de hand en heb je ze niet in een cronjob oid staan?

[SandStar]

smoking2000 schreef op vrijdag 04 maart 2005 @ 14:08:
[...]

Je zou het script voor statische html paginas kunnen gebruiken, dan staan je pagina die je wilt bekijken in een flits op je scherm. De uploads zullen niet sneller gaan, maar "casual browsing" zal drastisch sneller zijn.

Is het zo'n probleem dat je uploads 2 seconden duren, doe je de uploads met de hand en heb je ze niet in een cronjob oid staan?

uploads gaan met hourly cronjob
maar ssssst verder, ik zoek gewoon een goede reden om mn server te upgraden

Binnen niet afzonderlijke tijd hoop ik ook mn MCE2005 bakje mee te kunnen laten vouwen. Benieuwd of de client daar ook lekker op draait.
XP-M 2600

[smoking2000]

ik zoek gewoon een goede reden om mn server te upgraden

In dat geval ga ik weer verder met nieuwe feature ipv me met performance bezig te houden

[SandStar]

smoking2000 schreef op vrijdag 04 maart 2005 @ 17:31:
[...]


In dat geval ga ik weer verder met nieuwe feature ipv me met performance bezig te houden

Het enigste wat ik belangrijk vindt is de snelheid van de overzichtspagina en die is nog steeds lightning fast

[smoking2000]

fci-0.7 released.

Het heeft even geduurt, oa. bezig geweest met sociaal leven , ook is deze versie beter getest dan de voorgaande en duurde het even voordat ik de animated gif functionaliteit correct werkende had.

So what's new?
Enkele highlights:
- Herschreven HTTP handler en .plc parser code
- Voor de fci-client is het niet meer nodig om met de --windows flag aan te geven dat het OS Windows is, dit gaat nu automatisch
- Animated gifs van de proteines. Met dank aan Andreas Bohne van PDB2MGif voor mij in de juiste richting te wijzen.
- De mogelijkheid om in de configuratie interface de instellingen te resetten naar de default waardes
- Enkele gemiddelden van de clients

[Voor 16% gewijzigd door smoking2000 op 10-03-2005 13:25]

[SandStar]

Wat is eigelijk de handigste manier op te upgraden?
Gewoon alles vervangen of kan ik bepaalde instellingen laten staan...

[smoking2000]

In prince kan je alles gewoon er overheen kopieeren. De gegenereerde .htaccess & .htpasswd files blijven gewoon staan.
Je hoeft alleen een backup te maken van $docroot/settings/site-data/config waar je authenticatie info in staat. Deze kan je dan na upgrade terug plaatsen, en de nieuwe info die er nu in voorkomt kan je via de configuratie interface naar de defaults zetten.
Ik neem aan dat je je authenticatie info niet wilt resetten, dus dan hoef je alleen op de nieuwe images pagina de velden te resetten, gezien die velden nog niet in jou config file voorkomen.

Resetten is niets meer dan de betreffende waardes van die optie uit $docroot/settings/site-data/defaults te copieren naar $docroot/settings/site-data/config. Dat zij dus alleen de waardes van de velden waar de Defaults button onder staat.

In 0.7.1 of 0.8 zal ik het zo maken dat je alleen je config terug hoeft te plaatsen en dat de ontbrekende velden uit defaults gehaalt worden.

[smoking2000]

fci-0.7.1 released.

Wat kleine bugfixjes en nieuwe feature.
- fci-client.pl stuurt nu correct de qd & qdinfo.dat versie naar de server
- op de pagina settings/clients.plc is nu per client wat meer info getoont, als qd versies en fci-client.pl versie
- defaults worden nu correct gehandled wanneer er nieuwe waardes in de defaults file staan die nog niet in de bestaande config file staan

[SandStar]

We hebben weer wat te doen dit weekend

Nice job!

[smoking2000]

Thank you!

en nu eindelijk die installer eens afmaken voor 0.8, is een beetje stil komen te staan helaas.

[Schapie]

Eigen server is onderweg op dit moment nog wat bestanden overkopieren van hardeschijven en dan ga ik van het weekend win2000 installaren. Wat gevolgd zal worden door apache met de nodige opties. (mod_perl en mod_php dat heb ik goed toch ben een beetje n00b dus. php is nog voor wat anders in de toekomst)

Ik installeer alles dmv van zo'n pakket installer ik begrijp dat dat niet de beste manier is maar ik denk dat het voor mij wel de beste manier is om mee tebeginnen.
Gaat het trouwens werken het server script op een windows server met apache 2.x ?

[smoking2000]

Schapie schreef op vrijdag 11 maart 2005 @ 17:02:
Eigen server is onderweg op dit moment nog wat bestanden overkopieren van hardeschijven en dan ga ik van het weekend win2000 installaren. Wat gevolgd zal worden door apache met de nodige opties. (mod_perl en mod_php dat heb ik goed toch ben een beetje n00b dus. php is nog voor wat anders in de toekomst)

Ik installeer alles dmv van zo'n pakket installer ik begrijp dat dat niet de beste manier is maar ik denk dat het voor mij wel de beste manier is om mee tebeginnen.
Gaat het trouwens werken het server script op een windows server met apache 2.x ?

Momenteel werkt het server component alleen nog op Linux/UNIX, de client werkt wel onder Windows.
Verder is het ook alleen getest met de apache 1.3 branch, maar zou in principe ook met 2.x moeten werken.

Er moet veel meer aan de server gewijzigt worden om dat ook onder Windows te laten werken.
Behalve de pathnames, moeten er ook Windows versies van RasMol en xyz2pdb op komen, en waarschijnlijk nog wat Windows specifieke file handling

Als je zou willen helpen met deze functies testen, wil ik daar best snel aan beginnen, maar gezien ik geen Windows server tot mijn beschikking heb (clients only) en er tot nu in principe geen vraag naar was, heeft het een lage prioriteit. Laat het maar even weten.

[Voor 5% gewijzigd door smoking2000 op 11-03-2005 17:41]

[SandStar]

Schapie schreef op vrijdag 11 maart 2005 @ 17:02:
Eigen server is onderweg op dit moment nog wat bestanden overkopieren van hardeschijven en dan ga ik van het weekend win2000 installaren. Wat gevolgd zal worden door apache met de nodige opties. (mod_perl en mod_php dat heb ik goed toch ben een beetje n00b dus. php is nog voor wat anders in de toekomst)

Ik installeer alles dmv van zo'n pakket installer ik begrijp dat dat niet de beste manier is maar ik denk dat het voor mij wel de beste manier is om mee tebeginnen.
Gaat het trouwens werken het server script op een windows server met apache 2.x ?

Als je de server installeerd vanwege fci zou ik er zowieso meteen linux op knallen.
Zoals Smoking al aangaf werkt het server gedeelte niet onder windows en loop je alleen maar te kloten om het onder windows aan de praat te krijgen.

Je een beetje helpen met je linux bak kan ik wel

[smoking2000]

fci-0.7.2 released.

Kleine bug fix in de parsing van de qd data, herkent nu ook decimale waardes in percent complete velden

fci-0.7.3 released.

clients.plc laat nu ook van de qd informatie de points per hour zien, deze waarde was al beschikbaar maar werd nooit getoont.

fci-0.7.4 released.

typo gefixed in fci-client.pl welke compilatie sloopte

[Voor 53% gewijzigd door smoking2000 op 22-03-2005 10:00. Reden: 0.7.3 release added; 0.7.4 release added]

[Tootoo]

Een vraagje: is het misschien ook handig om een kleine sectie erbij te nemen om oude clients weer te netjes te verwijderen?

[SandStar]

donderdag update dag

[smoking2000]

Tootoo schreef op woensdag 23 maart 2005 @ 18:39:
Een vraagje: is het misschien ook handig om een kleine sectie erbij te nemen om oude clients weer te netjes te verwijderen?

Sinds 0.5 is het in de configuratie interface mogelijk om clients, of files daarvan, te verwijderen. Elke verwijzing naar die client is dan verwijderd.

Of bedoel je een automatische functie, die aan de hand van de lastupdate datum besluit om de client te verwijderen?

Momenteel staat de ontwikkeling van fci op een laag pitje, voornamelijk bugfixes atm, omdat ik veel moet overwerken om een project deadline te halen @work.

[SandStar]

laag pitje?
Ik kon het niet eens bijhouden al die updates

[Tootoo]

SandStar schreef op donderdag 24 maart 2005 @ 10:03:
laag pitje?
Ik kon het niet eens bijhouden al die updates

jij bent dan ook gewoon sloom (sorry, die bal lag iets te erg voor de goal al )

[smoking2000]

fci-0.8 released.

Na een maand lang 72 uur per week gewerkt te hebben, heb ik mijn deafline gehaald en op mijn 1e vrije dag de tijd gevonden om een nieuwe release af te ronden.

Diverse aanpassingen in de subroutines, om om te kunnen gaan met unitinfo.txt files die niet aan verwachtingen voldoen. Zoals een lege file, of een onbruikbare WU Name.

Ik ben een grote rewrite aan het voorbereiden waarin de belangrijkste bron van informatie qd word, ipv de unitinfo.txt gezien deze niet altijd betrouwbaar bleek, een installer en betere documentatie.

[Schapie]

Nee klopt dat de unitinfo.txt niet altijd even betrouwbaar is. Ik heb een client die het zo nu en dan nodig vind om extra spatie voor de naam tezetten waardoor dcmonitor het niet meer begrijpt.

(Weer een extra reden om fci tegaan gebruiken. Maar is het client script voor windows zelf getimed of moet ik die gewoon eens in de zoveel tijd laten uitvoeren ?)
[edit]
Bedankt smoking dat was precies wat ik moest weten want daar heb ik ook enkele keren mee zitten stoeien.

[Voor 14% gewijzigd door Schapie op 17-04-2005 20:56]

[smoking2000]

Je moet zelf een job in je schedular maken, ik zelf doe overall elke uur updaten.

De windows gebruikers van Fatal Error Group gebruiken Visual Cron ipv de standaard Windows schedular, gezien die wat moeite heeft met uurlijkse updates

[JMT]

Je bedoelt eerder met de user-rechten (iig in WinXP Pro) aangezien er ooit een lek in zat en waarvoor een bugfix is gekomen die het lek wel dicht maar daardoor je die scheduler ook niet goed meer kunt gebruiken. Er zou t.z.t. nog een nieuwe bugfix komen die dat dan ook weer zou moeten verhelpen maar wanneer blijft nog onbekend....
Visual Cron is overigens een perfecte vervanger hier

[SandStar]

*updated*

Ik zie dat de plaatjes van eiwitten nu ronddraaien, geinig

[smoking2000]

klopt, maar dat was ook al in de 0.7 release

Deze release heb ik snel gefixt om een gebruiker te helpen die moeite had met brakke unitinfo files, gezien dat toch op mijn todo lijst stond heb ik daar maar een prioriteit van gemaakt.

[SandStar]

smoking2000 schreef op maandag 18 april 2005 @ 17:41:
klopt, maar dat was ook al in de 0.7 release

Ik had wat vertraging opgelopen bij het onderhoud

[SandStar]

rotschop!

probleem.
Ik zit te kloten met een windows client (l4gger)

code:

C:\Program Files\FAH>fci-client.pl --url http://pr0ner.no-ip.org/folding/index.p
l --client l4gg3r --dir "C:\Program Files\FAH\" --config "C:\Program Files\FAH\c
lient.cfg" --unitinfo "C:\Program Files\FAH\unitinfo.txt" --username ****** --
password **** --windows --verbose
Error: Cannot read Folding@Home client directory! (C:\Program Files\FAH" --confi
g C:\Program)

Voeg ik een extra / toe zodat het --dir "C:\Program Files\FAH\\" wordt krijg ik een error met:
Error: Cannot read Folding@Home client directory! (C:\Program Files\Folding@Home>

Ik krijg het alleen gefixed door de standaard dir in client.pl te veranderen naar mijn specifieke dir...

[SandStar]

Wat ik trouwens ook net lees is dat de maker van qd is overleden.
The Weatherman heeft alles van zn site gemirrored via www.em-dc.com maar ik denk niet dat we nog enige updates ervan kunnen verwachten....

[smoking2000]

SandStar schreef op woensdag 24 augustus 2005 @ 21:35:
rotschop!

probleem.
Ik zit te kloten met een windows client (l4gger)

code:

C:\Program Files\FAH>fci-client.pl --url http://pr0ner.no-ip.org/folding/index.p
l --client l4gg3r --dir "C:\Program Files\FAH\" --config "C:\Program Files\FAH\c
lient.cfg" --unitinfo "C:\Program Files\FAH\unitinfo.txt" --username ****** --
password **** --windows --verbose
Error: Cannot read Folding@Home client directory! (C:\Program Files\FAH" --confi
g C:\Program)

Voeg ik een extra / toe zodat het --dir "C:\Program Files\FAH\\" wordt krijg ik een error met:
Error: Cannot read Folding@Home client directory! (C:\Program Files\Folding@Home>

Ik krijg het alleen gefixed door de standaard dir in client.pl te veranderen naar mijn specifieke dir...

Dit is een bekend probleem, Windows gaat niet helemaal relaxt om met directory separators op de commandline.
In v1.0 is dit gefixt, door automatisch de directory separator te suffixen als deze ontbreekt.

Als dit een erg grote irritatie is wil ik dit ook wel backporten naar 0.8 en een 0.8.1 release maken.

SandStar schreef op donderdag 25 augustus 2005 @ 01:07:
Wat ik trouwens ook net lees is dat de maker van qd is overleden.
The Weatherman heeft alles van zn site gemirrored via www.em-dc.com maar ik denk niet dat we nog enige updates ervan kunnen verwachten....

Ik las het gister pas op forum.folding-community.org. Erg zonde, ik zal hem missen. Hij was een enorme hulp bij het ontwikkelen van fci, hij heeft een hoop kennis van de F@H client en diens files kunnen verschaffen.

The Weatherman is de onofficiele maintainer geworden van Dick tools, en zorgt voor updates van qd. Hij en een aantal anderen hebben mogelijk updates voor qdinfo.dat zodat nieuwe WUs ook van de juiste credits voorzien kunnen worden. Maar qd kan ook met de data file van Electron Microscope van The Weatherman overweg, en gezien hij nog wel nieuwe versies uitbrengt zal ik die waarschijnlijk gaan gebruiken. Maar ik ben nog even in overleg met de verschillende developers om te kijken wat de beste aanpak moet worden, want een ding is zeker Dicks tools zijn onmisbaar voor 3th party F@H apps op Linux.

[SandStar]

Is geen grote irritatie; ik kan het zelf oplossen
* SandStar wacht met spanning op de 1.0 release

[smoking2000]

SandStar schreef op donderdag 01 september 2005 @ 09:41:
Is geen grote irritatie; ik kan het zelf oplossen
* SandStar wacht met spanning op de 1.0 release

Je bent niet de enige die met spanning op v1.0 wacht. Colin J. Ingram, die aan fci heeft gesleuteld om het op Apache2 werkend te krijgenn doet dat ook, zijn fixes zullen erin terug te vinden zijn

Ik heb tevens besloten om de 1.0 release aan Dick Howell op te dragen. Dat is wel het minste wat ik kan doen.

[smoking2000]

Ik heb de corrupte partitie gerecovered en de server is opnieuw installed.
Na een iets te lange downtime is http://fci.bile.nl weer back in business

[Schapie]

smoking2000 schreef op donderdag 22 september 2005 @ 23:01:
Ik heb de corrupte partitie gerecovered en de server is opnieuw installed.
Na een iets te lange downtime is http://fci.bile.nl weer back in business

Dat is mooi. Ik heb inmiddels een geheel draaiende installatie van debian ik moet alleen nog even kijken welke versie van apache ik heb geinstalleerd. (Ik heb de server alweer enige tijd terug geinstalleerd etc. maar door een probleem met een andere pc had ik de server nodig om nog eventjes een hdd te backuppen etc.) Maar van het weekend stop ik de goede hdd er weer in en zal ik eens kijken of fci gaat draaien. Mits het natuurlijk de 1.0 brand is van apache anders zal ik nog even moeten wachten op de 1.0 versie van FCI.

[SandStar]

1.0 gaat werken met apache2?
Het probleem lag toch niet zozeer bij fci maar bij mod_perl ofzow?

[Schapie]

SandStar schreef op vrijdag 23 september 2005 @ 09:18:
1.0 gaat werken met apache2?
Het probleem lag toch niet zozeer bij fci maar bij mod_perl ofzow?

smoking2000 schreef op donderdag 01 september 2005 @ 10:22:
[...]


Je bent niet de enige die met spanning op v1.0 wacht. Colin J. Ingram, die aan fci heeft gesleuteld om het op Apache2 werkend te krijgenn doet dat ook, zijn fixes zullen erin terug te vinden zijn

Ik heb tevens besloten om de 1.0 release aan Dick Howell op te dragen. Dat is wel het minste wat ik kan doen.

Ik durf namelijk niet meer eerlijk te zeggen welke versie ik nou geinstalleerd had. Ik weet wel zeker dat ie al werkte moest alleen nog het een en ander configureren.

[smoking2000]

SandStar schreef op vrijdag 23 september 2005 @ 09:18:
1.0 gaat werken met apache2?
Het probleem lag toch niet zozeer bij fci maar bij mod_perl ofzow?

Het is de bedoeling dat met de release van fci-1.0 het zowel op Apache 1.3.x als Apache2 gaat draaien. Momenteel draait de 0.x branch alleen nog op Apache 1.3.x

Het probleem lag aan fci omdat de mod_perl voor Apache2 een iets anders werkt dan die voor Apache 1, en daar geen rekening mee houdt. Tevens was het toen ik aan fci begon nog zo dat de mod_perl voor Apache2 niet echt lekker werkte, dit is gefixt met de laatste release van mod_perl ergens ten tijde van fci-0.7 ongeveer.

.

Schapie schreef op vrijdag 23 september 2005 @ 10:03:
Ik durf namelijk niet meer eerlijk te zeggen welke versie ik nou geinstalleerd had. Ik weet wel zeker dat ie al werkte moest alleen nog het een en ander configureren.

Ik hoop 0.8, daar zitten de meeste fixes in Dit is ook alweer een oude release, en ik verwacht er geen updates meer voor uit te brengen. Als er nog wat heel vervelende bugs gevonden worden, dan zal ik die uiteraard fixen in 0.8.x release, maar anders zicht ik mijn pijlen (en tijd!) liever op fci-1.0 wat een behoorlijk grote rewrite aan het worden is!

Vanochtend kreeg ik een PM op het folding-community forum met het bericht dat Plutronics van Team MacOSX 1971 updates maakt voor qdinfo.dat, de data file voor qd welke de credits per project bij houdt. Dit is erg mooi gezien de rewrite van fci de meeste van zijn data uit qd haalt.

[Schapie]

smoking2000 schreef op vrijdag 23 september 2005 @ 10:40:
[...]


Ik hoop 0.8, daar zitten de meeste fixes in

Ik bedoelde de Apache versie
FCI 0.8 heb ik ook iig gedownload en op een bruikbare plaats staan. De hdd met windows is er inmiddels uit alleen heeft die andere pc nog eventjes de voeding en de netwerkkabel ingebruik.
Maar dat ga ik zo ook afronden dan kan ik die weer bij mij broertje neerzetten en mag hij de rest en weer opzetten. (Na de FAH client )

[smoking2000]

code:

dpkg -l apache* | grep ^i

Het resultaat is een lijst met geinstalleerde apache componenten.

Als de naam niet met apache2 begint is het de apache 1.3.x branch.

[smoking2000]

fci-0.8.1 released.

Bugfix in www/settings/autentication.plc, als je een cusom path naar htpasswd gedefineerd had, werkd dat niet door het script gebruikt, waardoor de .htpasswd file niet aangemaakt werd.

Alle qd files zijn geupdate naar de laatste release van Dick Howell (11 Augustus 2005)

Tevens is het script download-qd-files.pl verwijderd en is vervangen door psummary2qdinfo.pl
Naar aanleiding van een mail die ik kreeg van Plutronics van Team MacOS-X, heb ik dit script geschreven. Ik was eigenlijk pas van plan een qdinfo.dat updater te maken voor fci-1.0, maar dit is nu toch al gebeurt.
Pluts hield aan de hand van een script van zijn teammate Jackrabbit de wijziging in psummaryC.html bij, welke hij dan met de hand (!) updatete in qdinfo.dat
Tijdens een nacht dat ik niet kon slapen, heb ik dat script onder handen genomen om de wijziging automatisch in qdinfo.dat te updaten om zijn werk wat makkelijker te maken. Het enige wat het in eerste instantie niet deed was het updaten van de credit revisions (point history), omdat niemand eigenlijk precies snapte hoe dat werkte.
Na wat hacking en semi-reverse engineering, heb ik uitgevogeld hoe dat werkt en het script geupdate.

Ik heb net nog wat cosmetische aanpassingen gemaakt, en bij fci toegevoegd.

[SandStar]

woei!
nice job!

[SandStar]

wat misschien leuk is voor de 1.0 release:
stats onderscheid laten maken in clients die op 1 pc draaien:
Ik heb een dual P3 (Zeus) en die moet ik nu dus Zeus-1 en Zeus-2 noemen.
Misschien leuk als die gewoon onder 1 noemer met 2 cores kunnen worden gezet.

100% weet ik het niet maar de V6 client van folding heeft waarschijnlijk dualcore/htt/smp ondersteuning. Met oog op de toekomst dus

[smoking2000]

Dat zit in de planning, in de 1.0 client zit een switch --cpu waarmee je kunt aangeven voor welke CPU je de info submit. Deze switch word o.a. ook gebruikt om de CPU speed van de machine uit te vogelen via het OS.

Er zit een nadeel aan, ik heb geen smp systemen, dus kan dat niet testen. Laat staan voor alle OSen die ik support (Linux, FreeBSD, OpenBSD & Windows). De UNIX systemen, zijn redelijk straightforward mbt SMP systemen, Windows is een andere verhaal...

Voor V6 kan ik nog niets doen, tenzij qd geupgrade kan worden om met het queue format van V6 om te gaan, zal ik fci toch weer from scratch moeten herschrijven...

Dus al met al, een deel van je wens is al aan gedacht :-)

Btw, als je Windows Server 2003 draait, is er nu een qd versie die deze support. Ik kwam die bug tegen bij een van onze teammembers, daar gaf qd alleen de identifier aan van het OS maar niet de naam.

Je kan die versie van qd op mn websites vinden:
http://linuxminded.xs4all.nl/?target=software-qd.plc

[Voor 19% gewijzigd door smoking2000 op 19-10-2005 12:43]

[SandStar]

smoking2000 schreef op woensdag 19 oktober 2005 @ 12:26:
Dat zit in de planning, in de 1.0 client zit een switch --cpu waarmee je kunt aangeven voor welke CPU je de info submit. Deze switch word o.a. ook gebruikt om de CPU speed van de machine uit te vogelen via het OS.

Er zit een nadeel aan, ik heb geen smp systemen, dus kan dat niet testen. Laat staan voor alle OSen die ik support (Linux, FreeBSD, OpenBSD & Windows). De UNIX systemen, zijn redelijk straightforward mbt SMP systemen, Windows is een andere verhaal...

Voor V6 kan ik nog niets doen, tenzij qd geupgrade kan worden om met het queue format van V6 om te gaan, zal ik fci toch weer from scratch moeten herschrijven...

Dus al met al, een deel van je wens is al aan gedacht :-)

Btw, als je Windows Server 2003 draait, is er nu een qd versie die deze support. Ik kwam die bug tegen bij een van onze teammembers, daar gaf qd alleen de identifier aan van het OS maar niet de naam.

Je kan die versie van qd op mn websites vinden:
http://linuxminded.xs4all.nl/?target=software-qd.plc

Als ik kan helpen met de smp machines... ik heb het volgende staan:
Dual Xeon 1.8 (met HT dus 4 cpu's) (win2k)
Dual P3 733 (linux)
Dual Opteron 252 (winxp)
Xeon 3.2 HT