diff options
author | Herman van Rink | 2015-07-19 20:15:49 (GMT) |
---|---|---|
committer | Herman van Rink | 2015-07-19 20:15:49 (GMT) |
commit | ea632e0a5b2e6e5387b51915e949eff355dd717d (patch) | |
tree | 46dc80b6f0d58980e455703dd8575a1ce5dc1306 | |
parent | b582b2abb241eda14b924366c62403741508c607 (diff) |
cleanup
-rw-r--r-- | HACKING_2x.mdwn | 206 |
1 files changed, 0 insertions, 206 deletions
diff --git a/HACKING_2x.mdwn b/HACKING_2x.mdwn deleted file mode 100644 index 6b13499..0000000 --- a/HACKING_2x.mdwn +++ /dev/null @@ -1,206 +0,0 @@ -This document summarizes issues I have found while working offline on -Aegir 2.x on june 2012. It should be posted as a blog or something. - -Install notes -============= - -Those are notes from a manual install of Aegir 2.x using the Nginx -backend. I have taken those notes instead of filing bugs as this work -was done offline. - -use sudo instead of su ----------------------- - -use the following instead of su aegir: - - sudo -u aegir -H /bin/bash - -install drush through PEAR --------------------------- - -we should follow Arch linux's lead and install drush through PEAR, as -it is upstream's suggestion. - -aegir 2.x modifications ------------------------ - - 1. install drush 5 instead of drush 4 (should be in the docs) - 2. we don't depend on drush make anymore, as it's in drush 5 core!! - make sure we change the hostmaster-install help and process at the - very least (done?) - -other issues ------------- - - * we should not talk about using a makefile if the hostmaster platform - already exists - * the aegir config file generates this nginx error: - - nginx on localhost could not be restarted. Changes might not be available until this has been done. [warning] - (error: Reloading nginx configuration: nginx: [emerg] "error_log" directive is duplicate in - /etc/nginx/conf.d/aegir.conf:107 - - (fixed) - - * install error: - - The hosting_platform_pathauto module is required but was not found. Please move it into the modules [error] - subdirectory. - - (fixed by removing said module, would need to be merged in) - - * the nginx config file is way too big, it sets policy, like hiding - headers, SSL performance, gzip compression, size limits and so - on. those do not belong in an aegir configuration file, and should - at least be optional. the fastcgi_params are also duplicate of a - file in /etc/nginx.conf - - (work started in the dev-nginx-cleanup branch) - - * out of the box, nginx shows "bad gateway" error when following the - login link - fix: - - diff --git a/php5/fpm/pool.d/www.conf b/php5/fpm/pool.d/www.conf - index 28a0651..e6d552d 100644 - --- a/php5/fpm/pool.d/www.conf - +++ b/php5/fpm/pool.d/www.conf - @@ -30,7 +30,8 @@ group = www-data - ; specific port; - ; '/path/to/unix/socket' - to listen on a unix socket. - ; Note: This value is mandatory. - -listen = /var/run/php5-fpm.sock - +;listen = /var/run/php5-fpm.sock - +listen = localhost:9000 - - ; Set listen(2) backlog. - ; Default Value: 128 (-1 on FreeBSD and OpenBSD) - - not sure how to fix this - - * the nginx includes may fail on remote servers because - /var/aegir/config/includes may not be rsync'd to remote servers - - * the nginx advanced and simple configuration are almost exactly the - same minus about 10 lines of diff - they should include each other - instead of duplicating stuff - - (fixed in cleanup branch) - -things i forgot ---------------- - - * forgot to clone pkg-drush - * forgot to install the nginx-doc package - * forgot to install ab or siege (crap) - -offline hacks -------------- - -I had to go through a few hoops to make this work offline. To install -drush, i worked from a previous clone I had lying around: - - sudo aegir -H git clone ~anarcat/src/drush - sudo ln -s /var/aegir/drush/drush /usr/local/bin/drush - -And the same for provision: - - sudo aegir -H git clone ~anarcat/src/provision .drush/provision --branch 6.x-2.x - -Then for the frontend (trickier), I had to fiddle around with also a -previously existing hostmaster platform: - - git clone ~anarcat/src/drupal hostmaster-6.x-2.x --branch 6.26 - git clone ~anarcat/src/hostmaster hostmaster-6.x-2.x/profiles/hostmaster --branch 6.x-2.x - cd hostmaster-6.x-2.x/profiles/hostmaster - cp -a ~/hostmaster-6.x-1.x/profiles/hostmaster/modules/{admin_menu,install_profile_api,jquery_ui,modalframe,openidadmin} modules - -Multiserver redesign -==================== - -One of the things I have been thinking of doing for a while was to -move the dispatcher to the backend and move more logic to remote -servers. This section details my findings related to that work - -Task queue ----------- - -This queue is tightly bound with the frontend. There's a complete -'task' module, complete with a database schema, in the hosting -package. It would be difficult if not illogical to move all that stuff -to the provision module. - -This, in turn, makes it difficult to implement the task queue on the -remote servers directly. - -An alternative would be to keep the task module in the frontend but -create a skeleton implementation in the backend that would do the task -unserialization necessary to produce the drush task. - -In other words, we would need to split the task module in two: one -part which would write tasks to the MySQL database (by default, other -backends could be implemented!) and another end (on the provision -side), which would read tasks from the database. - -The dispatcher --------------- - -The dispatcher, however, is less bound with the frontend. It uses the -Drupal variable storage for locking itself, but that is probably not a -blocker for moving the code to the backend. - -In fact, we could consider simply dropping all this code in favor of -the more stable, complete and logical hosting_queued. - -Settings for the queues that are used by the dispatcher could still be -managed by the frontend, provided we clearly specify which settings -are applied of course. Again, those settings are specific to our MySQL -"ghetto queue" implementation and could be extended to support other -queuing systems. - -Multiple queue support ----------------------- - -Moving the dispatcher code to the backend would have the advantage of -allowing that logic to be moved out of the main site, and allow to -have multiple queues, for example one per server. - -For this, we would need to have a server column to separate the queues -directly in the SQL tables. This, in turn, would duplicate the server -information, which is already in the hosting_site/platform/server -tables. In other words, maybe this information should be fetched -through a JOIN instead. - -Aliases location ----------------- - -Regardless, that information is also duplicated in the drush aliases, -which would need to be synced to remote servers anyways. One of the -reason for the hub/spoke model is that it makes it much easier to find -where a site is - you just look in the alias and there you are, you -log into that server and you do your things. - -Having a queue per server would probably mean completely removing -certain aliases, specifically the server aliases, which could mean -problem for slave servers in the 'pack' cluster module. - -The cron queue --------------- - -The cron queue is an odd anomaly in all this. It is the only known -implementation of the "batch" queue (although there is talk of -implementing a civicrm cron queue). It also happens to oddly duplicate -and overlap the functionality of the builtin cron daemon, which it -depends on. - -My thought is currently to *not* duplicate the functionality of cron -(which we depend on *anyways* - we do not want to reimplement this in -hosting_queued I believe) and instead start looking at writing cron -jobs individually to the crontab. This could be done in the verify -task of sites. - -Unfortunately, the crontab command doesn't feature a locking -mechanism, which means we will have to implement our own to avoid -overwriting changes if we ever allow some tasks to be ran in parallel. - -Nevertheless, this seems like a much simpler implementation that would -also allow per-task cron periods. |