Code Monkey home page Code Monkey logo

ansible.plone_server's Introduction

plone_server

This Ansible role provisions a Plone server with options to control client count and memory profile. It uses either a built-in buildout .cfg file (live.cfg by default) or one picked up via git.

This role takes care of:

  • Installing the required OS (development-) packages;
  • Creating users and groups for running buildout and daemons;
  • Downloading a buildout-cache tarball and checking out your buildout if needed;
  • Building the ZEO cluster;
  • Optional: setting up supervisor for process management and autostart;
  • Optional: installing cron-jobs for packing the database and backup.

If you'd like to use this role as part of a full-stack configuration kit, see the Plone Ansible Playbook.

This role should be able to work with Plone 4.3.x or 5.0. Just set the version variables documented below.

.. warning::

Some of the changes made in version 1.2.0 may cause your Plone-related supervisor job names to change.
To avoid problems, before you first run this version of the role, stop your Plone-related supervisor jobs and remove them from the supervisor/conf.d directory.

Requirements

Version 1.3.2 requires Ansible 2.5+.

Since this role creates and uses users and groups, it must be run as part of a playbook that sets sudo to "yes".

Currently working with Debian/Ubuntu, FreeBSD11 and CentOS/Fedora environments. Please put in a pull request if you can help get it going in other ansible's os families.

If you need to log in

You should not need to. But if you do, you should know:

  1. The Plone zeoserver and zeoclient processes should be run under the plone_daemon login; they will normally be controlled via supervisor;

  2. Run buildout as plone_buildout.

Role Variables

ansible_ssh_pipelining

ansible_ssh_pipelining: true

This role uses ssh pipelining to avoid security errors from Ansible when running operations without superuser rights. SSH pipelining for this purpose may require the disabling of ‘requiretty’ in /etc/sudoers. If you get a pipelining error and cannot disable requiretty, set this variable to false and instead turn on allow_world_readable_tmpfiles in your ansible.cfg. See http://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-user for a discussion.

plone_instance_name

plone_instance_name: frodos_site

Sets the name that discriminates this install from others. This name should be globally unique on the server as it's used to discriminate between supervisor and cron jobs.

Defaults to zeoserver.

.. warning::

Choose plone_instance_name carefully - as changing it later will leave directories, supervisor jobs,
cron jobs etc relating to the old name, that can only be tidied up *manually* if you want to
do so (and you probably will).

plone_target_path

plone_target_path: /opt/plone

Sets the Plone installation directory.

Defaults to /usr/local/plone-{{ plone_major_version }}

Your install's buildout directory will be {{ plone_target_path }}/{{ plone_instance_name }}.

plone_var_path

plone_var_path: /var/plone_var

Sets the Plone installation directory.

Defaults to /var/local/plone-{{ plone_major_version }}

Your install's var directory will be {{ plone_var_path }}/{{ plone_instance_name }}.

plone_backup_path

plone_backup_path: /mnt/backup/plone

Where do you want to put your backups? The destination must be writable by the plone_daemon user. Subdirectories are created for blob and filestorage backups.

Defaults to your instance's var directory.

Your install's backup directory will be {{ plone_backup_path }}/{{ plone_instance_name }}.

plone_buildout_git_repo

plone_buildout_git_repo: https://github.com/plone/plone.com.ansible.git
plone_buildout_git_version: master

plone_buildout_git_repo defaults to none (uses built-in buildout).

plone_buildout_git_version is the tag or branch. Defaults to master.

If you use your own buildout from a repository, you still need to specify your client count so that the playbook can 1) set up the supervisor specifications to start/stop and monitor clients, and 2) set up the load balancer.

Client part names must follow the pattern client# where # is a number (1,2,3 ...). Client ports must be numbered sequentially beginning with 8081 or the value you set for plone_client_base_port. The zeoserver part must be named zeoserver and be at 8100 or the value you set for plone_zeo_port.

If you use your own buildout, all Plone settings except plone_client_count, plone_client_base_port, and plone_client_max_memory are ignored.

plone_major_version

plone_major_version: '5.0'

plone_version

plone_version: '5.0'

Which Plone version do you wish to install? This defaults to the current stable version at the time you copy or clone the playbook. Make sure plone_major_version and plone_version are string variables or they won't compare correctly.

plone_python_version

plone_python_version: '2.7'

For Plone 5.2+, you may specify '2.7' or '3'. Earlier Plones must use '2.7'.

plone_initial_password

