Release status: stable
|Implementation||User rights, Special page, Page action|
|Description||Provides a web interface based on MediaWiki, offering a Nova or Swift manager that allows authorized users to create and manage projects, instances, IP allocations, DNS and LDAP entries, and boot images, to run virtual servers hosted on an OpenStack cloud.|
|Author(s)||Ryan lane (Ryan Lanetalk)|
|Latest version||2.0 (2012-09-04)|
|License||GNU General Public License 2.0 or later|
|Translate the OpenStackManager extension if it is available at translatewiki.net|
|Check usage and version matrix.|
|Issues||Open tasks · Report a bug|
Parts of this page (those related to integration with OpenStack) are outdated.
You may also read these pages on the main author's blog (on ryandlane.com) related to this MediaWiki-based implementation of these OpenStack managers:
Please help contribute by taking and fixing a bug. If you'd like to work in the same environment as the rest of us, talk to Ryan_Lane in #wikimedia-tech on freenode.
The support of Swift managers (for storage clouds), and possibly other types of clouds, may be developed later.
Install LDAP, and optionally DNS and PuppetEdit
For LDAP you can use your choice of other directory servers (likely excluding Active Directory). You'll need to add the puppet schema, the openssh-lpk schema, and the nova schema. I've been testing with OpenDJ. If you are more familiar with OpenLDAP, you may have an easier time with that. The schema files are included with the extension in both openldap and sun format.
For DNS you may be able to use any LDAP capable DNS server, but the extension has only been tested with PowerDNS with the LDAP backend in "strict" mode. It will not work with "tree" mode.
For puppet, you simply need to follow the puppetmaster installation instructions, and its LDAP configuration options.
Follow the instructions for a multinode install.
Install the LDAP Authentication pluginEdit
You must first install and configure the LDAP authentication extension. It must be configured to use proxy authentication, to allow user creation, to allow password updates, to allow mailing of passwords, and should pull preferences. Here's an example configuration:
require_once( "$IP/extensions/LdapAuthentication/LdapAuthentication.php" ); $wgAuth = new LdapAuthenticationPlugin(); $wgLDAPDomainNames = array( 'testdomain'); $wgLDAPServerNames = array( 'testdomain' => 'nova-controller'); $wgLDAPSearchAttributes = array( 'testdomain' => 'cn'); $wgLDAPBaseDNs = array( 'tesla' => 'dc=example,dc=org' ); $wgLDAPUserBaseDNs = array( 'tesla' => 'ou=people,dc=example,dc=org' ); $wgLDAPProxyAgent = array( 'tesla' => 'cn=proxyagent,ou=profile,dc=example,dc=org' ); $wgLDAPProxyAgentPassword = array( 'tesla' => 'P@SSWORD!!' ); $wgLDAPWriterDN = array( 'tesla' => 'cn=writerdn,ou=profile,dc=example,dc=org' ); $wgLDAPWriterPassword = array( 'tesla' => 'P@SSWORD!!' ); $wgLDAPWriteLocation = array( 'tesla' => 'ou=people,dc=example,dc=org' ); $wgLDAPAddLDAPUsers = array( 'tesla' => true ); $wgLDAPUpdateLDAP = array( 'tesla' => true ); // Change the password hash to clear if you are using a directory server that denies // non-clear text passwords on password change //$wgLDAPPasswordHash = array( 'tesla' => 'clear' ); // 'invaliddomain' is set to true so that mail password options // will be available on user creation $wgLDAPMailPassword = array( 'tesla' => true, 'invaliddomain' => true ); $wgLDAPPreferences = array( 'tesla' => array( "email"=>"mail","realname"=>"cn","nickname"=>"uid") ); $wgMinimalPasswordLength = 1; // Only enable UseLocal if you need to promote an LDAP user #$wgLDAPUseLocal = true; // Enabling debugging while doing development is encouraged $wgLDAPDebug = 5; $wgDebugLogGroups["ldap"] = "/tmp/ldap-debug.log" ;
Install PHP prerequisitesEdit
The following PHP extensions are needed by the extension:
- php5-uuid (OSSP)
Download the trunk snapshot and untar into the extensions directory. Add the following to LocalSettings.php:
require_once( "$IP/extensions/OpenStackManager/OpenStackManager.php" );
After installation, configure the extension using the options as shown below. You must currently use all options.
// Keystone identity URI // default: http://localhost:5000/v2.0 $wgOpenStackManagerNovaIdentityURI = 'http://nova-controller.example.org:35357/v2.0'; // LDAP Auth domain used for OSM // default: none $wgOpenStackManagerLDAPDomain = 'testdomain'; // UserDN used for reading and writing on the LDAP database // default: none $wgOpenStackManagerLDAPUser = 'cn=writerdn,ou=profile,dc=example,dc=org'; // Actual username of the LDAP user // default: none $wgOpenStackManagerLDAPUsername = 'novaadmin'; // Password used to bind // default: none $wgOpenStackManagerLDAPUserPassword = 'P@SSWORD!!'; // DN location of projects // default: none $wgOpenStackManagerLDAPProjectBaseDN = 'ou=projects,dc=example,dc=org'; // DN location for posix groups based on projects // default: none $wgOpenStackManagerLDAPProjectGroupBaseDN = "ou=groups,dc=example,dc=org"; // DN location of hosts/instances // default: none $wgOpenStackManagerLDAPInstanceBaseDN = 'ou=hosts,dc=example,dc=org'; // SSH key storage location, ldap or nova // default: ldap $wgOpenStackManagerNovaKeypairStorage = 'ldap'; $wgOpenStackManagerLDAPDefaultGid = '500'; $wgOpenStackManagerLDAPDefaultShell = '/bin/bash'; $wgOpenStackManagerLDAPUseUidAsNamingAttribute = true; $wgOpenStackManagerDNSOptions = array( 'enabled' => true, 'servers' => array( 'primary' => 'nova-controller.example.org', 'secondary' => 'nova-controller2.example.org' ), 'soa' => array( 'hostmaster' => 'nova-controller.example.org', 'refresh' => '1800', 'retry' => '3600', 'expiry' => '86400', 'minimum' => '7200' ), ); $wgOpenStackManagerPuppetOptions = array( 'enabled' => true, 'defaultclasses' => array( 'role::base' ), 'defaultvariables' => array( 'realm' => 'nova' ), ); $wgOpenStackManagerInstanceUserData = array( 'cloud-config' => array( #'puppet' => array( 'conf' => array( 'puppetd' => array( 'server' => 'nova-controller.example.org', 'certname' => '%i' ) ) ), ), 'scripts' => array( 'runpuppet.sh' => '/srv/org/example/controller/scripts/runpuppet.sh', ), 'upstarts' => array( 'ttyS0.conf' => '/srv/org/example/controller/upstarts/ttyS0.conf', 'ttyS1.conf' => '/srv/org/example/controller/upstarts/ttyS1.conf', ), ); $wgOpenStackManagerDefaultSecurityGroupRules = array( # Allow all traffic within the project array( 'group' => 'default' ), # Allow ping from everywhere array( 'fromport' => '-1', 'toport' => '-1', 'protocol' => 'icmp', 'range' => '0.0.0.0/0' ), # Allow ssh from all projects array( 'fromport' => '22', 'toport' => '22', 'protocol' => 'tcp', 'range' => '10.4.0.0/21' ), # Allow nrpe access from all projects (access is limited in config) array( 'fromport' => '5666', 'toport' => '5666', 'protocol' => 'tcp', 'range' => '10.4.0.0/21' ), ); #$wgOpenStackManagerInstanceDefaultImage = "ami-0000001d"; $wgGroupPermissions['cloudadmin']['listall'] = true; $wgGroupPermissions['bureaucrat']['manageproject'] = true; $wgGroupPermissions['cloudadmin']['managednsdomain'] = true; $wgGroupPermissions['cloudadmin']['manageglobalpuppet'] = true; $wgGroupPermissions['shell']['loginviashell'] = true; $smwgNamespacesWithSemanticLinks[NS_NOVA_RESOURCE] = true; $wgNamespacesWithSubpages[NS_NOVA_RESOURCE] = true; $wgNamespacesToBeSearchedDefault[NS_NOVA_RESOURCE] = true; # Enable doc links on the 'configure instance' page $wgOpenStackManagerPuppetDocBase = 'http://doc.example.org/puppet/classes/__site__/';
Initial setup can be awkward, due to the chicken and egg problem faced with wiki admin privileges and the LDAP plugin, and the need for an admin user for Nova. These are the steps I recommend:
- Fully configure Nova, and MediaWiki, the LDAP extension, and the OpenStackManager extension (minus the nova admin credentials)
- Create a user for yourself
- Enable local authentication using the following in LocalSettings.php: $wgLDAPUseLocal = true;
- Promote your user to Administrator and Bureaucrat
- Disable local authentication
- At this point, if you wish, you can
- Create a nova admin user
- Add the user to the "cloudadmins" global nova role
- Do not give this user any special wiki group rights; in fact, you can block this user if you'd like
- Get the user's accesskey and secretkey from ldap: ldapsearch -x '(|(cn=<username>)(uid=<username>)'
- Add these to LocalSettings.php for the nova admin credentials; ensure that the accesskey is "<accesskey>:<projectname>", where <projectname> is the default project name (this is annoyingly required by the EC2 API)
- Add your user to whichever roles you find appropriate, and add yourself to a project
This extension supports the ability to disable user creation by anyone other than Admins, if you choose to do so. If you would like to, set the following in LocalSettings.php:
# Only sysops can create new accounts. $wgGroupPermissions['*']['createaccount'] = false;
I've included some useful ldap scripts with the extension, under the scripts directory. Note that some of these are included because I'd like to improve them to the point where they are usable for this project, but will not currently work properly. The really useful ones are:
- Automatically creates home directories for ldap users, including adding their ssh keys to authorized_keys, and adding skel files
- Will automatically sign puppet ca requests for instances created, by ensuring they are valid LDAP entries
- A utility made for easier display of information in your ldap database. A python reimplementation of the Solaris tool
- Can modify attributes or rename ldap users. Be careful with this, some actions may cause problems with the extension!
- Can be used to email users when an instance has finished creating itself, given a from address, a to address, the user's language code, and a wiki address. The script will pull a localized message in the user's language from the wiki, and send it to the user from the from address.
I've included some useful upstarts, found under the upstarts directory. Some may be WMF specific, but are still likely useful.
- Enables ttyS0 so that a web console can be used on an instance. This is useful when using ajaxterm.
- Forces an initial puppet run, making it wait for a certificate, disables pluginsync, and ensures a consistent pid file is used. This may be a little WMF specific, but I found it makes an initial run of puppet more consistent.
- Added a reboot action for instances
- Made compatibility changes for cactus and diablo nova releases
- Made compatibility changes for MediaWiki 1.18
- Added support for configurable naming attributes
- Added support for adding objectclasses and attributes for users that are missing them
- It's now possible for MediaWiki to no longer have to create users, only update select user attributes and objectclasses
- Made a bunch of bugfixes regarding security groups
- Added support for wildcard DNS entries
- Bugfixes from John Du Hart, Sam Reed and Mark Hershberger
- Added realm and instancename variables to puppet default variables, so that they can be used in puppet runs
- Added support for wiki page creation for Projects
- Added support for configuring default images for instances
- Added support for creating server admin logs per project
- Added support for default security group rules on project creation
- Added dialog to project creation for adding members to projects and roles upon creation
- Added support for managing puppet classes and variables through the interface, rather than LocalSettings.php
- Made a usability change to instance creation: the default security group will always be selected by default
- Added support for including the ssh key fingerprint of an instance in the "your instance is ready" emails
- Made a usability change to only show actions to users if they can perform them
- Lots of other minor bug fixes
- Added support for managing sudo policies. Currently supports adding, modifying and deleting sudo policies with sudouser, sudohost, sudocommand, and sudooptions attributes. Requies wiki admin privileges to use the special page.
- Changed host addition behavior to add project to the host entry's puppet variables by default.
- Added support for adding/modifying/deleting instance information in Nova_Resource: wiki pages when creating/configuring/deleting instances. This can be disabled using the $wgOpenStackManagerCreateResourcePages configuration option.
- Added support for creating/deleting/attaching/detaching volumes.
- Changed the display of all tables to use the sortable CSS class.
- Changed name of the VM namespace, to instead be Nova Resources. All Nova resources will be placed in this namespace.
- Various MediaWiki 1.17 compatibility changes.
- Added a default shell config option, so that a shell can be added to user entries.
- Changed behavior of host addition to a location field on instance DNS entries.
- Code cleanup for localization.
- Fixed a number of spots the extension was throwing warnings.
- Changed Special:NovaDomain to check for cloudadmins membership if roles are intersecting, as otherwise netadmins for specific projects could also manage DNS domains.
- Fixed role check bug in Special:Domain, so that cloudadmins/netadmins can manage domains.
- Fixed various bugs in project/role membership management.
- Fixed a bug in public host management when an associated domain was removed that was also named for the dc attribute.
- Changed logic of which images will be shown for image creation: only show images that are public, are available, are of type machine, and have an image name
- Changed behavior of create action for Special:NovaInstance to show image names instead of image ids
- Added an upstart that can be used to enable consoles in instances.
- Added support for pulling instance type information from the Nova EC2 admin API.
- Added a class to represent instance types.
- Added support for the create action in Special:NovaInstance to list detailed information about instance types.
- Added a global config option for the Nova EC2 admin API's endpoint.
- Added support for project role members to add/remove other project role members.
- Added a utility upstart that can be used to do some puppet configuration changes before it starts on initial boot. Should be removed during first puppet run.
- Added support for getting console output from instances.
- Changed actions td on instance list page to be a list.
- Added script and localization messages for sending notification emails when instances are fully created
- Added default puppet variables for all instances created; adding the following variables, which represent the instance creator's email address, (wiki) user name, and interface language:
- Changed scripts and upstarts in clouddata to use named values in the arrays, where the named values are the name of the file that will be created on the instance.
- Changed behavior of instance termination to ensure any associated addresses are disassociated first.
- Added a number of validation checks for nova resource creation and modification.
- Changed creation of host entries to use instanceid instead of hostname for the dn, and changed creation to only use associated domain, not cname, since cnamerecords don't work when created that way.
- Added a script to automatically sign puppet certificate requests for hosts that exist in LDAP.
- Upgraded AWS SDK for PHP to 1.2.6 "Ifrit"
- Added floating ip output to instance list
- Removed cast calls from code pulling info from classes, and added them to the output of the classes
- Added support for cloud-init via $wgOpenStackManagerInstanceUserData
- Can currently add cloudconfig, scripts, and upstarts
- cloudconfig is currently an array that is converted to YAML, whereas scripts and upstarts load from given files
- Added schema directory with required schemas in openldap and sun format
- Added some useful python ldap scripts (note that scripts like add-ldap-user will not currently create users that are valid for OpenStackManager)
- A bunch of code clean up and code documentation (thanks Reedy!)
- Added a check to ensure the uid attribute isn't already used when adding user accounts. Anyone sane is already doing this on their directory server, but it's better safe than sorry.
- Added a bug fix for project searches
- Added support for project members to add/remove other project members
- Fixed a few possible XSS vectors
- Added some missing localization in Special:NovaKey
- Fixed a bug with key deletion
- Finished adding support for project roles
- Added support for global roles
- Made some interface changes to Special:Project
- Added initial support for managing global and project roles
- Added availability zone and launch time display to instance list
- Removed the rename option for now, as openstack doesn't currently support it
- Added security group display to instance list
- Fixed forms re-showing upon errors, when they should not re-show
- Added Security Group support
- Added support for Security Groups for instances, on instance creation
- Finished adding localization support
- Added support for allocating, release, associating, and deassociating floating IP addresses.
- Moved specials to /special
- Added SpecialNova abstract class and subclasses all special pages beneath it
- Added security
- Special:NovaInstance actions require sysadmin role
- Special:NovaDomain, Special:NovaAddress actions require netadmin role
- Special:NovaProject is limited to wiki administrators
- Roles are pulled from LDAP
- Added an option to determine whether role checks for projects should require that users be in both the global and project role to be considered a member of the role. This is the current Nova behavior, until lp697936 is fixed.
- Added support for managing public DNS entries via Special:NovaAddress
- Public DNS entries can only be added to allocated floating IP addresses
- A DNS entry can contain multiple A records, and multiple associated domain records (for aliases)
- Restricted to netadmins
- Added a small amount of locailization to Special:NovaInstance
- Changed DNS configuration options for instances
- Can now choose a domain only based upon location
- Location and instance DNS is linked, as the DNS entry created will be a private DNS entry
- Added a location field to the form for domains, so that domains can be location specific
- Domains with no location attribute set will be public DNS domains; this likely needs to be made clear on the form
- Fixed instance list for Special:NovaInstance; was previously only showing one instance, even if multiple instances existed
- Added a OpenStackNovaHostJob, to add IP addresses to host entries in a deffered manner
- This is due to a change in Nova; previously IP addresses were assigned on instance creation, now they are created on instance scheduling, so IP address information is not available immediately
- Removed in-process caching for Nova API responses; was causing more trouble than it was worth. Should be re-added as memcache caches later
- Modified the behavior of getInstance to get all instances from Nova, and return a specific instance, since this behavior changed in the API (which is likely a bug)
- Added various extra error checking
- Removed t1.micro as an instance type, as it isn't valid in Nova
- Removed key-name as a field for instance creation
- This should be added back in as a configurable option. We don't need key injection, but others may
- Added support for PowerDNS with an LDAP backend
- Added a special page for creating and deleting DNS domains
- Added a class for hosts and domains
- Added support for adding/removing ssh keys
- Added support for adding/removing projects
- Added support for configuration of extra namespaces using project from LDAP
- Added instance name support via "DisplayName" property in OpenStack
- Added a VM and VM_talk namespace; 498 and 499 respectively (500+ is for nova project namespaces)
- Added actions to NovaInstance special page for instance creation, modification, and lists
- Added security to Instance creation
- Will ensure you are in the project you wish to create instances in
- Will ensure your user account has Nova credentials
- Added a NovaUser class to represent Nova user accounts
- Functions added for getting credentials, getting project and role memberships, checking for project and role memberships, and checking for existence
- Initial release
- Very basic support for EC2 API
- Can fetch images, instances, keys, availability zones, and instance types
- Can create an instance
- Has absolutely no error checking
- Has no per-user security - uses admin for everything
|This extension is being used on one or more Wikimedia projects. This probably means that the extension is stable and works well enough to be used by such high-traffic websites. Look for this extension's name in Wikimedia's CommonSettings.php and InitialiseSettings.php configuration files to see where it's installed. A full list of the extensions installed on a particular wiki can be seen on the wiki's Special:Version page.|