Talk:Main Page

Jump to: navigation

This project arose out a discussion on DNUK [1] in November 

Elements of its antecedents include discussions on GP-UK,
and of course The Wikipedia

Archives of this main talk page at:-

Contents

MySQL restart

BEST NOW DONE BY REBOOTING MACHINE - we were only getting this issue as not using mysql_safe script to start mysql after reboot - now mysql and apache automatically restart on reboot Mlj 08:23, 19 May (BST)

GLitched some time today and I restarted it. Midgley 14:30, 1 June (BST)

Looks like every two months presently. Mlj 21:17, 1 June (BST)

Down again. Must have been in last 30 minutes or so as Main page came up earlier. When I went in home looking 78% full. Think it might be mysql log files due to some error in mysql getting out of hand and being copied with each nightly back up. Interestingly a mysql process was running when I went in. I did a complete reboot and will have a lock at logs now Mlj 22:43, 10 June (BST)

Had to restart MySQL yet again just now Mlj 20:21, 2 July (BST). Crash happened between 18:00 and 19:00 Mlj 20:26, 2 July (BST)
The rebuild may have to happen some time. I had a look at it and bogged down on a replacement for Apache. Midgley 16:01, 3 July (BST)
Glitched again today and off for 11 hours. MySQL restarted. only 32 days since reboot for other reason. Oh well. Mlj 23:22, 2 May (BST)
I'm back on the 'Net with a new router. Rebuilding Ganfyd is a scary job, actually. I'm still thinking about it though. Midgley 13:11, 3 May (BST)
Another MySQL restart necessary. Been down about 8 hours. No time for forensic analysis but may require reboot as well, we will see Mlj 08:41, 23 June (BST)
Yet another MySQL restart. Seems to have crashed about time of usual cron job for archive 03:00 and this did not complete until 11:50. Might need reboot sometime but will let Adrian do that after last disasterMlj 20:35, 5 May (BST)
Whole system went down and top suggested it had rebooted about 45 minutes before I noticed. So required a restart of mysql amd apache which did not go smoothly. Home was at 82% so I deleted apache log file that was running at over 4 GB while apache off. After third reboot full system up but was quite worried as mysql not coming up. Hope its just because it needs a return key acknowledgement to the message Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) that I had done in past and forgotten I had done. Mlj 00:47, 3 December (UTC)
PS - if anyone else goes into server next few days would expect df to show home decreasing from the 52% I have left it to ensure we have some archive from before crash to back up off site if someone wants to do it. Not backing up off site tonight myself as too close to usual archive time. Worried that mysql log files getting out of control in size but do not dare touch them as do not know enough. Mlj 01:01, 3 December (UTC)
MySQL restart: Went down about 16:00 - decided this gets predictable when home about 78% full. Did crude removal of MySQL log files as someone has done that before and that will leave home at 30%. Will last close to a year I reckon. The mysql-bin.index file needs manual clean out sometime to remove all the references to mySQL log files that have not been purged the official way by calling mysqladmin flush-logs or what ever. I understand flush-logs may not work easily as things are and that its possible to set up a rotate logs script but this well beyond my confidence level on a live system. Best done when MySQL closed cleanly with planned maintenance, not when aim is to get server up with a clean database recovery. Under no circumstances delete last mySQL log file or last entry in mysql-bin.index or you might not recover from a mySQL crash. That much I understood before manual clean up Mlj 21:20, 14 January (UTC).
MySQL went down about 04:00 yesterday morning. Rebooted rather than just restarted MySQL Mlj 13:56, 25 March (UTC)
MySQL went down about 19:00. Disk use only 47% but cleaned out logs while in so disk use about 22%. Clean close down of Apache, then restart MySQL and Apache. Mlj 23:20, 22 June (BST)
That did not last long. Needed reboot as yet again MySQL went down. A lot of activity in access logs from chinese hackers. Any one want to block 113.195.145.79 as was creating quite a load. Mlj 22:04, 27 June (BST)
MySQL went down just after 09:00. Decided to just do a reboot. Mlj 23:15, 17 November (UTC)
MySQL went down by its self so site offline about 6 hours. No clear reason why although we are being really hammered by wordpress targetted hackers which should not affect MySQL although of course apache is now not coping well at all. 21:17, 14 February (UTC)