plone_initial_password: alnv%r(ybs83nt

Initial password of the Zope admin user. The initial password is used when the database is first created. Don't forget to change it.

Defaults to "" -- which will cause the role to halt.

plone_client_count

plone_client_count: 5

How many ZEO clients do you want to run?

Defaults to 2.

May be set to 0 if you need no regular clients on the target server.

The provided buildout always (even if plone_client_count is 0) creates an extra client client_reserve that is not hooked into supervisor or the load balancer. Use it for debugging, run scripts and quick testing.

plone_zodb_cache_size

plone_zodb_cache_size: 30000

How many objects do you wish to keep in the ZODB cache.

Defaults to 30000

The default configuration is very conservative to allow Plone to run in a minimal memory server. You will want to increase this is you have more than minimal memory.

plone_zodb_cache_size_bytes

plone_zodb_cache_size_bytes: 512 MB

Target size for the ZODB cache.

Defaults to 0 -- which is unlimited. The object-count limit is then the only constraint.

Note that ZODB documentation indicates this feature is experimental.

plone_zserver_threads

plone_zserver_threads: 2

How many threads should run per client?

Defaults to 1

plone_client_max_memory

plone_client_max_memory: 800MB

A size (suffix-multiplied using "KB", "MB" or "GB") that should be considered "too much". If any Zope/Plone process exceeds this maximum, it will be restarted. Set to 0 for no memory monitoring.

Defaults to 0 (turned off)

This setting is used in configuration of the memmon monitor in supervisor: superlance plugin.

If you want to set plone_client_max_memory to a non-zero value, but do not wish to use superlance, set plone_hot_monitor to something other than superlance. This option was added to allow use of an alternative memory check mechanism in the Plone Playbook.

plone_additional_eggs

plone_additional_eggs:
    - Products.PloneFormGen
    - collective.cover
    - webcourtier.dropdownmenus

List additional Python packages (beyond Plone and the Python Imaging Library) that you want available in the Python package environment.

The default list is empty.

Plone hotfixes are typically added as additional eggs.

plone_sources

plone_sources =
  -  "my.package = svn http://example.com/svn/my.package/trunk update=true"
  -  "some.other.package = git git://example.com/git/some.other.package.git rev=1.1.5"

This setting allows you to check out and include repository-based sources in your buildout.

Source specifications, a list of strings in mr.developer sources format. If you specify plone_sources, the mr.developer extension will be used with auto-checkout set to "*".

plone_extension_profiles

plone_extension_profiles:
    - jarn.jsi18n:default

List additional Plone profiles which should be activated in the new Plone site. These are only activated if the plone_create_site variable is set.

plone_zcml_slugs

plone_zcml_slugs:
    - plone.reload

List additional ZCML slugs that may be required by older packages that don't implement auto-discovery. The default list is empty. This is rarely needed.

plone_additional_versions

plone_additional_versions:
  - "Products.PloneFormGen = 1.7.16"
  - "Products.PythonField = 1.1.3"
  - "Products.TALESField = 1.1.3"

The version pins you specify here will be added to the [versions] section of your buildout. The default list is empty.

plone_install_zeoserver

plone_install_zeoserver: no

Allows you to turn on and off the creation of a zeoserver. Defaults to yes. Useful if the zeoserver is not on the same machine as the clients.

plone_zeo_ip

plone_zeo_ip: 192.168.1.100

The ip address for the Zope database server. Defaults to 127.0.0.1. Useful if the zeoserver is not on the same machine as the clients.

plone_zeo_port

plone_zeo_port: 6100

The port number for the Zope database server. Defaults to 8100.

plone_client_base_port

plone_client_base_port: 6080

The port number for your first Zope client. Subsequent client ports will be added in increments of 1. Defaults to 8081.

plone_environment_vars

plone_environment_vars:
    - "TZ US/Eastern"
    - "zope_i18n_allowed_languages en"
    - "zope_i18n_compile_mo_files true"
    - "PYTHONHASHSEED random"

A list of environment variables you wish to set for running Plone instances.

Defaults to:

- "zope_i18n_compile_mo_files true"

plone_client_extras

plone_client_extras: |
    z2-log-level = ERROR

Extra text to add to all the client buildout parts. Don't use this to add zope-conf-additional stanzas, as they may be overriden.

plone_zeo_extras

Extra text to add to the ZEO server part of the buildout.

plone_zope_conf_additional

plone_zope_conf_additional: |
    <product-config foobar>
        spam eggs
    </product-config>

Use this directive to add a zope-conf-additional section to client zope configurations.

plone_client1_extras

plone_client1_extras: |
    webdav-address = 9080
    ftp-address = 8021

Extra text to add to only the first client buildout part.

plone_autorun_buildout

plone_autorun_buildout: (yes|no)

Do you wish to automatically run buildout if any of the Plone settings change? Defaults to yes.

plone_always_run_buildout

plone_always_run_buildout: (yes|no)

Do you wish to run buildout even if the buildout has not changed? Mainly useful in CI situations.

plone_buildout_cfg

plone_buildout_cfg: live.cfg

This avoits conflicts with local buildout.cfg for development and the generated file on the server used for production/staging. Default to live.cfg.

plone_buildout_cache_url

plone_buildout_cache_url: http://dist.plone.org/4.3.4/buildout-cache.tar.bz2

The URL of a buildout egg cache. Defaults to the one for the current stable version of Plone.

plone_buildout_cache_file

plone_buildout_cache_file: /home/steve/buildout-cache.tar.bz2

The full local (host) filepath of a buildout egg cache. Defaults to none. Should not be used at the same time as plone_buildout_cache_url.

plone_extra_parts

plone_extra_parts:
  zopepy: |
    recipe = zc.recipe.egg
    eggs = ${buildout:eggs}
    interpreter = zopepy
    scripts = zopepy
  diazotools: |
    recipe = zc.recipe.egg
    eggs = diazo

Extra parts to add to the automatically generated buildout. These should be in a key/value format with the key being the part name and the value being the text of the part. Defaults to {}.

plone_buildout_extra

plone_buildout_extra: |
  allow-picked-versions = false
  socket-timeout = 5

Allows you to add settings to the automatically generated buildout. Any text specified this way is inserted at the end of the [buildout] part and before any of the other parts. Defaults to empty.

Use this variable to add or override controlling settings to buildout. If you need to add parts, use plone_extra_parts for better maintainability.

plone_buildout_extra_dir

plone_buildout_extra_dir: local_path

Copies a local directory or the contents of a directory into the buildout directory on the remote server.

Use this variable to drop extra files (or even subdirectories) into the buildout directory. Local path may be absolute or relative to the playbook directory. Put a "/" on the end of the local path if you wish to copy the contents of the directory. Leave off the trailing "/" to copy the directory itself.

If the copied files change, buildout will be run if plone_autorun_buildout is true (the default). However, the autorun mechanism is not able to detect any other kind of change. For example, if you've used this setting, then remove it, the autorun will not be triggered.

plone_extra_find_links

plone_extra_find_links:
  - http://download.zope.org/distribution/
  - /some/otherpath
  - /some/path/someegg-1.0.0-py2.3.eggs

Allows you to add to the list of locations to search for distributions.

plone_create_site

plone_create_site: no

Should we create a Plone site in the ZODB when it's first initialized? Defaults to 'yes'.

plone_download_requirements_txt

plone_download_requirements_txt: yes

Should we download a requirements.txt file from dist.plone.org for the matching version of Plone? If you set this to no, or if dist.plone.org does not have a requirements file for the target version, we'll create one from a template. If we create from template, the following settings are used, all of which may be overriden:

plone_setuptools_version: '26.1.1'
plone_zc_buildout_version: '2.5.3'
plone_pip_version: '10.0.1'

However the requirements.txt file is created, it will be used via pip to prime our virtualenv.

plone_site_id

plone_site_id: client55

If we're creating a Plone site, what should the id be? Defaults to 'Plone'.

plone_extension_profiles

plone_extension_profiles:
    - jarn.jsi18n:default

List additional Plone profiles which should be activated in the new Plone site. These are only activated if the plone_create_site variable is set. Defaults to empty.

plone_default_language

plone_default_language: es

If we're creating a Plone site, what should be the default language? Defaults to 'en'.

plone_client_tcpcheck

plone_client_tcpcheck: off

As of plone server role version 1.3.0, we use five.z2monitor to set up monitor threads for each Plone ZEO client. You may use this directive to turn this off.

If you are using Python 3+, you'll want to check to see if five.z2monitor has a compatible update. Otherwise, turn this off.

plone_client_base_tcpcheck_port

plone_client_base_tcpcheck_port: 7200

If plone_client_tcpcheck, monitor threads will be configured for each Plone ZEO client. This directive allows you to control the base port. There will be as many ports used as there are Plone ZEO clients. The default is "{{ plone_client_base_port + 100 }}". This is not a global variable; it may only be overridden in the plone_config argument when the role is called.

Cron jobs

plone_pack_at

plone_pack_at:
  minute: 30
  hour: 1
  weekday: 7

When do you wish to run the ZEO pack operation? Specify minute, hour and weekday specifications for a valid cron time. See CRONTAB(5). Defaults to 1:30 Sunday morning. Set to no to avoid creation of a cron job.

plone_keep_days

plone_keep_days: 3

How many days of undo information do you wish to keep when you pack the database. Defaults to 3.

plone_backup_at

plone_backup_at:
  minute: 30
  hour: 2
  weekday: "*"

When do you wish to run the backup operation? Specify minute, hour and weekday specifications for a valid cron time. See CRONTAB(5). Defaults to 2:30 every morning. Set to no to avoid creation of a cron job.

plone_keep_backups

plone_keep_backups: 3

How many generations of full backups do you wish to keep? Defaults to 2.

Daily backups are typically partial: they cover the differences between the current state and the state at the last full backup. However backups after a pack operation are complete (full) backups -- not difference operations. Thus, keeping two full backups means that you have backups for plone_keep_backups * days_between_packs days. See the collective.recipe.backup documentation.

plone_keep_blob_days

plone_keep_blob_days: 21

How many days of blob backups do you wish to keep? This is typically set to keep_backups * days_between_packs days. Default is 14.

plone_rsync_backup_options

plone_rsync_backup_options: --perms --chmod=ug+rx

Rsync options set within the backup scripts (see collective.recipe.backup). This can be used (for example) to change permissions on backups so they can be downloaded more easily. Defaults to empty.

Supervisor Control

plone_use_supervisor

plone_use_supervisor: no

When set to yes (the default), the role will set up supervisor to start, stop and control the ZEO server and all the clients except the reserved client.

plone_restart_after_buildout

plone_restart_after_buildout: yes

When set to yes (the default), the role will restart the clients that are running under supervisor whenever buildout runs. This may be undesirable in situations where uptime is a high priority and clients are slow to start serving requests.

The full Plone Ansible Playbook has a nice alternative in such cases: a restart script that removes clients from the load-balancer cluster and doesn't return them until after priming caches.

Example Playbook

Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:

- hosts: all
  sudo: yes
  gather_facts: no

  pre_tasks:

    - name: Update host
      apt: upgrade=dist update_cache=yes

  roles:

    - role: plone.plone_server
      plone_initial_password: super_secret

Multiple Server Example

Here's an example playbook that sets up multiple Plone servers on the same target. Note the use of distinct plone_instance_name settings to make sure that cron and supervisor jobs do not collide.

- hosts: all
  sudo: yes
  gather_facts: yes

  pre_tasks:

    - name: Update host
      apt: upgrade=dist update_cache=yes

  roles:

    - role: plone.plone_server
      plone_instance_name: primary_plone
      plone_target_path: /opt/primary_plone
      plone_var_path: /var/local/primary_plone
      plone_major_version: '5.0'
      plone_version: '5.0'
      plone_initial_password: admin
      plone_zeo_port: 5100
      plone_client_base_port: 5080
      plone_create_site: no

    - role: plone.plone_server
      plone_instance_name: secondary_plone
      plone_target_path: /opt/secondary_plone
      plone_var_path: /var/local/secondary_plone
      plone_major_version: '4.3'
      plone_version: '4.3.7'
      plone_initial_password: admin
      plone_zeo_port: 4100
      plone_client_base_port: 4080
      plone_create_site: no

  tasks:
    - pause: seconds=30

    - name: Check to see if Plone 5 is running
      uri:
        url: http://127.0.0.1:5081/
        method: GET
        status_code: 200

    - name: Check to see if Plone 4.3.x is running
      uri:
        url: http://127.0.0.1:4081/
        method: GET
        status_code: 200

License

BSD-3-Clause

Author Information

Created by Steve McMahon. Maintained by the Plone Installer Team as part of the Plone project.

ansible.plone_server's People

Contributors

alecpm avatar djowett avatar fulv avatar gforcada avatar gomez avatar htgoebel avatar jensens avatar jpgimenez avatar l00ptr avatar mrtango avatar oggers avatar polyester avatar rockfruit avatar smcmahon avatar stevepiercy avatar tkimnguyen avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ansible.plone_server's Issues

plone_environment_vars issues

  1. The docs (both in ansible.plone_server and in ansible-playbook incorrectly say this 'Defaults to:

    "PYTHON_EGG_CACHE ${buildout:directory}/var/.python-eggs"'

Actually it defaults to

"zope_i18n_compile_mo_files true"
"PYTHON_EGG_CACHE {{ plone_var_path }}/{{ plone_instance_name }}/.python-eggs"

Or actually something slightly different if using the multi-server setup.

  1. When using playbook_plones, a global setting for this is ignored (probably because plone_instance_name changes per plone instance), but it's not easy to guess that's going to happen. To override this I have to set

    work_environment_vars:
    - "PYTHON_EGG_CACHE ${buildout:var-dir}/.python-eggs"
    - "PYTHONHASHSEED random"

I suggest it would be better to use the buildout variable ${buildout:var-dir} for PYTHON_EGG_CACHE instead of Ansible variables which are a bit fiddly here. Then the setting of work_environment_vars here can be simplified

Definitions of sites and virtualhosts is inconsistent

In defaults/main.yml only a single site can be defined, but in templates/restart_clients.sh.j2 several sites are referenced. This is inconsistent:

  • defaults/main.yml uses plone_site_id, while the template uses vh.zodb_path
  • the template uses webserver_virtualhosts which is not documented anywhere in this role.

I volunteer implementing the following (incompatible) change if you agree on it:

  • Convert the site-related definitions into a list of sites (scratch):
plone_default_site:
  create: yes
  site_id: Plone
  default_language: en
  extension_profiles:
plone_sites = '{{ [ plone_default_site ] }}'

and then in templates/restart_clients.sh.j2 revere to these.

As I follow up, the ansible-playbook has to be adopted, which I volunteer to do, too.

Remove restart_clients script.

The restart clients script makes too many assumptions about the operating stack. It doesn't belong inside a role that may be used with a dramatically different stack.

Checking ansible version raises error

I'm using ansible 2.6.1 and when I run this role (v 1.3.2) I get the following error:

The conditional check 'ansible_version is version('2.5.0', 'lt')' failed. The error was: Version comparison: '<' not supported between instances of 'str' and 'int'

Applying the following patch solves the problem:

--- main.yml.orig<----->2018-07-18 11:12:19.028597089 +0200
+++ main.yml<-->2018-07-18 10:40:43.634116606 +0200
@@ -2,7 +2,7 @@
.
 - name: Fail if Ansible is old
   fail: msg="We need updates in Ansible 2.5.0. Please update your kit. 'pip install -U Ansible'"
-  when: ansible_version is version('2.5.0', 'lt')
+  when: ansible_version.full is version('2.5.0', 'lt')
.
 - name: Fail if no plone initial password set
   fail: msg="You must set the plone_initial_password variable."

Hope you apply the patch asap.
Thank you.

Error when using --start-at="Run buildout"

Then running the role with --start-at="Run buildout", one gets the error

fatal: [test] => error while evaluating conditional: plone_autorun_buildout and instance_status.changed

The reason is that "Copy buildout template" is not run and thus instance_status is undefined.

As a work-around, the condition could be changed into


Solving this issue would require a different condition, see issue #14 .

Task "Copy requirements file" stomps on instance_status

Both the Copy buildout template and Copy requirements file tasks register the same instance_status variable. The result is that if the buildout template has changed, but the requirements file has not, the Run buildout task is never run if:

plone_always_run_buildout = false
plone_autorun_buildout = true

(which is the default).

bootstrap fails

Due to a bad setuptools release, bootstrapping buildout was failing.

install older Plone versions

I'm trying to use this with ansible-playbook to install an older Plone version, specifically 4.2.5.
No matter what I use in plone_major_version and plone_version, the versions.cfg file that is referred to in buildout.cfg's extends line is still the one for the latest version.

Upgrade to Plone5

The good news is that upgrading to Plone 5 is really easy (see pull request).

The big question is how we want to release such an upgrade: bump the major version number? Personally, I would advocate versioning this role according to the version of Plone that is installed with it: 5.0 installs Plone 5.0, 4.3.7 installs Plone 4.3.7, etc.

memmon isn't in /usr/bin/ in Ubuntu 18.04 (Bionic)

this comes out as:

$ sudo supervisorctl
myproj_memmon                FATAL     can't find command '/usr/bin/memmon'

What's the purpose in hardcoding the path for supervisor? Is it sufficient to do the ansible equivalent of which memmon?

TypeError: coercing to Unicode: need string or buffer, int found

Because I have several things running on one machine, and I am using ansible to create/update the lot, I find it useful to have a map file containing port bases for each configuration.

In a new folder I place

- ansible.plone_server (fresh clone of master branch)
- vbox_host.cfg
- map.yml
- instance.yml

map.yml:
---
localvagrant_port_base: 11

instance1.yml:
---
- hosts: localvagrant
sudo: yes
gather_facts: no

  vars_files:
    - ansible.plone_server/defaults/main.yml
    - map.yml

  tasks:
    - include: ansible.plone_server/tasks/main.yml
      vars:
        plone_instance_name:      instance1
        plone_initial_password:   adminsecret
        plone_zeo_port:           "{{ localvagrant_port_base }}01"
        plone_client_base_port:   "{{ localvagrant_port_base }}05"

Then, I invoke the playbook for 'instance1' and I receive the following output:

campbell@campbell-np600:~/asdf$ ansible-playbook -i vbox_host.cfg instance1.yml
PLAY [localvagrant] ***********************************************************
[...]
TASK: [Copy buildout template] ************************************************
fatal: [localvagrant] => {'msg': 'TypeError: coercing to Unicode: need string or buffer, int found', 'failed': True}
fatal: [localvagrant] => {'msg': 'TypeError: coercing to Unicode: need string or buffer, int found', 'failed': True}

buildout.sanitycheck fails, "Run buildout" is not run as plone_buildout

When running this role on a Vagrant machine I get the error shown below. It looks like ansible does not honour the sudo_user: entry.

Any idea how to solve this – except of changing the commands into `sudo ... ?, of course :-)

  • ansible 1.8.1
  • ansible.plone_server 1.0b6 (from galaxy)

Inventory:

test ansible_ssh_host=127.0.0.1 ansible_ssh_port=2222 ansible_ssh_private_key_file=~/.vagrant.d/insecure_private_key ansible_ssh_user=vagrant

Shortend error message:

failed: [test] => {"changed": true, "cmd": ["bin/buildout"], "delta": "...", "end": "...", "rc": 1, "start": "...", "warnings": []}
stderr: While:
  Installing.
  Loading extensions.
Error: User attempt to give system ownership to Internet
stdout: buildout.sanitycheck: 
***********************************************************
Buildout should not be run while superuser. Doing so allows
untrusted code to be run as root.
Instead, you probably wish to do something like:
    sudu -u plone_buildout bin/buildout

Exception: Failed to execute command: in 'Bootstrap buildout' play

I'm on Ubuntu 12.04, deploying Plone 4.3.7 and am seeing an error like this:

TASK [plone.plone_server : Bootstrap buildout] *********************************
fatal: [plone11]: FAILED! => {"changed": true, "cmd": ["../python2.7/bin/python2.7", "bootstrap.py", "--setuptools-version=8.0.4"], "delta": "0:00:00.874500", ...

If I run this outside Ansible, it looks like this:

$ sudo -u plone_buildout ../python2.7/bin/python2.7 bootstrap.py --setuptools-version=8.0.4
error: None
Traceback (most recent call last):
  File "bootstrap.py", line 172, in <module>
    "Failed to execute command:\n%s" % repr(cmd)[1:-1])
Exception: Failed to execute command:
'/usr/local/plone-4.3/highfields/../python2.7/bin/python2.7', '-c', 'from setuptools.command.easy_install import main; main()', '-mZqNxd', '/tmp/tmpnwlSux', 'zc.buildout==2.5.2'

Python on Ubuntu 12.04 is only at 2.7.3, and Setuptools on the server is up at 24.3.0, so maybe that's an issue, but I can't seem to pin it down.

The only things I've found online that looks similar are these:
pypa/setuptools#543
https://mail.python.org/pipermail/distutils-sig/2014-September/024759.html

error "list object has no element 1" while checking supervisor tasks are present

I'm getting this error when running the Plone ansible-playbook, on both the initial and a subsequent run:

TASK [plone.plone_server : Supervisor zeoclient tasks are present] *************
fatal: [redacted]: FAILED! => {"failed": true, "msg": "ERROR! ERROR! ERROR! list object has no element 1"}
  • ansible-playbook: fresh clone from today
  • ansible version 2.0.0.2
  • I set plone_client_count: 4; not sure if that's relevant

Any idea what's wrong?

client/zope.conf always thinks zeoserver is 8100

I have modified the plone_zeo_port setting, and this is reflected correctly in parts/zeoserver/etc/zeo.conf. However parts/client?/etc/zope.conf always show the following:

<zodb_db main>
    # Main database
    cache-size 30000
# Blob-enabled ZEOStorage database
    <zeoclient>
      read-only false
      read-only-fallback false
      blob-dir /var/local/plone-4.3/cbt/blobstorage
      shared-blob-dir on
      server 8100
      storage 1
      name zeostorage
      var /usr/local/plone-4.3/cbt/parts/client3/var
      cache-size 128MB
    </zeoclient>
    mount-point /
</zodb_db>

plone_buildout_git_repo error

I'm trying to build my own buildout out of a git repo, so in my local-configure.yml I define:

plone_buildout_git_repo: [email protected]:myrepo.git

I get the following error:

fatal: [default] => Failed to template {% if [email protected]:myrepo.git %} True {% else %} False {% endif %}: template error while templating string: unexpected char u'@' at 9

Trying with a http url instead of git is almost the same, it complains about '//' in the string...

Support rpm enviroment

I usually deploy to rpm based environments, so I'll contribute my changes to a branch a then create a pull request.

Changing plone_client_max_memory doesn't take effect

In my case I updated 250MB to 300MB, but found that memmon restarted a process running at 260MB.

From a ps -ef analysis I can see that supervisord was not restarted when I ran Ansible. Reading around this, it seems there are some caveats of running supervisor update - it seems it may not restart relevant processes - in my case memmon. Perhaps we should be sending a SIGHUP to supervisord?

Brain dump of links
http://www.onurguzel.com/supervisord-restarting-and-reloading/ ( a bit old)
http://supervisord.org/running.html
Supervisor/supervisor#720

/etc/cron.daily/apt: DB Update failed, database locked (mailed from Cron)

I get the following email daily (4 days running so far)

Cron root@myhostname test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
/etc/cron.daily/apt:
DB Update failed, database locked

Not very alarming, but I'd rather not have it

This post suggests a fix of:

 sudo apt-get remove apt-xapian-index

but upon review it seems this package is part of the default Ubuntu (14.04) install, so I'd rather not do this. The post does have good links to other discussions though.

What happens when plone_instance_name is changed?

If you've already deployed to a server with Ansible, then I presume doing this mindlessly (or otherwise) will give you a world of hurt? if so should there be a warning about this?
if not, please tell me - I'll be happy to be wrong!

file system permissions are broken

In the current master and also in the tag 1.2.8 the file system permissions are broken:

root@plone-test1-deb8-32bit:/usr/local/plone-4.3/example# su plone_daemon 
$ pwd
/usr/local/plone-4.3/example
$ ./bin/client_reserved run scripts/addPloneSite.py  
Traceback (most recent call last):
  File "/usr/local/plone-4.3/example/parts/client_reserved/bin/interpreter", line 260, in <module>
    exec(_val)
  File "<string>", line 1, in <module>
  File "/usr/local/plone-4.3/buildout-cache/eggs/Zope2-2.13.23-py2.7.egg/Zope2/__init__.py", line 51, in app
    startup()
  File "/usr/local/plone-4.3/buildout-cache/eggs/Zope2-2.13.23-py2.7.egg/Zope2/__init__.py", line 47, in startup
    _startup()
  File "/usr/local/plone-4.3/buildout-cache/eggs/Zope2-2.13.23-py2.7.egg/Zope2/App/startup.py", line 81, in startup
    DB = dbtab.getDatabase('/', is_root=1)
  File "/usr/local/plone-4.3/buildout-cache/eggs/Zope2-2.13.23-py2.7.egg/Zope2/Startup/datatypes.py", line 287, in getDatabase
    db = factory.open(name, self.databases)
  File "/usr/local/plone-4.3/buildout-cache/eggs/Zope2-2.13.23-py2.7.egg/Zope2/Startup/datatypes.py", line 185, in open
    DB = self.createDB(database_name, databases)
  File "/usr/local/plone-4.3/buildout-cache/eggs/Zope2-2.13.23-py2.7.egg/Zope2/Startup/datatypes.py", line 182, in createDB
    return ZODBDatabase.open(self, databases)
  File "/usr/local/plone-4.3/buildout-cache/eggs/ZODB3-3.10.5-py2.7-linux-i686.egg/ZODB/config.py", line 101, in open
    storage = section.storage.open()
  File "/usr/local/plone-4.3/buildout-cache/eggs/ZODB3-3.10.5-py2.7-linux-i686.egg/ZODB/config.py", line 220, in open
    **options)
  File "/usr/local/plone-4.3/buildout-cache/eggs/ZODB3-3.10.5-py2.7-linux-i686.egg/ZEO/ClientStorage.py", line 387, in __init__
    self.fshelper = ZODB.blob.FilesystemHelper(blob_dir)
  File "/usr/local/plone-4.3/buildout-cache/eggs/ZODB3-3.10.5-py2.7-linux-i686.egg/ZODB/blob.py", line 330, in __init__
    layout_name = auto_layout_select(base_dir)
  File "/usr/local/plone-4.3/buildout-cache/eggs/ZODB3-3.10.5-py2.7-linux-i686.egg/ZODB/blob.py", line 516, in auto_layout_select
    for name in os.listdir(path):
OSError: [Errno 13] Permission denied: '/var/local/plone-4.3/example/blobstorage'

tag 1.2.5 works with the same playbook.
OS: Debian 32bit on DiagitalOcean

Add extends to buildout cache

All our server use the extends cache, as it makes them more independent from third party downtimes.

We use a task like this:

- name: Copy the buildout default cfg template
  template:
    src: "buildout_default_cfg.j2"
    dest: '$home/.buildout/default.cfg'

With this template:

[buildout]
eggs-directory = $home/.buildout/eggs
download-cache = $home/.buildout/downloads
extends-cache  = $home/.buildout/extends

Should i prepare a PR for this?

Where is `roles/plone.plone_server/tasks/main.yml`?

When running through the tutorial, I kept hitting the problem fixed in #134. I had to manually edit plone/ansible-playbook/playbook.yml:13 to the following:

when: ansible_version.full is version('2.5.0', '<')

Then after running the playbook, I had to add another instance of the same issue in plone/ansible-playbook/roles/plone.plone_server/tasks/main.yml:5.

Two questions:

  1. Why did the change in #134 not get used when I ran the playbook?
  2. Where the heck is plone/ansible-playbook/roles/plone.plone_server/tasks/main.yml in any of the repositories, or is it generated automatically somehow?

Ubuntu 20.04 LTS missing python-pip

I am testing this on Ubuntu 20.04 LTS:

TASK [plone.plone_server : Ensure required python2 packages] *******************************************************************************************************************************************************
fatal: [some.i.p.address]: FAILED! => {"changed": false, "msg": "No package matching 'python-pip' is available"}

Duplicate cron jobs

It seems that updating to 1.1.1 including 5cce05d has left me with duplicate cron jobs. I can just remove them manually (not the Ansible way), but thought it worth noting.

root@mysite:/etc# crontab -u plone_daemon -l
#Ansible: Plone packing
30 1 * * 7 cd /usr/local/plone-4.3/zeoserver && bin/zeopack
#Ansible: Plone backup
30 2 * * * cd /usr/local/plone-4.3/zeoserver && bin/backup
#Ansible: zeoserver Plone packing
30 1 * * 7 cd /usr/local/plone-4.3/zeoserver && bin/zeopack
#Ansible: zeoserver Plone backup
30 2 * * * cd /usr/local/plone-4.3/zeoserver && bin/backup

Error creating base directory, it creates /usr/local/plone- (without version)

At some point it creates the directory defined by {{ instance_config.plone_target_path }}.

This variable is calculated from:

plone_target_path: "{{ plone_config.plone_target_path|default('/usr/local/plone-' + work_major_version) }}"

And in case plone_config.plone_target_path is not defined, it looks at:

work_major_version: "{{ work_version|truncate(length=3, end='') }}"

And here truncating "4.3.7" results in empty string, you should change the truncate filter to:

truncate(length=3, killwords=true, end='')

Plone doesn't get restarted when plone_client_count: 1

This is an issue in Ansible 1.9.2 (and 1.9.2.1). A fix is coming in the next release of Ansible but that isn't out yet (unless you want to use rc versions)

Installing the older 1.9.1 of Ansible fixed this for me. I had to:

apt-get remove ansible 
pip install ansible=1.9.1

Can I/we log this somewhere? (just tell me where)

"Failed to set permissions on the temporary files Ansible needs to create..."

Occurs on e.g. "plone.plone_server : Bootstrap buildout" when running Ansible 2.1 without being root.
(this is the case in Plone 4.3, but it looks to me like it would just give the same error on a different task in Plone 5)

Full message is:

fatal: [peacock]: FAILED! => {"failed": true, "msg": "Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user. For information on working around this, see https://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-user"}

Not an error in this role, but could we advise a course of action?

Basically the options are:

  • use pipelining
  • Install filesystem acl support on the managed host
  • always run as root
  • don't use become in our tasks (not suitable for us)
  • (potentially insecure) override Ansible's check by setting allow_world_readable_tmpfiles in ansible.cfg

Unhelpful permissions on blobstoragebackup directory

The blobstoragebackups directory is not readable by anyone other than plone_daemon.
That is not helpful if I am for instance trying to pull backups on to another server (remember that plone_daemon is not given an external login, and it's recommended to turn off root's login)

memmon gets installed even if plone_client_max_memory == 0

As the subject stated, in my cases memmon gets installed and setup in supervisor even though I set plone_client_max_memory to 0.

I found out that incuding the int filter in the supervisor_task.j2 template solves the problem, but it probably doesn't work if you set the max memory to something like 2GB. So, better, change the line:

{% if instance_config.plone_client_max_memory != 0 %}

so that it looks like:

{% if instance_config.plone_client_max_memory != '0' %}

Allow to define the users and groups

I though that the role itself is helpful to provision development boxes, developers could use it to get a Plone env. ready on their own laptops, but having two users and a dedicated group is a bit overkilling, change that to allow a user to choose just one user and group should be easy, leaving the current behaviour (plone_buildout, plone_daemon and plone_group) as default.

Re-running role does not re-run "Run buildout"

When "Run buildout" fails, (see issue #13) re-running the role does not re-run "Run buildout". Instead this will be skipped. The reason is:

- name: Run buildout
when: plone_autorun_buildout and instance_status.changed

But instance_status.changed is only true when the buildout.cfg has changed. So we'd need some other or additional condition.

wv package is not reachable on the specified url

Hello,

I don't know why but the vw package is no longer at this url:
http://dl.fedoraproject.org/pub/epel/6/x86_64/wv-1.2.7-2.el6.x86_64.rpm

but there:
https://dl.fedoraproject.org/pub/epel/6/x86_64/Packages/w/wv-1.2.7-2.el6.x86_64.rpm

This is not the first time we hit this issue, the first time we discussed about it in the wrong project:
plone/ansible-playbook#60

I don't know how to fix this problem once and for all. Do you know if there is a version of this package for centos7 because I can't find one?

Best regards,
L00ptr

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.