cards

Cards or leave-pieces might be useful to hand people. Midgley 17:20, 11 July (BST)

Medpedia RIP

Despite the big backing of US medical schools, seems to have quietly disappeared: Mark ong 19:10, 23 August (BST)

interesting. So that commercial model does not work. The single expert in speciality model for medical wikis does not work (anaesthesia) Some good content lost compared to wikipedia with both demises. Suggests we may as well keep going ( especially if we get around to a successful rebuild) . Wikipedia still continues to have inaccuracies and other biases that annoy me at least to the degree that I will put minor degrees of money and time to keep GANFYD going. Mlj
So it goes. Midgley 23:54, 26 August (BST)

SubjectBox (template) and Printable Format

The SubjectBox goes very nasty when a page is asked for printable format. It probably isn't worth having the SubjectBox present at all, on a printed page, since it is all links. This doesn't apply to Chemistry boxes and so on which hold useful specific information as well. For the SubjectBox, substituting on paper a note that selected links are available from the online version (or conceivably a QRCode that points to the specific page in case soemone is reading a paper copy and has a smartphone) would be fine, but for other boxes we need to check that they print sensible versions. Midgley 14:52, 1 September (BST)

Actually this should be easy to solve by CSS manipulation for class SubBox, I will have a lookMlj 21:18, 1 September (BST)
Ok removing SubBox works. To render only useful information in SubBox will take longer to sort. See MediaWiki:Print.css for the code that removes all our SubBox's which I have left in operation. Also note following reference URLs [2] and [3]/ Mlj 21:42, 1 September (BST)
I have now tidied up so only div.URL removed. Will sort out Snomed in a moment by placing it as a div.URL and it will do. Mlj 21:53, 1 September (BST)
Neat. Thanks. Midgley 14:51, 2 September (BST)

Should we have a picture of a water fowl

To go with "The enclosed is an advertised theory or health belief likely to be presented or underlie some people's apparent concern with their health but which lacks or is inconsistent with scientific or medical evidence: "? Midgley 07:10, 9 December (UTC)

which picture - roast duck/geese/swan ( believe the last is probably high treason for many GANFYD contributors), swamp hen, pukeko, rail ? Mlj 22:49, 9 December (UTC)

Cochrane collab. Offering free subs to WP medical editors

There's an overlap between this and WP editors. Cochrane access is worth having. Wander over there if you don't have it and would like it. Midgley 21:03, 3 January (UTC)

Serious maintenance issues

When checked against latest Wikimedia exploit we seem to be safe. But rebuild must happen sometime to allow us to keep MediaWiki software up to date. However when in server main disk was up to 80% full due to Apache access log file size and our back ups of this. More permanent solution awaited as only way I can work out to do it safely on live installation is stop web server manually and then delete the access files Mlj 22:18, 30 January (UTC)

Was down to 44% full after maintenance. Hopefully will back up site offsite overnight as archived 05:15 16th Feb but this will take 8 hours. This is just in case I created any Mysql recovery issues from 17th February so please do not reboot server today ! Mlj 19:05, 16 February (UTC)

almost a doctor site

Copyright appears simply the original owner of the site, dr tom leach now in Australia.

Perhaps we should talk to him and other contributors there. Midgley 01:29, 4 February (UTC)

interesting and high quality resource well illustrating the distracting issues with commercial sponsorship but also what can be put in by just a few motivated individuals. Could become a slave to its sponsors. Sort of resource that the present owners of DNUK will gobble up one day if they decide worth their while. Mlj 07:55, 4 February (UTC)

Long Outage

An enforced reallocation of IP address revealed old dependencies in the server setup. Sorted now. It is time for a rebuild, but making sure the system comes back up is non-trivial. Midgley 21:09, 31 March (BST)

  • Happened to run across a predictable outage (of 10 minutes) odd while editing on opposite side of planet to our server. It backs up at a time that's not so convenient in Japan, Hong Kong or Australasia. Makes you wonder with a single server directed at slightly international audience what is the optimal time for back up. Easy enough to change the CRON job settings. Certainly cheaper that the solutions used by the big server sites (eg Fastly. Mlj 06:26, 17 August (BST)

Time for a Refresh?

What improvements might be made to the look and feel? I think the front page could do with some rethinking. Midgley 21:24, 4 April (BST)

Your words about a refresh made me think of the logo. Its always annoyed me that the logo colours were different on the web site itself from the favicon. So as an exercise having discovered where Adam must have got original logo from, I have done an icon with favicon colours. Of course we could change the favicon instead. It was quite a shock seeing in a brief experiment what a change it made to the website. I like the middle one myself. The original is on the left.

Current logoLogo that matches better faviconThis clashes a bit I thinkMlj 19:24, 11 May (BST)

Concur. Midgley 21:07, 12 May (BST)
OK- tend to believe in week long consultations for things easily reversed so we will do it. Any regular user who does not clear their local cache will notice no difference ! Mlj 08:48, 17 May (BST)
Fine by me! --Penglish 14:15, 15 July (BST)

Perhaps we may rotate teh picture on the front page a bit. I also wonder if the wording of our description there is due for a refresh? Midgley 10:10, 12 January (UTC)

Should we have a Medical Entomology category?

ganfyd and various other insects, bugs and the like. There are books about it. Midgley 15:14, 14 July (BST)

can not see why not Mlj 22:05, 14 July (BST)
Me neither. Let's have one! --Penglish 14:17, 15 July (BST)
Perhaps I should have meant arthropodology ... Midgley 22:25, 23 September (BST)

The Final Frontier?

I've been busy, something that should reduce in a couple of months, and just continued things rather than making progress on a plan for a rebuild, or for lower cost server or - well, anything. I think this is a useful thing, and don't expect a large proportion of colleagues to understand yet why, and think it should continue in some form.

Meanwhile, I see that Wikipedia is in the asteroid belt. Good.

Midgley 22:24, 23 September (BST)

Just one thing after another at the moment. Midgley 11:39, 6 October (BST)
I know that one thing after enough feeling. Take up my offer if you can as I still think it will be useful to have a lower cost server sitting ready to switch overMlj 23:20, 6 October (BST)

Advice for writing medical articles in the Wikipedia

May be of some use in here as well. Midgley 06:17, 5 December (UTC) It's advice not to use primary sources will cause grief or perhaps celebration as this should encourage more up to date articles being on Ganfyd ! Mlj 08:57, 6 December (UTC)

Loss of subcategories

Have noticed that some subcategories are not showing up in their master category. Presume this is due to some database issue. Can we force the wiki to reindex or should it wait till long over due rebuild ? Mlj 13:19, 27 December (UTC)

Apologies, turns out to be a feature and in fact they are not missing, but are not displayed if more than 200 pages in a category except when the correct page alphabetically is displayed. May be sovled with using a sort Key for important subcategories Mlj 13:55, 27 December (UTC)

Outage

Server required a hard reset and then tickling back into happiness. Done now. Some time this year we will perforce move to a newer piece of hardware which should be accompanied by a rebuild. Midgley 19:12, 24 March (UTC)

Been interesting looking at some of the logs that created the unhappiness. Our upgrade path over the years has resulted in some minor mis-configuration issues resulting in asked for files not being served up and when I was sorting out the worse of these in terms of error generation I discovered that an interesting side-effect is that they may have frustrated some mediawiki hackers that have been trying to get in by following classic mediawiki paths. Accordingly I have not done a complete fix - they can not exploit functionality that is not there Mlj 22:24, 27 March (UTC)

#FOAMed, Twitter and Emergency Medicine

We should be aware of the first two... Possibly there should be a general Twitter account either automagically or by deliberate process sending a tweet or two per day from the project. An ED colleague displayed a little interest, having found Ganfyd useful, and has kindly tweeted so withthe hashtag #FOAMed. Midgley 00:19, 5 May (BST)

Our oldest medicine?

I thought Digoxin, but I think we've had the Poppy for longer. Have we had anything longer than that? Chewing Willow bark?? Midgley 15:24, 28 May (BST)

Hardware move pending

The old server instead of being swapped for a new one at the moment will be physically moved to a different data centre in a couple of weeks. There's no reason to think that will break it. Sooner or later though we will move to a newer server, one which has a mirror drive, thus making data loss less of a risk. Midgley 19:19, 31 August (BST)

we seem to have survived the physical move. Next, a rebuild. Midgley 17:17, 5 December (UTC)
Ok I have just got rid of another 2GBytes of Apache log files accumulated since March, even if they GZip down well in the archives that take up much of disk, to give us a bit more time . Mlj 18:53, 5 December (UTC)
Sounds good. Mark ong 21:57, 7 December (UTC)

Social media for coordination recruitment and presence?

Should we be on Facebook, Tweet and so on? Midgley 09:41, 14 September (BST)

RIP

Ian Murdock but Debian lives on and powers Ganfyd.Mlj 21:10, 30 December (UTC)

Outage

Happened today about 10am GMT and was real bother to solve as was some form of apache race process and marked delay in ssh login. Server became unresponsive as apache http requests built up, even to degree of taking 20 minutes to respond to console commands when issue came to my notice about 12MD. I tried reboot but it refused (although it closed down some processes such as a partial ssh login giving me hope before stalling. A top showed some http processes and a graceful stop to apache did not work but gave a slightly more responsive console down to about 5 http process. A apache kill worked and the outstanding reboot worked. Message is that if shutdown -r now does not work, an apachectl stop will kill the naughty process which may or may not be caught up in a mysql bug but whatever is apache mediated. Document this as it was looking like a hard reset at server might be only way in 13:15, 31 January (UTC)

Glitched - I'm unclear what fell over. Restarted, Apache and Mysql brought back up in our usual arcane ways. Midgley 13:08, 11 February (UTC)

Looks to me triggered by Chinese hack attempts so persistent as to be a DoS that made it fall over. :-( Mlj 22:19, 11 February (UTC)
Glad it's back online. Mark ong 23:19, 11 February (UTC)
MySQL restart. MySQL seems to have crashed 18:00 yesterday. Can not identify any reason for a complete reboot as disk only 44% full. Mlj 21:20, 3 March (UTC)
MySQL went down about 04:00 yesterday morning. Rebooted rather than just restarted MySQL as this will better clear out processes. definitely getting old Mlj 13:56, 25 March (UTC)
MySQL half went down again about 20:00 and while detected pretty smartly , mysql and apache seem to have conspired to create a mutual race condition, making reboot an unexpectedly delayed international effort taking about 3 hours. Midgley's lost sleep, so users had minimum downtime, is regretted Mlj 03:38, 23 August (BST)
Sorry but from about 13:30 another outage with I assume again apache in a race condition with MySQL. Because of race condition took ages to respond to log into server and for server to process commands. Hard stop apache done to allow reboot. MySQL had a process Expect a 2 hour process to get it back up from when one of sysadmins detects issue. Roll on a rebuild. Mlj 22:39, 20 October (BST)
Sorry but the old apache race came back from about 14:00. Takes about an hour to reboot server once realised - and I had no console handy. Mlj 23:44, 1 December (UTC)
Thanks though. I only got logged in as you brought it back up. Midgley 00:10, 2 December (UTC)

And again today. Midgley 20:01, 6 December (UTC)

and again today for 14 hours before I noticed. We are getting quite sick Mlj 23:43, 12 December (UTC)
down again, sicker and sicker and a hour to get going again Mlj 00:03, 16 December (UTC)
very sick GANFYD is since about 07:34. Both Adrian and me not hopeful. I will try to close down cleanly having got mysql running and restart 21:53, 16 December (UTC)
Ok done what I could do and it restarted nicely- we will see how long it lasts. At least the fall over of mysql allowed me in quickly and gave me the opportunity to explore. Certainly our defences are being bombarded. We shall seeMlj 22:08, 16 December (UTC)
Remains very sick. Down after less than 48 hours with too many connections message and Apache race - MySQL not completely dead. Need Rupert to do some MySQL maintenance I think, till we can sort out more like a new server. Database maintenance commands totally beyond me. Mlj 22:29, 18 December (UTC)
Down again for about 6 hours. Have captured some data to send Rupert. Sorry guys. It takes a hour to reboot as we are filling memory with the crash which explains poor responsiveness. Mlj 00:40, 23 December (UTC)
Continues very sick - as I see on the net that some badly behaved indexing robots can precipitate these sort of issues I have added a Crawl-delay: to our Robots.txt file but this likely forlorn hopeMlj 16:25, 24 December (UTC)
Found that there is a memory leak somewhere. Have found that last wiki upgrade years ago was not as clean as we would have liked - now corrected but this irrelevant to issue of moment Mlj 14:08, 25 December (UTC)
Restart - watched memory filled up with orphan apache processes, had about 400 of them to kill Mlj 23:15, 27 December (UTC)
Ok - now blocked the IP addresses which on turning on apache very rapidly seemed to be doing a DoS on us - we shall see - looking much better than an hour ago - for other admins its a .htaccess file I dropped into our current wiki base directory that seems to have worked. Literally within few ms of apache being turned on the logs would show some well behaved checking robots.txt and a few poorly behaved http hits of which most active in IP range 46.229.168.65 to 46.229.168.75. These all blocked. Memory has remained stable now for much longer than any period since I realised might be nasty DoS from logs - we shall see as have cycled up to almost all RAM used when some bots active but then back down again with good memory release and no travel into swap when everything turns sour. Mlj 01:32, 28 December (UTC) :-)
Still not sorted - apache again lost connection to mysql due to race condition. Inspecting more logs as have quite good timing of crash Mlj 17:01, 29 December (UTC)
Have been investigating memory leak in Apache. Assume its bad php. Have also blocked some attempts to get in via wordpress which we certainly have not got. Some of the wiki configuration after our upgrade/recovery is very suspicious and have amongst other minor changes reverted skins to correct mediawiki version but copied over KHTMLFixes which is the webkit horizontal scroll bar issue- bots seem to have been asking for lots of deep php files outside monobook which was only skin updated, see how long memory stays at about 652000k free max after this change ...any things worth a tryMlj 19:21, 30 December (UTC)
Still memory leak that fills it in days. Only reason no outage is that I have been able to reboot in good time over Xmas break. 07:42, 4 January (UTC)
Memory leak continues. I managed to overload database connections forcing it to go into swap with just editing 25 odd pages fairly quickly with a template replacement at the same time it was being hit hard by an indexing bot that used up 700000k of memory in no time. Suspect some of my concurrent thread control has made a slight difference but it definitely does not like going into swap. Mlj 20:57, 15 January (UTC)
Went down about 30 minutes ago when I was in monitoring memory leak. Fails when swap greater than real memory and this suddenly happened when apparently server bombarded by over 400 httpd requests when it looked like we had 40% of memory still available - I thought I had limited number of apache processes to below this. Still there is an apache associated memory leak as I killed down apache first and this released very reasonable amount of memory, presumably in PHP as far as I can tell.Ah well00:11, 20 January (UTC)
Blame today's outage on not being able to cope with all those attempts to exploit wordpress vulns in the news but the truth is our LAMP is beyond its sell by date and has been limping with daily maintenance for weeks and I was just seeing how long it could stay up for with present limits on concurrent apache processes. The answer is less than 36 hours with nasty net out there checking anything that serves php. Oh well. Mlj 22:11, 10 February (UTC)
Another predictable crash due to memory leak. Just wish some processes were not active that really should not have been as root when I went in. Will look at logs now back up.23:56, 16 March (UTC)
Very flaky, will try some apache parameters that may decrease the 430 odd http processes that I found when I finally got in and that took an hour to kill. No definite DOS at time it went over Mlj 00:42, 21 March (UTC)
Sorry all: My attempts at reducing apache foot print are making absolutely no difference to robustness to date and we are now falling over in 12 hour periods. Need new installation.Mlj 22:54, 6 April (BST)
Rowing back on my attempts to make Apache more stable by lower memory requirements as they may have created inability to cope with bot demand Mlj 12:43, 8 April (BST)
Now trying to reduce MaxKeepAliveRequests from 100 and maxspare servers from 10 but of course website would be better with value now days up to 1000 for formerMlj 21:43, 9 April (BST)
Now increased MaxKeepAliveRequests but limiting server processes more - makes Apache more stable and MySQL less. Oh well at least easy to get into fix Mlj 08:10, 11 April (BST)
Continues very sick. Fell over when reached MAXCLIENTS of 7 and loss DataBase connection - used to be 10 so I am increasing more slowly just to see if lasts longer Mlj 22:18, 11 April (BST)
Now seeing if main memory leak was in skins - reverted to version with a few tidy ups - successfully to date - have not yet updated file upload php on principle some php in v1.16.5 may be causing leakMlj 21:53, 14 April (BST)
Been in logs this afternoon as server had gone crazy again.
Site activity including silent bots
Memory leak significance seems to have been created by a very badly behaviour from bots from range IP range 46.229.168.65 to 46.229.168.75 as before which were not being blocked from php engine or robots.txt. These bots were giving very complex commands including redirection, hidemyself and chasing down every edit a page had had with no lag time, hidden amongst more benign but uncontrolled harvesting. Effectively we have been under a DoS attack from semrush. It seems the error_log file from Apache will get very big now but if machine survives tonight I will see if I can rotate. Our bot site load has doubled since Jan due to this (have pretty graph going back to that shows bot activity had increased over 50 fold since but was silent to site and our google monitoring by marketing orientated design. Oh well. They will no doubt try other tricks. Server has been stable for a few hours now Mlj 23:47, 23 April (BST)
Memory leak could still bring server down within a few days reckon. Monitoring and attempts at fine tuning will continue. Now generates 3% of disk space in a week of log files from all the blocked bots and Apache does not like its log files being rotated - all automated solutions seem to require server down time for a few minutes a day - need a shell script kiddie :-<. Mlj 07:58, 24 April (BST)
Ah, Apache log rotate never set up properly at the beginning. Wonder if all the right utilities are around ? Has Apache never been given an automatic rest all these years as doing that the hard part ? Mlj 08:12, 29 April (BST) - hack to logrotate apache logs tested Ok so now in place last 7 days only saved
Well that did not completely work. Brief down time today may have been associated with DoS but other things still not configured right from look of it Mlj 08:37, 4 May (BST)

REBOOT is now straight into fully working server after lots (for me) of log and start up script reconfiguration. This necessary due to failure as yet to resolve memory leak so reboot at moment quite frequent Mlj 08:23, 19 May (BST)

pubmed_caption_finder

This has to be updated given PubMed's shift to https from tomorrow. From today it will generate https references BUT the module still uses http call in php (as https call not recognised) to get all the info. This will no doubt change and give us message "Unable to contact Pubmed. This may be transient - please try again later. If this error recurs, please contact a ganfyd admin." If in due course I can enable php to do https I have version 20 of the module uploaded and ready to go and replace present version 21 (we were on version 19 before today) CheersMlj 18:37, 26 September (BST)

Oh bother, the only easy hope is that openssl is compiled into our php. Then if etc/perl4/apache2/php.ini or whatever has line extension=php_openssl.dll added and is recognised all might work when they switch off http completely. This could be disastrous if it does not work. Whatever a test will mean switching apache off and on again with new php.ini file sometime. Anyone brave enough to do this ? Mlj 23:38, 28 September (BST)
We are looking a bit obsolete. Needs a new server etc, but I'm nervous. Midgley 13:48, 29 October (BST)
There is no need to be nervous. Moving to a new server will be straightforward. LAMP is bread & butter stuff. I've done dummy runs on increasingly modern distros a few times - sadly, we've never followed through and got new (possibly virtual) hardware. Optionally, we could move away from Apache to a more efficient server - I think Wikimedia use lighttpd. A new server will offer superior performance at less cost. —Rupert (Talk) 16:41, 29 October (BST)
LAMP is bread & butter but shifting the wiki? I think it is time to do this though, the hosting company is keen to get us off the old hardware. Midgley 14:30, 7 December (UTC)
Oh, and while Apache is patchy and old, I'd stick with it, to avoid making too many changes in one go. Midgley 14:31, 7 December (UTC)
Looks like our pubmed_caption_finder is now broken courtesy of pubmed removing their http redirect to https on their back room server. I may have time later to see if Apache fix above works but doubt it. Mlj 10:18, 6 November (UTC)
pubmed_caption_finder is now back working. I have done an awful hack using for source of article details but their RESTful backend is still http so we have all functionality back except ability to flag in red retracted papers. Identified a few code improvements that could be made to the pHp for greater efficiency but did not bother once I identified that at present not all perfect with europepmc server software serving up full articles in pdf. Mlj 23:08, 3 December (UTC)
Have we ever thought of using a DOI finder instead/as well? (Sorry if this has been considered previously...) --Penglish 13:33, 7 December (UTC)
The DOI is extracted and is used for the external link (as intended !), with the DOI discoverable by mouse hover on a desk top. If you want the DOI where present explicately stated as part of the reference this is trivial to code but redundant for most. With new database we are using also trivial to code the pHp to indicate if DOI link should be free to down load and even give the free download URL although if you wanted pdf free downloads thats a bit more text processing to code due to an oversight by the University of Cambridge that I may get around to tell them to correct sometime now I have worked out their error and the fix. The functionality limits are defined by the XML fields returned from the Restful API with the resulttype parameter set as core. The URL that follows will return to your browser an XML example of the fields that you can ask me to code reference functionality from. This XML database is different from the one returned by the pubmed API and which we have used since so some functionality would take a bit of new coding: src:med&format=xml&resulttype=core this is a naughty URL format that they should not have used as it contains a space character. For example our original coders (great power to Adam and Rupert - at that time I had not done any major coding in pHp) debugged an option to display the abstract text on hover which would be trivial to implement as usable functionality for most now we have all major browsers on a common standard but was hell back in the days of IE rather than Edge. It would however inflate page size in any page using references considerably for functionality users can get by two mouse clicks anyway and this may be why Rupert/Adam never implemented functionality as back then some browsers did not cope with pages sizes greater than 32K. Mlj 22:00, 7 December (UTC).
pubmed_caption_finder is now dead again due to RESTful backend moving to https. I am contemplating that short of doing our own overdue rebuild which will needs lots of Wikimedia sort outs so is not just a relatively trivial off the shelf LAMP creation exercise, the only quick way to maintain this service if no http server exists is create an http webserver whose only function is to serve the XML from querying one of the https databases back to ourselves. The load is so low from Ganfyd alone I suppose I could do it on a locked down RaspberryPi exposed to the wide world if my ISP gave me a fixed address. However better solution is to look at virtual servers, which we need anyway if GANFYD to to survive. No time to look at options in more detail due to winter pressures and work Mlj 18:28, 21 January (UTC)

System Admin

I've trimmed the list of URLs and IP addresses. This should not be perceptible but reduces the complication of the account, and slightly its cost. ganfyd and ganfyd are available as is medipaedia. Midgley 13:50, 29 October (BST)

gives me an idea - see separate email Mlj 23:16, 31 October (UTC)
PHP version is now 7.0 according to the account management setup at the host. 5.5 is no longer fully-supported. Midgley 00:12, 2 December (UTC)

10 years + on...

Things are a bit quiet now.

We could seek to attract a new generation of editors, or change the format, or archive it.

I don't really have the stamina now to tour the country telling people it is a good idea, besides, good ideas seem unfashionable this year. Midgley 20:03, 6 December (UTC)

DOS attacks

We are being hit every day or so (less today) by someone running through every php script (mainly Wordpress) that is presumably vulnerable. Server just can not cope and there is no doubt that ultimately its exceeding our memory and site stops responding when goes into Swap. Ultimately the repeat attacks are enough after about two days to bring everything down as we definitely have a memory leak somewhere. Will see if I can alter Apache timeouts Mlj 20:26, 18 March (UTC)

If it all falls over in next day

Trying some deep maintenance to make server appear more robust then it really is. Chance could all fall over but think I understand what I am doing after keeping it limping for 2 months. Backups should exist Mlj 21:58, 28 July (BST).

All went well, only one process is now creating files that need manual removal as would otherwise use up about 35% of disk space in 3 months. Hopefully should be stable for weeks more. Any other administrators should read InfoToRestartGANFYD file in /home to understand naughty and potentially annoying hacks if in due course a server migration takes placeMlj 08:35, 29 July (BST)
Update after a year. Removal of old MySQL log files every 6 months is only manual task that seems necessary, now server refreshes itself every day. Of course the real task one day is a new https server. Mlj 23:10, 18 July (BST)

Succession

I'm getting steadily more and more retired, and need to hand the management, and paying for, the hosting on. Midgley 20:11, 19 September (BST)

I have helped the paying for. Mlj 18:30, 21 January (UTC)
It is greatly appreciated. I'm now out of Medicine, and embarking on a building project and need to hand the whole thing over. If the team will put up with it I'd like to remain a member/user and do sub-editing and so on. Midgley 12:56, 13 April (BST)
The end of the financial year is probably a good time for such things. Midgley 12:58, 13 April (BST)
I have a contact who can haul down a backup for reinstallation, set up a new server, play this back on to it and host for less than the current hosting. I'm inclined to just go ahead with that - there might be a short gap, and if this carries on during it updates wuold not make it into the new installation. Midgley 10:32, 22 April (BST)
Good. I have no definite time to commit for at least 6 months. Rupert did volunteer to try to get a new server going but the key issue is successful migration from the old and time for administration when holding down a job in medicine. Happy to help within my limited skill base but the administration involved in a server transition would be a minefield for the likes of me I suspect Mlj 22:26, 22 April (BST)

Registration

It seems reopening to registration opened us up to the good old denial of service attacks causing us to crash. I have not yet had time to work out who I need to block from log files. We will see how long it stays up for. Registration will stop working soon as I have turned off the DNS redirection as that should help. Mlj 01:07, 21 December (UTC)

Yes the logs were interesting: some one was trying to get in with a script that quickly cycled through a long list of exploitable php files. Now blocked but presumably a pawned server that some one uses to quickly targets new domain name registrants - the information is certainly available. May try again re-enabling registration sometime over Xmas Mlj 00:21, 22 December (UTC)
The fixes have worked for a month, but I see yet again someone external doing something has broken another useful feature (pubmed_caption_finder section above) Mlj 18:35, 21 January (UTC)
The pubmed problem is almost certainly a consequence of the US government shut down. When the government shuts down, PubMed (which is run by the US government) shuts down. I assume that, when PubMed starts working again, so will this feature. --Penglish 13:10, 22 January (UTC)
Oops - I just see you'd already established that it is NOT due to the government shut down. Sorry! --Penglish 13:12, 22 January (UTC)