https://wiki.archlinux.org/api.php?action=feedcontributions&user=Buergi&feedformat=atomArchWiki - User contributions [en]2024-03-29T08:22:38ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Redmine&diff=628465Redmine2020-08-02T17:26:07Z<p>Buergi: Updated the installation procedure</p>
<hr />
<div>[[Category:Issue tracking systems]]<br />
[[ja:Redmine]]<br />
{{Related articles start}}<br />
{{Related|Ruby on Rails}}<br />
{{Related|RVM}}<br />
{{Related|MariaDB}}<br />
{{Related|Apache HTTP Server}}<br />
{{Related|Nginx}}<br />
{{Related articles end}}<br />
[https://www.redmine.org/ Redmine] is a [[Wikipedia:free and open source software|free and open source]], web-based [[Wikipedia:project management|project management]] and [[Wikipedia:Issue tracking system|issue tracking]] tool. It handles multiple projects and subprojects. It [http://www.redmine.org/projects/redmine/wiki/Features features] per project wikis and forums, time tracking, and flexible role based access control. It includes a [[Wikipedia:calendar|calendar]] and [[Wikipedia:Gantt chart|Gantt chart]]s to aid visual representation of projects and their [[Wikipedia:time limit|deadlines]]. Redmine integrates with various [[Wikipedia:version control|version control]] systems and includes a repository browser and diff viewer.<br />
<br />
Redmine is written using the [[Ruby on Rails]] framework. It is cross-platform and cross-[[Wikipedia:database|database]] and supports 34 languages.<br />
<br />
==Installation==<br />
This document will guide you through the suggested installation process of Redmine.<br />
<br />
If for some reason you want to setup redmine manually, it is recommended to follow the official [https://redmine.org/projects/redmine/wiki/RedmineInstall Installation Guide].<br />
<br />
Although it is possible to run Redmine on its own for testing purposes, for production use it requires an SQL database as well as a web server.<br />
As database it is recommended to use [[MariaDB]] or [[PostgreSQL]].<br />
The supported web servers are<br />
<br />
* [[Apache]] or [[nginx]] via [https://www.phusionpassenger.com/ Phusion Passenger]<br />
* [[Ruby on Rails#Puma_(with_Nginx_as_reverse_proxy_server)]]<br />
* [[Ruby on Rails#Unicorn]]<br />
<br />
==Installation==<br />
<br />
===Build and Installation===<br />
<br />
[[Install]] the {{Pkg|redmine}} package.<br />
<br />
As redmine still requires Ruby 2.6, while the {{Pkg|ruby}} package in the repositories is 2.7, it installs the legacy package {{Pkg|ruby-2.6}} into `/opt/ruby-2.6`.<br />
To use the correct executables in all commands below we set up some temporary aliases. Of course, you can also specify the full paths in all commands below.<br />
<br />
# alias ruby=/opt/ruby2.6/bin/ruby-2.6<br />
# alias bundle=/opt/ruby2.6/bin/bundle-2.6<br />
# alias gem=/opt/ruby2.6/bin/gem-2.6<br />
<br />
In the following we assume user under which the redmine will be running is {{ic|http}}. The ruby commands are thus explicitly executed under this specifiy user's control.<br />
<br />
===Database Configuration===<br />
<br />
Now, we will need to create the database that the Redmine will use to store your data. For now on, the database and its user will be named {{ic|redmine}}. But this names can be changed to anything else.<br />
<br />
{{Note|The configuration for [[MariaDB]] and [[MySQL]] will be the same since both are binary compatible.}}<br />
<br />
====Database Creation====<br />
<br />
To create the database, the user and set privileges:<br />
{{hc|# mysql -u root -p|<br />
CREATE DATABASE redmine CHARACTER SET UTF8;<br />
CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'my_password';<br />
GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost';}}<br />
<br />
For PostgreSQL:<br />
{{bc|1=CREATE ROLE redmine LOGIN ENCRYPTED PASSWORD 'my_password' NOINHERIT VALID UNTIL 'infinity';<br />
CREATE DATABASE redmine WITH ENCODING='UTF8' OWNER=redmine;}}<br />
<br />
{{Note|If you want to use additional environments, you must create separate databases for each one (for example: ''development'' and ''test'').}}<br />
<br />
====Database Access Configuration====<br />
<br />
Now you need to configure Redmine to access the database we just created. To do that you have to copy {{ic|/usr/share/webapps/redmine/config/database.yml.example}} to {{ic|database.yml}}:<br />
<br />
# cd /usr/share/webapps/redmine/config<br />
# cp database.yml.example database.yml<br />
<br />
And then edit this file in order to configure your database settings for "production" environment (you can configure for the "development" and "test" environments too, just change the appropriate sections).<br />
<br />
Example for MariaDB and MySQL database:<br />
{{hc|nano database.yml|<br />
production:<br />
adapter: mysql2<br />
database: redmine<br />
host: localhost<br />
port: 3307 '''#If your server is not running on the standard port (3306), set it here, otherwise this line is unnecessary.'''<br />
username: redmine<br />
password: my_password}}<br />
<br />
Example for PostgreSQL database:<br />
{{hc|nano database.yml|<br />
production:<br />
adapter: postgresql<br />
database: redmine<br />
host: localhost<br />
username: redmine<br />
password: my_password<br />
encoding: utf8<br />
schema_search_path: <database_schema> (default - public)}}<br />
<br />
Example for a SQL Server database:<br />
{{hc|nano database.yml|<br />
production:<br />
adapter: sqlserver<br />
database: redmine<br />
host: localhost '''#Set not default host (localhost) here, otherwise this line is unnecessary.'''<br />
port: 1433 '''#Set not standard port (1433) here, otherwise this line is unnecessary.'''<br />
username: redmine<br />
password: my_password<br />
}}<br />
<br />
=== Ruby gems ===<br />
Redmine requires some [[RubyGems]], however {{Pkg|redmine}} comes prepackaged with all requirements.<br />
<br />
===Session Store Secret Generation===<br />
Now you must generate a random key that will be used by Rails to encode cookies that stores session data thus preventing their tampering:<br />
<br />
# bundle exec rake generate_secret_token<br />
<br />
{{Warning|Generating a new secret token invalidates all existing sessions after restart.}}<br />
<br />
===Database Structure Creation===<br />
With the database created and the access configured for Redmine, now it is time to create the database structure. This is done by running the following command under the application root directory:<br />
<br />
# cd /usr/share/webapps/redmine<br />
# chown http:http db # migration requires write access to db/schema.rb<br />
# sudo -u http -g http RAILS_ENV=production bundle exec rake db:migrate<br />
<br />
These command will create tables by running all migrations one by one then create the set of the permissions and the application administrator account, named admin.<br />
<br />
===Database Population with Default Data===<br />
Now you may want to insert the default configuration data in database, like basic types of task, task states, groups, etc. To do so execute the following:<br />
<br />
# sudo -u http -g http RAILS_ENV=production bundle exec rake redmine:load_default_data<br />
<br />
Redmine will prompt for the data set language that should be loaded; you can also define the REDMINE_LANG environment variable before running the command to a value which will be automatically and silently picked up by the task:<br />
<br />
# sudo -u http -g http RAILS_ENV=production REDMINE_LANG=de bundle exec rake redmine:load_default_data<br />
<br />
{{Note|This step is not mandatory, but it certainly will save you a lot of work to start using Redmine. And for a first time it can be very instructive.}}<br />
<br />
===File System Permissions===<br />
The user account running the application '''must''' have write permission on the following subdirectories:<br />
<br />
* '''files''': storage of attachments.<br />
* '''log''': application log file production.log.<br />
* '''tmp''' and '''tmp/pdf''': used to generate PDF documents among other things (create these ones if not present).<br />
<br />
The {{Pkg|redmine}} comes preconfigured with permissions for user {{ic|http}}. In case you like to use a different user you need to change the ownership, e.g.<br />
<br />
# chown -R redmine:redmine files/ log/ tmp/<br />
<br />
===Test the installation===<br />
To test your new installation using WEBrick web server run the following in the Redmine folder:<br />
<br />
# sudo -u http -g http ruby bin/rails server webrick -e production<br />
<br />
Once WEBrick has started, point your browser to '''http://localhost:3000/'''. You should now see the application welcome page. Use default administrator account to log in: '''''admin'''''/'''''admin'''''. You can go to Administration menu and choose Settings to modify most of the application settings.<br />
<br />
{{Warning|Webrick is not suitable for production use, please only use webrick for testing that the installation up to this point is functional. Use one of the many other guides in this wiki to setup redmine to use either Passenger (aka mod_rails), FCGI or a Rack server (Unicorn, Thin, Puma or hellip) to serve up your redmine.}}<br />
<br />
===Configure the production server===<br />
<br />
==== Puma / Unicorn ====<br />
Puma and Unicorn are web servers based on Mongrel. For its increased speed and smaller memory footprint [https://puma.io/ Puma] is recommended. Both are very simple to setup, but for production use should be used in combination with a reverse proxy (Apache, Nginx, lighttpd, etc.).<br />
<br />
# gem install puma<br />
# sudo -u http -g http /opt/ruby2.6/bin/puma<br />
<br />
For production, puma can be started as a systemd service:<br />
<br />
{{hc|/etc/systemd/system/redmine.service|<br />
[Unit]<br />
Description=Redmine<br />
After=network.target<br />
<br />
[Service]<br />
User=http<br />
Group=http<br />
RestartSec=1<br />
Restart=always<br />
StartLimitInterval=10<br />
StartLimitBurst=10<br />
WorkingDirectory=/usr/share/webapps/redmine/<br />
ExecStart=/opt/ruby2.6/bin/puma -e production -p 9292<br />
<br />
[Install]<br />
WantedBy=multi-user.target}}<br />
<br />
# systemctl daemon-reload<br />
# systemctl enable redmine<br />
# systemctl start redmine<br />
<br />
==== Phusion Passenger ====<br />
For Apache and Nginx, it is recommended to use [https://www.phusionpassenger.com/ Phusion Passenger]. Passenger is a module available for [[Nginx]] and [[Apache HTTP Server]].<br />
<br />
Start by installing the 'passenger' gem:<br />
# gem install passenger<br />
<br />
Now you have to look at your passenger gem installation directory to continue. If you do not known where it is, type:<br />
# gem env<br />
<br />
And look at the {{ic|GEM PATHS}} to find where the gems are installed. If you followed this guide and installed [[RVM]], you can have more than one path, look at the one you are using.<br />
<br />
For this guide so far, the gem path is {{ic|/usr/local/rvm/gems/ruby-2.0.0-p247@global}}.<br />
# cd /usr/local/rvm/gems/ruby-2.0.0-p247@global/gems/passenger-4.0.23<br />
<br />
If you are aiming to use [[Apache HTTP Server]], run:<br />
# passenger-install-apache2-module<br />
<br />
In case a rails application is deployed with a sub-URI, like http://example.com/yourapplication, some additional configuration is required, see [https://www.phusionpassenger.com/library/deploy/apache/deploy/ruby/#deploying-an-app-to-a-sub-uri-or-subdirectory the Passenger documentation]<br />
<br />
For [[Nginx]]:<br />
# passenger-install-nginx-module<br />
<br />
And finally, the installer will provide you with further information regarding the installation (such as installing additional libraries). So, to setup your server, simply follow the output from the passenger installer.<br />
<br />
==Updating==<br />
<br />
{{Out of date|Redmine package is now in community and has its own dependencies. The update process is a little different.}}<br />
<br />
Backup the files used in Redmine:<br />
# tar czvf ~/redmine_files.tar.gz -C /usr/share/webapps/redmine/ files<br />
<br />
Backup the plugins installed in Redmine:<br />
# tar czvf ~/redmine_plugins.tar.gz -C /usr/share/webapps/redmine/ plugins<br />
<br />
Backup the database:<br />
# mysqldump -u root -p <redmine_database> | gzip > ~/redmine_db.sql.gz<br />
<br />
Update the {{Pkg|redmine}} package as normal.<br />
<br />
Update the gems requirements:<br />
# bundle update<br />
<br />
For a clean gems environment, you may want to remove all the gems and reinstall them. To go through this, do:<br />
# for x in `gem list --no-versions`; do gem uninstall $x -a -x -I; done<br />
<br />
{{Warning|The command above will delete ALL the gems in your system or user, depending of what type of Ruby installation you did in the prerequisites step. You must take care or you can stop working another applications that rely on Ruby gems.}}<br />
<br />
If you did the last step and removed all the gems, now you will need to reinstall them all:<br />
# gem install bundler<br />
# bundle install --without development test<br />
<br />
{{Note|If you removed ALL the gems as above, and used a server that uses a gem, remember to reinstall the server gem: passenger (for Apache and Nginx), Mongrel or Unicorn. To do this, just follow the steps in the installation tutorial above.}}<br />
<br />
Copy the saved files:<br />
# tar xzvf ~/redmine_files.tar.gz -C /usr/share/webapps/redmine/<br />
<br />
Copy the installed plugins:<br />
# tar xzvf ~/redmine_plugins.tar.gz -C /usr/share/webapps/redmine/<br />
<br />
Regenerate the secret token:<br />
# cd /usr/share/webapps/redmine<br />
# bundle exec rake generate_secret_token<br />
<br />
Check for any themes that you may have installed in the {{ic|public/themes}} directory. You can copy them over but checking for updated version is ideal.<br />
<br />
{{Warning|Do NOT overwrite config/settings.yml with the old one.}}<br />
<br />
Update the database. This step is the one that could change the contents of your database. Go to your new redmine directory, then migrate your database:<br />
# RAILS_ENV=production REDMINE_LANG=pt-BR bundle exec rake db:migrate<br />
<br />
If you have installed any plugins, you should also run their database migrations:<br />
# RAILS_ENV=production REDMINE_LANG=pt-BR bundle exec rake redmine:plugins:migrate<br />
<br />
Now, it is time to clean the cache and the existing sessions:<br />
# RAILS_ENV=production bundle exec rake tmp:cache:clear tmp:sessions:clear<br />
<br />
Restart the application server (e.g. puma, thin, passenger, etc). And finally go to "Admin -> Roles & permissions" to check/set permissions for the new features, if any.<br />
<br />
==Troubleshooting==<br />
===Runtime error complaining that RMagick was configured with older version===<br />
<br />
If you get the following runtime error after upgrading ImageMagick {{ic|This installation of RMagick was configured with ImageMagick 6.8.7 but ImageMagick 6.8.8-1 is in use.}} then you only need to reinstall (or rebuild as shown above if is the case).<br />
<br />
{{Note|This is due to that when you install the RMagick gem it compiles some native extensions and they may need to be rebuilt after some ImageMagick upgrades.}}<br />
<br />
===Error when installing gems: Cannot load such file -- mysql2/mysql2===<br />
<br />
If you see an error like {{ic| cannot load such file -- mysql2/mysql2}}, you are having a problem with the installation of the database gem. Probably a misconfiguration in the [[#Database Access Configuration|Database Access Configuration]] step.<br />
In this case you should verify the {{ic|database.yml}} file.<br />
<br />
If no success, you can manually install the database gem by:<br />
<br />
# gem install mysql2<br />
<br />
In last case, as suggested by [[User:Bobdog|Bobdog]], you can try to comment the line of the database gem and add a new one as bellow:<br />
<br />
{{hc|<path-to-mysql2-gem-directory>/lib/mysql2/mysql2.rb|<br />
<br />
# require 'mysql2/mysql2'<br />
require '<path-to-mysql2-gem-directory>/lib/mysql2/mysql2.so'}}<br />
<br />
=== Checkout SVN Source ===<br />
Get the Redmine source ([http://www.redmine.org/projects/redmine/wiki/Download Download instructions]). Here is method of installing Redmine directly from subversion in /srv/http/redmine/<br />
# useradd -d /srv/http/redmine -s /bin/false redmine<br />
# mkdir -p /srv/http/redmine<br />
# svn checkout http://svn.redmine.org/redmine/branches/2.1-stable /srv/http/redmine<br />
# chown -R redmine: /srv/http/redmine<br />
<br />
=== Automating The Update Process ===<br />
Example of an after-update script:<br />
<br />
#!/usr/bin/bash<br />
export RAILS_ENV=production<br />
grep -E "^gem 'thin'" Gemfile || echo "gem 'thin'" >> Gemfile<br />
bundle update && bundle exec rake generate_secret_token db:migrate redmine:plugins:migrate tmp:cache:clear tmp:sessions:clear<br />
<br />
{{Note| Note that this script uses Thin as application server, so you must change it to your needs.}}<br />
<br />
=== Creating a Systemd Unit===<br />
If you want to automatic run you application server when system starts, you need to create a systemd unit file.<br />
<br />
{{Note| This is not needed if you use {{Pkg|apache}} or {{Pkg|nginx}} with Passenger gem. Those servers already have their own unit file, so you have only to enable it.}}<br />
<br />
{{hc|/etc/systemd/system/redmine.service|<nowiki><br />
[Unit]<br />
Description=Redmine server<br />
After=syslog.target<br />
After=network.target<br />
<br />
[Service]<br />
Type=simple<br />
User=redmine2<br />
Group=redmine2<br />
Environment=GEM_HOME=/home/redmine2/.gem/<br />
ExecStart=/usr/bin/ruby /usr/share/webapps/redmine/bin/rails server webrick -e production<br />
<br />
# Give a reasonable amount of time for the server to start up/shut down<br />
TimeoutSec=300<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://www.redmine.org/ Redmine Official Site]<br />
* [http://www.redmine.org/projects/redmine/wiki/Features Redmine Features]<br />
* [http://www.redmine.org/projects/redmine/wiki/RedmineInstall Official install guide from Redmine Wiki]</div>Buergihttps://wiki.archlinux.org/index.php?title=GitLab&diff=267426GitLab2013-07-21T14:26:35Z<p>Buergi: /* systemd support */ Fixed systemd service files, gitlab.target makes no sence -> change to multi-user.target</p>
<hr />
<div>[[Category:Version Control System]]<br />
{{Article summary start}}<br />
{{Article summary text|This page gives guidelines for the installation and configuration of Gitlab on Archlinux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Gitolite}}<br />
{{Article summary wiki|Ruby on Rails}}<br />
{{Article summary end}}<br />
[http://gitlab.org/ Gitlab] is a free git repository management application based on [[Ruby on Rails]]. It is distributed under the MIT License and its source code can be found on [https://github.com/gitlabhq/gitlabhq Github]. It is a very active project with a monthly release cycle and ideal for businesses that want to keep their code private. Consider it as a self hosted Github but open source. You can try a demo [http://demo.gitlabhq.com/ here].<br />
{{Note|Throughout the article, sudo is heavily used, assuming that the user that is running the commands is root or someone with equal privileges. There is no need to edit the sudoers file whatsoever. It is only used to change to the appropriate user. For more info read {{ic|man sudo}}.}}<br />
<br />
==Required packages==<br />
<br />
Install the packages below as they are needed to proceed further.<br />
<br />
# pacman -Syu --noconfirm --needed sudo base-devel zlib libyaml openssl gdbm readline ncurses libffi curl git openssh redis libxml2 libxslt icu python2<br />
<br />
{{Note| In order to receive mail notifications, make sure to install a mail server. By default, Archlinux does not ship with one. The recommended mail server is [[postfix]], but you can use others such as [[SSMTP]], [[msmtp]], [[sendmail]], [https://wiki.archlinux.org/index.php/Category:Mail_Server etc].}}<br />
<br />
== PKGBUILDs for Gitlab and Gitlab-shell ==<br />
There are some (not fully working) PKGBUILDs available to create installable packages:<br />
<br />
[https://github.com/mtorromeo/archlinux-packages/tree/master/gitlab Gitlab PKGBUILD on GitHub.com]<br />
<br />
[https://github.com/mtorromeo/archlinux-packages/tree/master/gitlab-shell Gitlab-shell PKGBUILD on GitHub.com]<br />
<br />
(Please extend/rename this section with further instructions)<br />
<br />
==Ruby==<br />
<br />
GitLab supports [[ruby]] >= {{ic|1.9.3}} and {{ic|2.0.0}}, but some dependencies gems work better with ruby {{ic|1.9.3}}. Install it from the official repositories and if you bump into any trouble use [[rvm]] with latest ruby {{ic|1.9.3}}.<br />
<br />
{{Note|If you want to use rvm be sure to check out [[Gitlab#Running GitLab with rvm]] before starting with the installation}}<br />
<br />
==User accounts==<br />
<br />
Add {{ic|git}} user:<br />
<br />
# useradd -U -m -d /home/git git<br />
<br />
{{Note| {{ic|git}} user must have its initial group set to {{ic|git}} (not {{ic|users}}). If the initial group is not {{ic|git}}, then all files created by the {{ic|git}} user will be owned by {{ic|git:users}} which will prevent GitLab from showing you a newly created repository (it will get stucked at the page where it tells you how to push to the new repository).}}<br />
<br />
==gitlab-shell==<br />
<br />
GitLab Shell is an ssh access and repository management software developed specially for GitLab.<br />
<br />
Login as git:<br />
<br />
# su - git<br />
<br />
Clone gitlab shell:<br />
<br />
$ git clone https://github.com/gitlabhq/gitlab-shell.git<br />
$ cd gitlab-shell<br />
<br />
Switch to the right version:<br />
<br />
$ git checkout v1.4.0<br />
<br />
Edit {{ic|config.yml}} and replace gitlab_url with something like {{ic|http://domain.com/}}:<br />
<br />
$ cp config.yml.example config.yml<br />
<br />
Setup the environment:<br />
<br />
$ ./bin/install<br />
<br />
You should see this result:<br />
<br />
{{hc|Example output|<nowiki><br />
mkdir -p /home/git/repositories: true<br />
mkdir -p /home/git/.ssh: true<br />
chmod 700 /home/git/.ssh: true<br />
touch /home/git/.ssh/authorized_keys: true<br />
chmod 600 /home/git/.ssh/authorized_keys: true<br />
chmod -R ug+rwX,o-rwx /home/git/repositories: true<br />
find /home/git/repositories -type d -print0 | xargs -0 chmod g+s: true<br />
</nowiki>}}<br />
<br />
==Database selection==<br />
<br />
Currently GitLab supports [[MySQL]] and [[PostgreSQL]]. [[MariaDB]] has not been officially tested but it works just fine.<br />
<br />
===MariaDB===<br />
<br />
[[pacman|Install]] {{Pkg|mariadb}} and {{Pkg|libmariadbclient}} from the [[official repositories]] and start the [[daemon]]. Create the database and do not forget to replace {{ic|your_password_here}} with a real one.<br />
<br />
# su - git<br />
$ mysql -u root -p<br />
<br />
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;<br />
mysql> CREATE USER 'gitlab'@'localhost' IDENTIFIED BY 'your_password_here';<br />
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'gitlab'@'localhost';<br />
mysql> \q<br />
<br />
Try connecting to the new database with the new user:<br />
<br />
$ mysql -u gitlab -p -D gitlabhq_production<br />
<br />
===PostgreSQL===<br />
<br />
[[pacman|Install]] {{Pkg|postgresql}} and {{Pkg|libpqxx}} from the [[official repositories]]. Follow [[PostgreSQL#Installing_PostgreSQL]] to set it up and start the [[daemon]].<br />
<br />
Login to PostgreSQL and remember to change {{ic|your_password_here}} to a real one:<br />
<br />
# sudo -u postgres psql -d template1<br />
<br />
template1=# CREATE USER git WITH PASSWORD 'your_password_here';<br />
template1=# CREATE DATABASE gitlabhq_production OWNER git;<br />
template1=# \q<br />
<br />
Try connecting to the new database with the new user:<br />
<br />
# sudo -u git -H psql -d gitlabhq_production<br />
<br />
===MySQL===<br />
<br />
If you are still in favor of {{AUR|mysql}}, follow the same commands as MariaDB.<br />
<br />
==Gitlab==<br />
<br />
===Installation===<br />
<br />
Clone GitLab's repository:<br />
# su - git<br />
$ git clone https://github.com/gitlabhq/gitlabhq.git gitlab<br />
$ cd gitlab<br />
$ git checkout 5-2-stable<br />
<br />
{{Note| You can change {{ic|5-2-stable}} to {{ic|master}} if you want the bleeding edge version, but do so with caution! Check github to see what is the latest stable version and replace above accordingly.}}<br />
<br />
===Basic configuration===<br />
<br />
First we need to rename the example file.<br />
<br />
$ cp config/gitlab.yml.example config/gitlab.yml<br />
<br />
The options are pretty straightforward. Open {{ic|config/gitlab.yml}} with your favorite editor and edit where needed.<br />
Make sure to change {{ic|localhost}} to the fully-qualified domain name of your host serving GitLab where necessary.<br />
<br />
Make sure GitLab can write to the {{ic|log/}} and {{ic|tmp/}} directories:<br />
<br />
$ chown -R git log/<br />
$ chown -R git tmp/<br />
$ chmod -R u+rwX log/<br />
$ chmod -R u+rwX tmp/<br />
<br />
Create directory for satellites:<br />
<br />
$ mkdir /home/git/gitlab-satellites<br />
<br />
Create directories for sockets/pids and make sure GitLab can write to them:<br />
<br />
$ mkdir tmp/{pids,sockets}<br />
$ chmod -R u+rwX tmp/{pids,sockets}<br />
<br />
Create the {{ic|public/uploads}} directory otherwise backup will fail:<br />
<br />
$ mkdir public/uploads<br />
$ chmod -R u+rwX public/uploads<br />
<br />
Copy the example Puma config and edit to your liking:<br />
<br />
$ cp config/puma.rb.example config/puma.rb<br />
<br />
Configure Git global settings for git user, useful when editing via web. Edit {{ic|user.email}} according to what is set in {{ic|gitlab.yml}}:<br />
<br />
$ git config --global user.name "GitLab"<br />
$ git config --global user.email "gitlab@localhost"<br />
<br />
Configure GitLab database settings:<br />
<br />
* MariaDB:<br />
$ cp config/database.yml.mysql config/database.yml<br />
<br />
* PostgreSQL:<br />
$ cp config/database.yml.postgresql config/database.yml<br />
<br />
Make sure to update {{ic|username}}/{{ic|password}} in {{ic|config/database.yml}}.<br />
<br />
<br />
===Install gems===<br />
<br />
{{Tip| If you do not want to download any gem documentation, add {{ic|gem: --no-rdoc --no-ri}} to {{ic|/home/git/.gemrc}}. Be sure to add it as the {{ic|git}} user in order to acquire the appropriate permissions.}}<br />
{{Note|See bug #[https://bugs.archlinux.org/task/33327 33327] for about system-wide gems. As a temporary solution the following packages will be installed as {{ic|git}} user, make sure {{ic|/home/git/.gemrc}} contains {{ic|gem: ... --user-install}}. And then add the {{ic|bin}} path to the {{ic|PATH}} variable like so {{ic|1=export PATH="$PATH:~/.gem/ruby/2.0.0/bin"}}.}}<br />
<br />
Install {{ic|bundler}} and {{ic|charlock_holmes}} under {{ic|/git/home/.gem/}} (normally system wide via sudo):<br />
<br />
# su - git<br />
$ gem install charlock_holmes --version '0.6.9.4'<br />
$ gem install bundler<br />
<br />
Install gems from Gemfile:<br />
<br />
$ cd gitlab/<br />
<br />
{{Note|When executing the below and you recieve `Could not verify the SSL certificate for https://rubygems.org/` see bug #[https://github.com/gitlabhq/gitlabhq/issues/4095 GitHub-4095] most likely because you're behind a proxy that tries to inject a local certificate for SSL domains in order to verify its content}}<br />
<br />
If you used MariaDB:<br />
<br />
$ bundle install --deployment --without development test postgres<br />
<br />
If you used PostgreSQL:<br />
<br />
$ bundle install --deployment --without development test mysql<br />
<br />
{{Note|1= Using {{ic|--without group_name}} in bundle command line will ignore required packages for the mentioned groups.}}<br />
<br />
===Initialize Database===<br />
<br />
{{Note| Make sure the redis [[daemon]] is enabled and started, otherwise the following command will fail. To check the status and see if it's running execute {{ic|systemctl status redis}}, if it's dead start it as per usual via {{ic|systemctl start redis}}}}<br />
<br />
Initialize database and activate advanced features: <br />
$ bundle exec rake gitlab:setup RAILS_ENV=production<br />
<br />
{{Note|If you recieve a error {{ic|No such file or directory - /home/git/repositories/root}} then most likely you've changed the default configuration for {{ic|GitLab}} and you'll need to modify all static paths in {{ic|config/gitlab.yml}} and run the above command again to initialize the database!}}<br />
<br />
===Check status===<br />
<br />
With the following commands we check if the steps we followed so far are configured properly. <br />
<br />
$ bundle exec rake gitlab:env:info RAILS_ENV=production<br />
$ bundle exec rake gitlab:check RAILS_ENV=production<br />
<br />
{{hc|Example output of gitlab:env:info|<br />
System information<br />
System: Arch Linux<br />
Current User: git<br />
Using RVM: yes<br />
RVM Version: 1.20.3<br />
Ruby Version: 2.0.0p0<br />
Gem Version: 2.0.0<br />
Bundler Version:1.3.5<br />
Rake Version: 10.0.4<br />
<br />
GitLab information<br />
Version: 5.2.0.pre<br />
Revision: 4353bab<br />
Directory: /home/git/gitlab<br />
DB Adapter: mysql2<br />
URL: http://gitlab.arch<br />
HTTP Clone URL: http://gitlab.arch/some-project.git<br />
SSH Clone URL: git@gitlab.arch:some-project.git<br />
Using LDAP: no<br />
Using Omniauth: no<br />
<br />
GitLab Shell<br />
Version: 1.4.0<br />
Repositories: /home/git/repositories/<br />
Hooks: /home/git/gitlab-shell/hooks/<br />
Git: /usr/bin/git<br />
}}<br />
<br />
{{Note| {{ic|gitlab:check}} will complain about missing initscripts. Don't worry, we will use ArchLinux' [[systemd]] to manage server start (which GitLab does not recognize).}}<br />
<br />
==Web server configuration==<br />
<br />
<br />
===Unicorn only===<br />
<br />
{{Note|As of GitLab 5.1 Unicorn is no longer the default server as it got replaced by Puma. You can therefore ignore this section.}}<br />
<br />
Edit {{ic|/home/gitlab/gitlab/config/unicorn.rb}} uncomment:<br />
<br />
listen 8080 # listen to port 8080 on all TCP interfaces<br />
<br />
Create {{ic|/etc/rc.d/unicorn-gitlab}}.<br />
<pre><br />
#!/bin/bash<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
<br />
PID=`pidof -o %PPID /usr/bin/ruby`<br />
case "$1" in<br />
start)<br />
stat_busy "Starting unicorn"<br />
[ -z "$PID" ] && sudo -u gitlab bash -c "source /home/gitlab/.bash_profile && cd /home/gitlab/gitlab/ && bundle exec unicorn_rails -c config/unicorn.rb -E production -D"<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
add_daemon unicorn<br />
stat_done<br />
fi<br />
;;<br />
stop)<br />
stat_busy "Stopping unicorn"<br />
[ ! -z "$PID" ] && kill $PID &> /dev/null<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
rm_daemon unicorn<br />
stat_done<br />
fi<br />
;;<br />
restart)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
esac<br />
exit 0<br />
</pre><br />
<br />
Start '''unicorn''':<br />
<br />
# /etc/rc.d/unicorn-gitlab start<br />
<br />
Test it http://localhost:8080<br />
<br />
Add it to DAEMONS array in /etc/rc.conf<br />
<br />
Redirect http port to unicorn server<br />
<br />
# iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080<br />
<br />
And test again, now http://localhost<br />
<br />
===Nginx and unicorn===<br />
<br />
[[pacman|Install]] {{Pkg|nginx}} from the [[official repositories]].<br />
<br />
Run these commands to setup nginx:<br />
<br />
# wget https://raw.github.com/gitlabhq/gitlab-recipes/master/nginx/gitlab -P /etc/nginx/sites-available/<br />
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab <br />
<br />
Edit {{ic|/etc/nginx/sites-enabled/gitlab}} and change YOUR_SERVER_IP and YOUR_SERVER_FQDN to the IP address and fully-qualified domain name of the host serving Gitlab. As you can see nginx needs to access {{ic|/home/gitlab/gitlab/tmp/sockets/gitlab.socket}} socket file. You have to be able to run {{ic|sudo -u http ls /home/gitlab/gitlab/tmp/sockets/gitlab.socket}} successfully. Otherwise setup access to the directory:<br />
<br />
# chgrp http /home/gitlab<br />
# chmod u=rwx,g=rx,o= /home/gitlab<br />
<br />
Restart gitlab.service, resque.service and nginx.<br />
<br />
[http://unicorn.bogomips.org/ Unicorn] is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. First we rename the example file and then we start unicorn:<br />
<br />
# cd /home/gitlab/gitlab<br />
# sudo -u gitlab cp config/unicorn.rb.orig config/unicorn.rb<br />
# sudo -u gitlab bundle exec unicorn_rails -c config/unicorn.rb -E production -D<br />
<br />
===Apache and unicorn===<br />
<br />
[[pacman|Install]] {{Pkg|apache}} from the [[official repositories]]. <br />
<br />
====Configure Unicorn====<br />
<br />
{{Note|If the default path is not {{ic|/home/git}} for your installation, change the below path accordingly}}<br />
<br />
As the official installation guide instructs, copy the unicorn configuration file:<br />
# sudo -u git -H cp /home/git/gitlab/config/unicorn.rb.example /home/git/gitlab/config/unicorn.rb<br />
<br />
Now edit {{ic|config/unicorn.rb}} and add a listening port by uncommenting the following line:<br />
listen "127.0.0.1:8080"<br />
<br />
{{Tip| You can set a custom port if you want. Just remember to also include it in Apache's virtual host. See below.}}<br />
<br />
====Create a virtual host for Gitlab====<br />
<br />
Create a configuration file for Gitlab’s virtual host and insert the lines below adjusted accordingly. For the ssl section see [[LAMP#SSL]]. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the BalanceMember line.<br />
<br />
# mkdir -pv /etc/httpd/conf/vhosts/<br />
<br />
{{hc|/etc/httpd/conf/vhosts/gitlab|<br />
<VirtualHost *:80><br />
ServerName gitlab.myserver.com<br />
ServerAlias www.gitlab.myserver.com<br />
DocumentRoot /home/gitlab/gitlab/public<br />
ErrorLog /var/log/httpd/gitlab_error_log<br />
CustomLog /var/log/httpd/gitlab_access_log combined<br />
<br />
<Proxy balancer://unicornservers><br />
BalancerMember http://127.0.0.1:8080<br />
</Proxy><br />
<br />
<Directory /home/gitlab/gitlab/public><br />
AllowOverride All<br />
Options -MultiViews<br />
</Directory><br />
<br />
RewriteEngine on<br />
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f<br />
RewriteRule ^/(.*)$ balancer://unicornservers%{REQUEST_URI} [P,QSA,L]<br />
<br />
ProxyPass /uploads !<br />
ProxyPass / balancer://unicornservers/<br />
ProxyPassReverse / balancer://unicornservers/<br />
ProxyPreserveHost on<br />
<br />
<Proxy *><br />
Order deny,allow<br />
Allow from all<br />
</Proxy><br />
</VirtualHost><br />
<br />
<VirtualHost MY_IP:443><br />
ServerName gitlab.myserver.com<br />
ServerAlias www.gitlab.myserver.com<br />
DocumentRoot /home/gitlab/gitlab/public<br />
ErrorLog /var/log/httpd/gitlab_error_log<br />
CustomLog /var/log/httpd/gitlab_access_log combined<br />
<br />
<Proxy balancer://unicornservers><br />
BalancerMember http://127.0.0.1:8080<br />
</Proxy><br />
<br />
<Directory /home/gitlab/gitlab/public><br />
AllowOverride All<br />
Options -MultiViews<br />
</Directory><br />
<br />
RewriteEngine on<br />
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f<br />
RewriteRule ^/(.*)$ balancer://unicornservers%{REQUEST_URI} [P,QSA,L]<br />
<br />
ProxyPass /uploads !<br />
ProxyPass / balancer://unicornservers/<br />
ProxyPassReverse / balancer://unicornservers/<br />
ProxyPreserveHost on<br />
<br />
<Proxy *><br />
Order deny,allow<br />
Allow from all<br />
</Proxy><br />
<br />
SSLEngine on<br />
SSLCertificateFile /home/gitlab/gitlab/ssl.cert<br />
SSLCertificateKeyFile /home/gitlab/gitlab/ssl.key<br />
</VirtualHost><br />
}}<br />
<br />
====Enable host and start unicorn====<br />
<br />
Enable your Gitlab virtual host and reload [[Apache]]:<br />
{{hc|/etc/httpd/conf/httpd.conf|Include conf/vhosts/gitlab}}<br />
<br />
Finally start unicorn:<br />
<br />
# cd /home/gitlab/gitlab<br />
# sudo -u gitlab bundle exec unicorn_rails -c config/unicorn.rb -E production -D<br />
<br />
==systemd support==<br />
<br />
Note that you don't need the systemd units to launch shell scripts as suggested by the gitlab authors. Just make sure the ExecStart line points to the full path of the **bundle** executable. <br />
<br />
Create:<br />
{{hc|gitlab.service|<nowiki><br />
<br />
[Unit]<br />
Description=GitLab Puma Server<br />
<br />
[Service]<br />
User=git<br />
WorkingDirectory=/home/git/gitlab<br />
Environment=RAILS_ENV=production<br />
SyslogIdentifier=gitlab-puma<br />
Type=forking<br />
TimeoutStartSec=600<br />
PIDFile=/home/git/gitlab/tmp/pids/puma.pid<br />
<br />
ExecStart=/usr/bin/bundle exec "puma -C /home/git/gitlab/config/puma.rb -e production"<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
ExecStop=/bin/kill -QUIT $MAINPID<br />
<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki><br />
}}<br />
<br />
{{hc|gitlab-sidekiq.service|<nowiki><br />
[Unit]<br />
Description=GitLab Sidekiq Server<br />
<br />
[Service]<br />
User=git<br />
WorkingDirectory=/home/git/gitlab<br />
Environment=RAILS_ENV=production<br />
SyslogIdentifier=gitlab-sidekiq<br />
Type=forking<br />
PIDFile=/home/git/gitlab/tmp/pids/sidekiq.pid<br />
<br />
<br />
ExecStart=/usr/bin/bundle exec rake sidekiq:start<br />
ExecStop=/usr/bin/bundle exec rake sidekiq:stop<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki><br />
}}<br />
<br />
Also see: https://github.com/gitlabhq/gitlab-recipes/issues/14<br />
<br />
==Useful Tips==<br />
===Hook into /var===<br />
sudo mkdir -m700 /var/log/gitlab /var/tmp/gitlab<br />
sudo chown gitlab:gitlab /var/log/gitlab /var/tmp/gitlab<br />
sudo -u gitlab -i<br />
cd ~/gitlab<br />
d=log; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
d=tmp; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
<br />
===Hidden options===<br />
Go to Gitlab's home directory<br />
# cd /home/gitlab/gitlab<br />
<br />
and run<br />
# rake -T | grep gitlab<br />
<br />
These are the options so far:<br />
rake gitlab:app:backup_create # GITLAB | Create a backup of the gitlab system<br />
rake gitlab:app:backup_restore # GITLAB | Restore a previously created backup<br />
rake gitlab:app:enable_automerge # GITLAB | Enable auto merge<br />
rake gitlab:app:setup # GITLAB | Setup production application<br />
rake gitlab:app:status # GITLAB | Check gitlab installation status<br />
rake gitlab:gitolite:update_hooks # GITLAB | Rewrite hooks for repos<br />
rake gitlab:gitolite:update_keys # GITLAB | Rebuild each key at gitolite config<br />
rake gitlab:gitolite:update_repos # GITLAB | Rebuild each project at gitolite config<br />
rake gitlab:test # GITLAB | Run both cucumber & rspec<br />
<br />
===Backup and restore===<br />
<br />
Create a backup of the gitlab system:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create<br />
<br />
Restore the previously created backup file {{ic|/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar}}:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740<br />
<br />
{{Note| Backup folder is set in {{ic|config/gitlab.yml}}. GitLab backup and restore is documented [https://github.com/gitlabhq/gitlabhq/blob/master/doc/raketasks/backup_restore.md here].}}<br />
<br />
===Update Gitlab===<br />
<br />
When a new version is out follow the instructions at [https://github.com/gitlabhq/gitlabhq/wiki Github wiki]. A new release is out every 22nd of a month.<br />
<br />
===Migrate from sqlite to mysql===<br />
<br />
Get latest code as described in [[#Update_Gitlab]].<br />
Save data.<br />
# cd /home/gitlab/gitlab<br />
# sudo -u gitlab bundle exec rake db:data:dump RAILS_ENV=production<br />
<br />
Follow [[#Mysql]] instructions and then setup the database.<br />
# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production<br />
<br />
Finally restore old data.<br />
# sudo -u gitlab bundle exec rake db:data:load RAILS_ENV=production<br />
<br />
===Running GitLab with rvm===<br />
<br />
To run gitlab with rvm first you have to set up an rvm:<br />
<br />
curl -L https://get.rvm.io | bash -s stable --ruby=1.9.3<br />
<br />
{{Note|Version 1.9.3 is currently recommended to avoid some compatibility issues.}}<br />
<br />
For the complete installation you will want to be the final user (e.g. {{ic|git}}) so make sure to switch to this user and activate your rvm:<br />
<br />
su - git<br />
source "$HOME/.rvm/scripts/rvm"<br />
<br />
Then continue with the installation instructions from above. However, the systemd scripts will not work this way, because the environment for the rvm is not activated. The recommendation here is to create to separate shell scripts for {{ic|puma}} and {{ic|sidekiq}} to activate the environment and then start the service:<br />
<br />
{{hc|gitlab.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
RAILS_ENV=production bundle exec puma -C "/home/git/gitlab/config/puma.rb"</nowiki><br />
}}<br />
<br />
{{hc|sidekiq.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
case $1 in<br />
start)<br />
bundle exec rake sidekiq:start RAILS_ENV=production<br />
;;<br />
stop)<br />
bundle exec rake sidekiq:stop RAILS_ENV=production<br />
;;<br />
*)<br />
echo "Usage $0 {start|stop}"<br />
esac<br />
</nowiki>}}<br />
<br />
Then modify the above systemd files so they use these scripts. Modify the given lines:<br />
<br />
{{hc|gitlab.service|<nowiki><br />
ExecStart=/home/git/bin/gitlab.sh<br />
</nowiki>}}<br />
{{hc|sidekiq.service|<nowiki><br />
ExecStart=/home/git/bin/sidekiq.sh start<br />
ExecStop=/home/git/bin/sidekiq.sh stop<br />
</nowiki>}}<br />
<br />
==Troubleshooting==<br />
<br />
Sometimes things may not work as expected. Be sure to visit the [https://github.com/gitlabhq/gitlab-public-wiki/wiki/Trouble-Shooting-Guide Trouble Shooting Guide].<br />
<br />
==See also==<br />
*[https://github.com/gitlabhq/gitlabhq/blob/stable/doc/install/installation.md Official Documentation]<br />
*[https://github.com/gitlabhq/gitlab-recipes Gitlab recipes for setup on different platforms, update etc.]<br />
*[http://www.andmarios.com/en/2012/06/gitlab-on-an-ubuntu-10-04-server-with-apache/ GitLab on an Ubuntu 10.04 server with Apache]<br />
*[http://blog.phusion.nl/2012/04/21/tutorial-setting-up-gitlab-on-debian-6/ Setting up gitlab on Debian 6]<br />
*[http://howto.basjes.nl/linux/installing-gitlab-on-centos-6 Installing Gitlab on CentOS 6]<br />
*[https://gist.github.com/2440768 Gist: Install Gitlab on Debian Squeeze]<br />
*[https://gist.github.com/3305554 Gist: Install Gitlab on Archlinux]</div>Buergihttps://wiki.archlinux.org/index.php?title=Systemd&diff=267423Systemd2013-07-21T14:16:43Z<p>Buergi: /* Journal */ Add tip about disabling CoW for btrfs</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[ar:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[it:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN:Systemd]]<br />
[[zh-TW:Systemd]]<br />
{{Article summary start}}<br />
{{Article summary text|Covers how to install and configure systemd.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|systemd/User}}<br />
{{Article summary wiki|systemd/Services}}<br />
{{Article summary wiki|systemd FAQ}}<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|Daemons List}}<br />
{{Article summary wiki|udev}}<br />
{{Article summary wiki|Improve Boot Performance}}<br />
{{Article summary end}}<br />
From the [http://freedesktop.org/wiki/Software/systemd project web page]:<br />
<br />
:''systemd'' is a system and service manager for Linux, compatible with SysV and LSB init scripts. ''systemd'' provides aggressive parallelization capabilities, uses socket and [[D-Bus]] activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux [[cgroups|control groups]], supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.<br />
<br />
{{Note|1=For a detailed explanation as to why Arch has moved to ''systemd'', see [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 this forum post].}}<br />
<br />
== Migration from SysVinit/initscripts ==<br />
<br />
{{Note|<br />
* {{Pkg|systemd}} and {{Pkg|systemd-sysvcompat}} are both installed by default on installation media newer than [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 2012-10-13]. This section is aimed at Arch Linux installations that still rely on ''sysvinit'' and ''initscripts''.<br />
* If you are running Arch Linux inside a VPS, please see [[Virtual Private Server#Moving your VPS from initscripts to systemd]].<br />
}}<br />
<br />
=== Considerations before switching ===<br />
<br />
* Do [http://freedesktop.org/wiki/Software/systemd/ some reading] about ''systemd''.<br />
* Note the fact that systemd has a ''journal'' system that replaces ''syslog'', although the two can co-exist. See [[#Journal]].<br />
* While ''systemd'' can replace some of the functionality of ''cron'', ''acpid'', or ''xinetd'', there is no need to switch away from using the traditional daemons unless you want to.<br />
* Interactive ''initscripts'' are not working with ''systemd''. In particular, ''netcfg-menu'' cannot be used at system start-up ({{Bug|31377}}).<br />
<br />
=== Installation procedure ===<br />
<br />
# [[pacman|Install]] {{Pkg|systemd}} from the [[official repositories]].<br />
# Append the following to your [[kernel parameters]]: {{ic|1=init=/usr/lib/systemd/systemd}}.<br />
# Once completed you may enable any desired services via the use of {{ic|systemctl enable ''service_name''}} (this roughly equates to what you included in the {{ic|DAEMONS}} array. New names can be found in [[Daemons List]]).<br />
# Reboot your system and verify that ''systemd'' is currently active by issuing the following command: {{ic|cat /proc/1/comm}}. This should return the string {{ic|systemd}}.<br />
# Make sure your hostname is set correctly under ''systemd'': {{ic|hostnamectl set-hostname ''myhostname''}}.<br />
# Proceed to remove ''initscripts'' and ''sysvinit'' from your system and install {{Pkg|systemd-sysvcompat}}.<br />
# Optionally, remove the {{ic|1=init=/usr/lib/systemd/systemd}} parameter as it is no longer needed. {{Pkg|systemd-sysvcompat}} provides the default init.<br />
<br />
=== Supplementary information ===<br />
<br />
* If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.<br />
<br />
* It is not necessary to add your user to [[Users and Groups|groups]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) for most use cases with systemd. The groups can even cause some functionality to break. For example, the {{ic|audio}} group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via [[Wikipedia:Access control list|POSIX ACLs]] on audio/video devices, and allow certain operations like mounting removable storage via [[udisks]].<br />
<br />
* See the [[Network Configuration]] article for how to set up networking targets.<br />
<br />
== Basic systemctl usage ==<br />
<br />
The main command used to introspect and control ''systemd'' is '''systemctl'''. Some of its uses are examining the system state and managing the system and services. See {{ic|man 1 systemctl}} for more details.<br />
<br />
{{Tip|You can use all of the following ''systemctl'' commands with the {{ic|-H ''user''@''host''}} switch to control a ''systemd'' instance on a remote machine. This will use [[SSH]] to connect to the remote ''systemd'' instance.}}<br />
<br />
{{Note|''systemadm'' is the official graphical frontend for ''systemctl''. It is provided by the {{AUR|systemd-ui-git}} package from the [[AUR]].}}<br />
<br />
=== Analyzing the system state ===<br />
<br />
List running units:<br />
<br />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ systemctl --failed<br />
<br />
The available unit files can be seen in {{ic|/usr/lib/systemd/system/}} and {{ic|/etc/systemd/system/}} (the latter takes precedence). You can see a list of the installed unit files with:<br />
<br />
$ systemctl list-unit-files<br />
<br />
=== Using units ===<br />
<br />
Units can be, for example, services (''.service''), mount points (''.mount''), devices (''.device'') or sockets (''.socket'').<br />
<br />
When using ''systemctl'', you generally have to specify the complete name of the unit file, including its suffix, for example ''sshd.socket''. There are however a few short forms when specifying the unit in the following ''systemctl'' commands:<br />
<br />
* If you do not specify the suffix, systemctl will assume ''.service''. For example, {{ic|netcfg}} and {{ic|netcfg.service}} are equivalent.<br />
* Mount points will automatically be translated into the appropriate ''.mount'' unit. For example, specifying {{ic|/home}} is equivalent to {{ic|home.mount}}.<br />
* Similiar to mount points, devices are automatically translated into the appropriate ''.device'' unit, therefore specifying {{ic|/dev/sda2}} is equivalent to {{ic|dev-sda2.device}}.<br />
<br />
See {{ic|man systemd.unit}} for details.<br />
<br />
Activate a unit immediately:<br />
<br />
# systemctl start ''unit''<br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop ''unit''<br />
<br />
Restart a unit:<br />
<br />
# systemctl restart ''unit''<br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload ''unit''<br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status ''unit''<br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled ''unit''<br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable ''unit''<br />
<br />
{{Note|Services without an {{ic|[Install]}} section are usually called automatically by other services. If you need to install them manually, use the following command, replacing ''foo'' with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable ''unit''<br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ systemctl help ''unit''<br />
<br />
Reload ''systemd'', scanning for new or changed units:<br />
<br />
# systemctl daemon-reload<br />
<br />
=== Power management ===<br />
<br />
[[polkit]] is necessary for power management. If you are in a local ''systemd-logind'' user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), ''systemd'' will automatically ask you for the root password.<br />
<br />
Shut down and reboot the system:<br />
<br />
$ systemctl reboot<br />
<br />
Shut down and power-off the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Put the system into hibernation:<br />
<br />
$ systemctl hibernate<br />
<br />
Put the system into hybrid-sleep state (or suspend-to-both):<br />
<br />
$ systemctl hybrid-sleep<br />
<br />
== Running DMs under systemd ==<br />
<br />
To enable graphical login, run your preferred [[Display Manager]] daemon (e.g. [[KDM]]). At the moment, service files exist for [[GDM]], [[KDM]], [[SLiM]], [[XDM]], [[LXDM]], [[LightDM]], and {{AUR|SDDM}}.<br />
<br />
# systemctl enable kdm<br />
<br />
This should work out of the box. If not, you might have a ''default.target'' set manually or from an older install:<br />
<br />
{{hc|# ls -l /etc/systemd/system/default.target|<br />
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}<br />
<br />
Simply delete the symlink and ''systemd'' will use its stock ''default.target'' (i.e. ''graphical.target'').<br />
<br />
# rm /etc/systemd/system/default.target<br />
<br />
=== Using systemd-logind ===<br />
<br />
In order to check the status of your user session, you can use {{ic|loginctl}}. All [[PolicyKit]] actions like suspending the system or mounting external drives will work out of the box.<br />
<br />
$ loginctl show-session $XDG_SESSION_ID<br />
<br />
== Native configuration ==<br />
<br />
{{Note|You may need to create these files. All files should have {{ic|644}} permissions and {{ic|root:root}} ownership.}}<br />
<br />
=== Virtual console ===<br />
{{Deletion|Not strictly related, trying to remove the [[#Native configuration]] section entirely.|section=Duplication of content in Native configuration section}}<br />
<br />
The virtual console (keyboard mapping, console font and console map) is configured in {{ic|/etc/vconsole.conf}} or by using the ''localectl'' tool.<br />
<br />
For more information, see [[Fonts#Console fonts|console fonts]] and [[KEYMAP|keymaps]].<br />
<br />
=== Hardware clock ===<br />
{{Merge|Time|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
''systemd'' will use UTC for the hardware clock by default.<br />
<br />
{{Tip|It is advised to have the [[Network Time Protocol daemon]] running to keep the system time synchronized with Internet time and the hardware clock.}}<br />
<br />
==== Hardware clock in localtime ====<br />
<br />
If you want to change the hardware clock to use local time ('''strongly discouraged''') do:<br />
<br />
# timedatectl set-local-rtc true<br />
<br />
If you want to revert to the hardware clock being in UTC, do:<br />
<br />
# timedatectl set-local-rtc false<br />
<br />
Be warned that, if the hardware clock is set to localtime, dealing with daylight saving time is messy. If the DST changes when your computer is off, your clock will be wrong on next boot ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html there is a lot more to it]). Recent kernels set the system time from the RTC directly on boot, assuming that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is the root of certain weird bugs (time going backwards is rarely a good thing).<br />
<br />
One reason for allowing the RTC to be in local time is to allow dual boot with Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx which uses localtime]). However, Windows is able to deal with the RTC being in UTC with a simple [[Time#UTC in Windows|registry fix]]. It is recommended to configure Windows to use UTC, rather than Linux to use localtime. If you make Windows use UTC, also remember to disable the "Internet Time Update" Windows feature, so that Windows does not mess with the hardware clock, trying to sync it with internet time. You should instead leave touching the RTC and syncing it to internet time to Linux, by enabling an [[NTP]] daemon, as suggested previously.<br />
<br />
For more information, see [[Time]].<br />
<br />
=== Kernel modules ===<br />
{{Deletion|Not strictly related, trying to remove the [[#Native configuration]] section entirely.|section=Duplication of content in Native configuration section}}<br />
<br />
See [[Kernel modules#Configuration]].<br />
<br />
=== Filesystem mounts ===<br />
{{Merge|File Systems|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
The default setup will automatically fsck and mount filesystems before starting services that need them to be mounted. For example, systemd automatically makes sure that remote filesystem mounts like [[NFS]] or [[Samba]] are only started after the network has been set up. Therefore, local and remote filesystem mounts specified in {{ic|/etc/fstab}} should work out of the box.<br />
<br />
See {{ic|man 5 systemd.mount}} for details.<br />
<br />
==== Automount ====<br />
{{Merge|fstab|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
If you have a large {{ic|/home}} partition, it might be better to allow services that do not depend on {{ic|/home}} to start while {{ic|/home}} is checked by ''fsck''. This can be achieved by adding the following options to the {{ic|/etc/fstab}} entry of your {{ic|/home}} partition:<br />
<br />
noauto,x-systemd.automount<br />
<br />
This will fsck and mount {{ic|/home}} when it is first accessed, and the kernel will buffer all file access to {{ic|/home}} until it is ready.<br />
<br />
{{Note|This will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.}}<br />
<br />
The same applies to remote filesystem mounts. If you want them to be mounted only upon access, you will need to use the {{ic|noauto,x-systemd.automount}} parameters. In addition, you can use the {{ic|1=x-systemd.device-timeout=#}} option to specify a timeout in case the network resource is not available.<br />
<br />
If you have encrypted filesystems with keyfiles, you can also add the {{ic|noauto}} parameter to the corresponding entries in {{ic|/etc/crypttab}}. ''systemd'' will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd does not have to wait for the device to become available. For example:<br />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
==== LVM ====<br />
{{Merge|LVM|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
If you have [[LVM]] volumes not activated via the [[Mkinitcpio|initramfs]], [[Systemd#Using_units|enable]] the '''lvm-monitoring''' service, which is provided by the {{pkg|lvm2}} package.<br />
<br />
=== ACPI power management ===<br />
{{Merge|Power Management|This section was added here before systemd became the default init system. Delete it after merging. [[Power Management]] is mainly used to link to other articles at the moment, but since systemd is default on Arch now, this section could stay there.|section=Duplication of content in Native configuration section}}<br />
<br />
''systemd'' handles some power-related [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] events. They can be configured via the following options from {{ic|/etc/systemd/logind.conf}}:<br />
<br />
* {{ic|HandlePowerKey}}: specifies which action is invoked when the power key is pressed.<br />
* {{ic|HandleSuspendKey}}: specifies which action is invoked when the suspend key is pressed.<br />
* {{ic|HandleHibernateKey}}: specifies which action is invoked when the hibernate key is pressed.<br />
* {{ic|HandleLidSwitch}}: specifies which action is invoked when the lid is closed.<br />
<br />
The specified action can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}}, {{ic|hybrid-sleep}}, {{ic|lock}} or {{ic|kexec}}.<br />
<br />
If these options are not configured, ''systemd'' will use its defaults: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, and {{ic|1=HandleLidSwitch=suspend}}.<br />
<br />
On systems which run no graphical setup or only a simple window manager like [[i3]] or [[awesome]], this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
{{Note|<br />
* Run {{ic|systemctl restart systemd-logind}} for your changes to take effect.<br />
* ''systemd'' cannot handle AC and Battery ACPI events, so if you use [[Laptop Mode Tools]] or other similar tools [[acpid]] is still required.<br />
}}<br />
<br />
In the current version of ''systemd'', the {{ic|Handle*}} options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If these inhibits are not taken, you can end up with a situation where ''systemd'' suspends your system, then when it wakes up the other power manager suspends it again.<br />
<br />
{{Warning|Currently, the power managers in the newest versions of [[KDE]] and [[GNOME]] are the only ones that issue the necessary "inhibited" commands. Until the others do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[Xfce]], [[acpid]] or other programs.}}<br />
<br />
{{Note|''systemd'' can also use other suspend backends (such as [[Uswsusp]] or [[TuxOnIce]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate.}}<br />
<br />
For {{ic|systemctl hibernate}} to work on your system you need to follow the instructions at [[Pm-utils#Hibernation (suspend2disk)]] and possibly at [[Pm-utils#Mkinitcpio Resume Hook]] (''pm-utils'' does ''not'' need to be installed). <br />
<br />
==== Sleep hooks ====<br />
<br />
''systemd'' does not use [[pm-utils]] to put the machine to sleep when using {{ic|systemctl suspend}}, {{ic|systemctl hibernate}} or {{ic|systemctl hybrid-sleep}}; ''pm-utils'' hooks, including any [[Pm-utils#Creating_your_own_hooks|custom hooks]], will not be run. However, ''systemd'' provides two similar mechanisms to run custom scripts on these events.<br />
<br />
===== Suspend/resume service files =====<br />
<br />
Service files can be hooked into ''suspend.target'', ''hibernate.target'' and ''sleep.target'' to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. To activate the user service files run {{ic|systemctl enable suspend@''user'' && systemctl enable resume@''user''}}. Examples:<br />
<br />
{{hc|/etc/systemd/system/suspend@.service|2=<nowiki><br />
[Unit]<br />
Description=User suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'<br />
ExecStart=/usr/bin/sflock<br />
<br />
[Install]<br />
WantedBy=sleep.target</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/resume@.service|2=<nowiki><br />
[Unit]<br />
Description=User resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
User=%I<br />
Type=simple<br />
ExecStartPre=/usr/local/bin/ssh-connect.sh<br />
ExecStart=/usr/bin/mysql -e 'slave start'<br />
<br />
[Install]<br />
WantedBy=suspend.target</nowiki>}}<br />
<br />
For root/system actions (activate with {{ic|systemctl enable root-suspend}}):<br />
<br />
{{hc|/etc/systemd/system/root-resume.service|2=<nowiki><br />
[Unit]<br />
Description=Local system resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart mnt-media.automount<br />
<br />
[Install]<br />
WantedBy=suspend.target</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/root-suspend.service|2=<nowiki><br />
[Unit]<br />
Description=Local system suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=-/usr/bin/pkill sshfs<br />
<br />
[Install]<br />
WantedBy=sleep.target</nowiki>}}<br />
<br />
A couple of handy hints about these service files (more in {{ic|man systemd.service}}):<br />
* If {{ic|1=<nowiki>Type=OneShot</nowiki>}} then you can use multiple {{ic|1=<nowiki>ExecStart=</nowiki>}} lines. Otherwise only one {{ic|ExecStart}} line is allowed. You can add more commands with either {{ic|ExecStartPre}} or by separating commands with a semicolon (see the first example above; note the spaces before and after the semicolon, as they are ''required'').<br />
* A command prefixed with {{ic|-}} will cause a non-zero exit status to be ignored and treated as a successful command. <br />
* The best place to find errors when troubleshooting these service files is of course with [[Systemd#Journal|journalctl]].<br />
<br />
===== Combined Suspend/resume service file =====<br />
<br />
With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).<br />
<br />
Example and explanation:<br />
<br />
{{hc|/etc/systemd/system/wicd-sleep.service|2=<nowiki><br />
[Unit]<br />
Description=Wicd sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/share/wicd/daemon/suspend.py<br />
ExecStop=-/usr/share/wicd/daemon/autoconnect.py<br />
<br />
[Install]<br />
WantedBy=sleep.target</nowiki>}}<br />
<br />
* {{ic|1=<nowiki>RemainAfterExit=yes</nowiki>}}: After started, the service is considered active until it is explicitly stopped.<br />
* {{ic|1=<nowiki>StopWhenUnneeded=yes</nowiki>}}: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after ''sleep.target'' is stopped.<br />
* Because ''sleep.target'' is pulled in by ''suspend.target'', ''hibernate.target'' and ''hybrid-sleep.target'' and ''sleep.target'' itself is a ''StopWhenUnneeded'' service, the hook is guaranteed to start/stop properly for different tasks.<br />
<br />
===== Hooks in /usr/lib/systemd/system-sleep =====<br />
<br />
''systemd'' runs all executables in {{ic|/usr/lib/systemd/system-sleep/}}, passing two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} or {{ic|hybrid-sleep}}, depending on which is being invoked<br />
<br />
In contrast to [[pm-utils]], ''systemd'' will run these scripts concurrently and not one after another.<br />
<br />
The output of any custom script will be logged by ''systemd-suspend.service'', ''systemd-hibernate.service'' or ''systemd-hybrid-sleep.service''. You can see its output in ''systemd''<nowiki>'</nowiki>s [[systemd#Journal|journal]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
{{Note|You can also use ''sleep.target'', ''suspend.target'', ''hibernate.target'' or ''hybrid-sleep.target'' to hook units into the sleep state logic instead of using custom scripts.}}<br />
<br />
An example of a custom sleep script:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<br />
#!/bin/sh<br />
case $1/$2 in<br />
pre/*)<br />
echo "Going to $2..."<br />
;;<br />
post/*)<br />
echo "Waking up from $2..."<br />
;;<br />
esac}}<br />
<br />
Do not forget to make your script executable:<br />
# chmod a+x /usr/lib/systemd/system-sleep/example.sh<br />
<br />
See {{ic|man 7 systemd.special}} and {{ic|man 8 systemd-sleep}} for more details.<br />
<br />
=== Temporary files ===<br />
{{Moveto|Systemd#|Trying to remove the [[#Native configuration]] section entirely, this section can easily become a top-level one like [[#Journal]].|section=Duplication of content in Native configuration section}}<br />
<br />
'''systemd-tmpfiles''' uses configuration files in {{ic|/usr/lib/tmpfiles.d/}} and {{ic|/etc/tmpfiles.d/}} to describe the creation, cleaning and removal of volatile and temporary files and directories which usually reside in directories such as {{ic|/run}} or {{ic|/tmp}}. Each configuration file is named in the style of {{ic|/etc/tmpfiles.d/''program''.conf}}. This will also override any files in {{ic|/usr/lib/tmpfiles.d/}} with the same name.<br />
<br />
tmpfiles are usually provided together with service files to create directories which are expected to exist by certain daemons. For example the [[Samba]] daemon expects the directory {{ic|/run/samba}} to exist and to have the correct permissions. The corresponding tmpfile looks like this:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /run/samba 0755 root root}}<br />
<br />
{{Out of date|initscripts is deprecated.}}<br />
<br />
tmpfiles may also be used to write values into certain files on boot. For example, if you use {{ic|/etc/rc.local}} to disable wakeup from USB devices with {{ic|echo USBE > /proc/acpi/wakeup}}, you may use the following tmpfile instead:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
See {{ic|man 5 tmpfiles.d}} for details.<br />
<br />
{{Note|This method may not work to set options in {{ic|/sys}} since the ''systemd-tmpfiles-setup'' service may run before the appropriate device modules is loaded. In this case you could check whether the module has a parameter for the option you want to set with {{ic|modinfo ''module''}} and set this option with a [[Modprobe.d#Configuration|config file in /etc/modprobe.d]]. Otherwise you will have to write a [[Udev#About_udev_rules|udev rule]] to set the appropriate attribute as soon as the device appears.}}<br />
<br />
=== Units ===<br />
{{Merge|#Writing custom .service files|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
A ''unit'' configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a file system path or a timer controlled and supervised by ''systemd''. The syntax is inspired by XDG Desktop Entry Specification ''.desktop'' files, which are in turn inspired by Microsoft Windows ''.ini'' files.<br />
<br />
See {{ic|man 5 systemd.unit}} for details.<br />
<br />
== Writing custom .service files ==<br />
<br />
See also [[systemd/Services]].<br />
<br />
=== Handling dependencies ===<br />
<br />
With ''systemd'', dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit ''A'' requires the unit ''B'' to be running before ''A'' is started. In that case add {{ic|1=Requires=''B''}} and {{ic|1=After=''B''}} to the {{ic|[Unit]}} section of ''A''. If the dependency is optional, add {{ic|1=Wants=''B''}} and {{ic|1=After=''B''}} instead. Note that {{ic|1=Wants=}} and {{ic|1=Requires=}} do not imply {{ic|1=After=}}, meaning that if {{ic|1=After=}} is not specified, the two units will be started in parallel.<br />
<br />
Dependencies are typically placed on services and not on targets. For example, ''network.target'' is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since ''network.target'' is started anyway.<br />
<br />
=== Type ===<br />
<br />
There are several different start-up types to consider when writing a custom service file. This is set with the {{ic|1=Type=}} parameter in the {{ic|[Service]}} section. See {{ic|man systemd.service}} for a more detailed explanation.<br />
<br />
* {{ic|1=Type=simple}} (default): ''systemd'' considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.<br />
* {{ic|1=Type=forking}}: ''systemd'' considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify {{ic|1=PIDFile=}} as well so ''systemd'' can keep track of the main process.<br />
* {{ic|1=Type=oneshot}}: this is useful for scripts that do a single job and then exit. You may want to set {{ic|1=RemainAfterExit=yes}} as well so that ''systemd'' still considers the service as active after the process has exited.<br />
* {{ic|1=Type=notify}}: identical to {{ic|1=Type=simple}}, but with the stipulation that the daemon will send a signal to ''systemd'' when it is ready. The reference implementation for this notification is provided by ''libsystemd-daemon.so''.<br />
* {{ic|1=Type=dbus}}: the service is considered ready when the specified {{ic|BusName}} appears on DBus's system bus.<br />
<br />
=== Editing provided unit files ===<br />
<br />
To edit a unit file provided by a package, you can create a directory called {{ic|/etc/systemd/system/''unit''.d/}} for example {{ic|/etc/systemd/system/httpd.service.d/}} and place ''*.conf'' files in there to override or add new options. ''systemd'' will parse these ''*.conf'' files and apply them on top of the original unit. For example, if you simply want to add an additional dependency to a unit, you may create the following file:<br />
<br />
{{hc|/etc/systemd/system/''unit''.d/customdependency.conf|2=<br />
[Unit]<br />
Requires=''new dependency''<br />
After=''new dependency''}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl daemon-reload<br />
# systemctl restart ''unit''<br />
<br />
Alternatively you can copy the old unit file from {{ic|/usr/lib/systemd/system/}} to {{ic|/etc/systemd/system/}} and make your changes there. A unit file in {{ic|/etc/systemd/system/}} always overrides the same unit in {{ic|/usr/lib/systemd/system/}}. Note that when the original unit in {{ic|/usr/lib/}} is changed due to a package upgrade, these changes will not automatically apply to your custom unit file in {{ic|/etc/}}. Additionally you will have to manually reenable the unit with {{ic|systemctl reenable ''unit''}}. It is therefore recommended to use the ''*.conf'' method described before instead.<br />
<br />
{{Tip|You can use '''systemd-delta''' to see which unit files have been overridden and what exactly has been changed.}}<br />
<br />
As the provided unit files will be updated from time to time, use ''systemd-delta'' for system maintenance.<br />
<br />
=== Syntax highlighting for units within Vim ===<br />
<br />
Syntax highlighting for ''systemd'' unit files within [[Vim]] can be enabled by installing {{Pkg|vim-systemd}} from the [[Official Repositories|official repositories]].<br />
<br />
== Targets ==<br />
<br />
''systemd'' uses ''targets'' which serve a similar purpose as runlevels but act a little different. Each ''target'' is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some ''target''s are implemented by inheriting all of the services of another ''target'' and adding additional services to it. There are ''systemd'' ''target''s that mimic the common SystemVinit runlevels so you can still switch ''target''s using the familiar {{ic|telinit RUNLEVEL}} command.<br />
<br />
=== Get current targets ===<br />
<br />
The following should be used under ''systemd'' instead of running {{ic|runlevel}}:<br />
<br />
$ systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<br />
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific ''systemd'' ''target''. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named ''systemd'' ''target'' as {{ic|/etc/systemd/system/''your target''}} that takes one of the existing runlevels as a base (you can look at {{ic|/usr/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/''your target''.wants}}, and then symlink the additional services from {{ic|/usr/lib/systemd/system/}} that you wish to enable.<br />
<br />
=== Targets table ===<br />
<br />
{| border="1"<br />
! SysV Runlevel !! systemd Target !! Notes<br />
|-<br />
| 0 || runlevel0.target, poweroff.target || Halt the system.<br />
|-<br />
| 1, s, single || runlevel1.target, rescue.target || Single user mode.<br />
|-<br />
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || User-defined/Site-specific runlevels. By default, identical to 3.<br />
|-<br />
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.<br />
|-<br />
| 5 || runlevel5.target, graphical.target || Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.<br />
|-<br />
| 6 || runlevel6.target, reboot.target || Reboot<br />
|-<br />
| emergency || emergency.target || Emergency shell<br />
|-<br />
|}<br />
<br />
=== Change current target ===<br />
<br />
In ''systemd'' targets are exposed via ''target units''. You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<br />
This will only change the current target, and has no effect on the next boot. This is equivalent to commands such as {{ic|telinit 3}} or {{ic|telinit 5}} in Sysvinit.<br />
<br />
=== Change default target to boot into ===<br />
<br />
The standard target is ''default.target'', which is aliased by default to ''graphical.target'' (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following [[kernel parameters]] to your bootloader:<br />
<br />
{{Tip|The ''.target'' extension can be left out.}}<br />
<br />
* {{ic|1=systemd.unit=multi-user.target}} (which roughly corresponds to the old runlevel 3),<br />
* {{ic|1=systemd.unit=rescue.target}} (which roughly corresponds to the old runlevel 1).<br />
<br />
Alternatively, you may leave the bootloader alone and change ''default.target''. This can be done using ''systemctl'':<br />
<br />
# systemctl enable multi-user.target<br />
<br />
The effect of this command is output by ''systemctl''; a symlink to the new default target is made at {{ic|/etc/systemd/system/default.target}}. This works if, and only if:<br />
<br />
[Install]<br />
Alias=default.target<br />
<br />
is in the target's configuration file. Currently, ''multi-user.target'' and ''graphical.target'' both have it.<br />
<br />
== Journal ==<br />
<br />
''systemd'' has its own logging system called the journal; therefore, running a syslog daemon is no longer required. To read the log, use:<br />
<br />
# journalctl<br />
<br />
By default (when {{ic|1=Storage=}} is set to {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), the journal writes to {{ic|/var/log/journal/}}. The directory {{ic|/var/log/journal/}} is a part of the ''systemd'' package. If you or some program delete that directory, systemd will '''not''' recreate it automatically; however, it will be recreated during the next update of the systemd package. Until then, logs will be written to {{ic|/run/systemd/journal}}, and logs will be lost on reboot.<br />
<br />
{{Tip|If {{ic|/var/log/journal/}} resides in a [[btrfs]] filesystem you should consider disabling [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] for the directory:<br />
{{ic|# chattr +C /var/log/journal}}<br />
}}<br />
<br />
=== Filtering output ===<br />
<br />
''journalctl'' allows you to filter the output by specific fields.<br />
<br />
Examples:<br />
<br />
Show all messages from this boot:<br />
<br />
# journalctl -b<br />
<br />
However, often one is interested in messages not from the current, but from the previous boot (e.g. if an unrecoverable system crash happened). Currently, this feature is not implemented, though there was a discussion at [http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/6608 systemd-devel@lists.freedesktop.org] (September/October 2012).<br />
<br />
As a workaround you can use at the moment:<br />
<br />
# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac<br />
<br />
provided, that the previous boot happened today. Be aware that, if there are many messages for the current day, the output of this command can be delayed for quite some time.<br />
<br />
Follow new messages:<br />
<br />
# journalctl -f<br />
<br />
Show all messages by a specific executable:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# journalctl -u netcfg<br />
<br />
See {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}}, or Lennert's [http://0pointer.de/blog/projects/journalctl.html blog post] for details.<br />
<br />
=== Journal size limit ===<br />
<br />
If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the respective file system. For example, with {{ic|/var/log/journal}} located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:<br />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with syslog ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. To make the syslog daemon work with the journal, it has to bind to this socket instead of {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). The {{Pkg|syslog-ng}} package in the repositories automatically provides the necessary configuration.<br />
<br />
# systemctl enable syslog-ng<br />
<br />
A good ''journalctl'' tutorial is [http://0pointer.de/blog/projects/journalctl.html here].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Shutdown/reboot takes terribly long ===<br />
<br />
If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. ''systemd'' waits some time for each service to exit before trying to kill it. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
<br />
=== Short lived processes do not seem to log any output ===<br />
<br />
If {{ic|journalctl -u foounit}} does not show any output for a short lived service, look at the PID instead. For example, if {{ic|systemd-modules-load.service}} fails, and {{ic|systemctl status systemd-modules-load}} shows that it ran as PID 123, then you might be able to see output in the journal for that PID, i.e. {{ic|journalctl -b _PID&#61;123}}. Metadata fields for the journal such as _SYSTEMD_UNIT and _COMM are collected asynchronously and rely on the {{ic|/proc}} directory for the process existing. Fixing this requires fixing the kernel to provide this data via a socket connection, similar to SCM_CREDENTIALS.<br />
<br />
=== Diagnosing boot problems ===<br />
<br />
Boot with these parameters on the kernel command line:<br />
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}<br />
<br />
[http://freedesktop.org/wiki/Software/systemd/Debugging More Debugging Information]<br />
<br />
=== Disabling application crash dumps journaling ===<br />
<br />
To get back normal core dump files, edit the following file in order to overwrite the settings from {{ic|/lib/sysctl.d/}}:<br />
<br />
{{hc|/etc/sysctl.d/49-coredump.conf|2=<nowiki><br />
kernel.core_pattern = core<br />
kernel.core_uses_pid = 0</nowiki>}}<br />
<br />
Then run:<br />
# /usr/lib/systemd/systemd-sysctl<br />
<br />
As before, you also need to "unlimit" the core files size in the shell:<br />
$ ulimit -c unlimited<br />
<br />
See [http://www.freedesktop.org/software/systemd/man/sysctl.d.html sysctl.d] and [https://www.kernel.org/doc/Documentation/sysctl/kernel.txt the documentation for /proc/sys/kernel] for more information.<br />
<br />
== See also ==<br />
<br />
*[http://www.freedesktop.org/wiki/Software/systemd Official web site]<br />
*[[Wikipedia:systemd|Wikipedia article]]<br />
*[http://0pointer.de/public/systemd-man/ Manual pages]<br />
*[http://freedesktop.org/wiki/Software/systemd/Optimizations systemd optimizations]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips and tricks]<br />
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]<br />
*[http://fedoraproject.org/wiki/Systemd About systemd on Fedora Project]<br />
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems How to debug systemd problems]<br />
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] introductory article in ''The H Open'' magazine.<br />
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]<br />
*[http://0pointer.de/blog/projects/systemd-update.html Status update]<br />
*[http://0pointer.de/blog/projects/systemd-update-2.html Status update2]<br />
*[http://0pointer.de/blog/projects/systemd-update-3.html Status update3]<br />
*[http://0pointer.de/blog/projects/why.html Most recent summary]<br />
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]</div>Buergihttps://wiki.archlinux.org/index.php?title=MariaDB&diff=267422MariaDB2013-07-21T14:13:21Z<p>Buergi: /* Installation */ Add tip about disabling CoW for btrfs</p>
<hr />
<div>[[Category:Database management systems]]<br />
[[cs:MySQL]]<br />
[[de:MySQL]]<br />
[[es:MySQL]]<br />
[[fr:MySQL]]<br />
[[it:MySQL]]<br />
[[sr:MySQL]]<br />
[[tr:MySQL]]<br />
[[zh-CN:MySQL]]<br />
MySQL is a widely spread, multi-threaded, multi-user SQL database. For more information about features, see the [http://www.mysql.com/ official homepage].<br />
<br />
{{Note|MariaDB is now officially Arch Linux default implementation of MySQL. It is recommended for all users to [[#Upgrade from Oracle MySQL to MariaDB|upgrade]] to MariaDB. Oracle MySQL was dropped to the AUR. See [https://www.archlinux.org/news/mariadb-replaces-mysql-in-repositories/ the announcement].}}<br />
<br />
== Installation ==<br />
<br />
The MySQL implementation choosen by Archlinux is called MariaDB.<br />
[[pacman|Install]] {{Pkg|mariadb}}, {{Pkg|libmariadbclient}}, {{Pkg|mariadb-clients}} packages from the [[official repositories]].<br />
Alternate implementations are {{Pkg|percona-server}} and Oracle {{AUR|mysql}}.<br />
<br />
{{Tip|If the database (in /var/lib/mysql) resides in a [[btrfs]] filesystem you should consider disabling [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] for the directory before creating any database:<br />
{{ic|# chattr +C /var/lib/mysql}}<br />
}}<br />
<br />
Start the {{ic|mysqld}} [[daemon]], run the setup script and restart the daemon afterwards:<br />
# systemctl start mysqld<br />
# mysql_secure_installation<br />
# systemctl restart mysqld<br />
<br />
Frontends available are {{AUR|mysql-gui-tools}} and {{AUR|mysql-workbench}}.<br />
<br />
=== Upgrade from Oracle MySQL to MariaDB ===<br />
<br />
Users who want to switch will need to install mariadb, libmariadbclient or mariadb-clients and execute mysql_upgrade in order to migrate their systems.<br />
# systemctl stop mysqld<br />
# pacman -S mariadb libmariadbclient mariadb-clients<br />
# systemctl start mysqld<br />
# mysql_upgrade -p<br />
<br />
=== On update ===<br />
<br />
You might consider running this command after you have upgraded MySQL and started it:<br />
# mysql_upgrade -u root -p<br />
<br />
== Configuration ==<br />
<br />
Once you have started the MySQL server, you probably want to add a root account in order to maintain your MySQL users and databases. This can be done manually or automatically, as mentioned by the output of the above script. Either run the commands to set a password for the root account, or run the secure installation script.<br />
<br />
You now should be able to do further configuration using your favorite interface. For example you can use MySQL's command line tool to log in as root into your MySQL server:<br />
$ mysql -p -u root<br />
<br />
=== Disable remote access ===<br />
<br />
The MySQL server is accessible from the network by default. If MySQL is only needed for the localhost, you can improve security by not listening on TCP port 3306. To refuse remote connections, uncomment the following line in {{ic|/etc/mysql/my.cnf}}:<br />
skip-networking<br />
<br />
You will still be able to log in from the localhost.<br />
<br />
=== Enable auto-completion ===<br />
<br />
{{Note|Enabling this feature can make the client initialization longer.}}<br />
The MySQL client completion feature is disabled by default. To enable it system-wide edit {{ic|/etc/mysql/my.cnf}}, and replace {{ic|no-auto-rehash}} by {{ic|auto-rehash}}. Completion will be enabled next time you run the MySQL client.<br />
<br />
=== Using UTF-8 ===<br />
<br />
In the {{ic|/etc/mysql/my.cnf}} file section under the "mysqld" group, add:<br />
<br />
{{bc|<nowiki>[mysqld]<br />
init_connect = 'SET collation_connection = utf8_general_ci,NAMES utf8'<br />
collation_server = utf8_general_ci<br />
character_set_client = utf8<br />
character_set_server = utf8</nowiki>}}<br />
<br />
=== Using a TMPFS for tmpdir ===<br />
<br />
The directory used by MySQL for storing temporary files is named "tmpdir". For example, it is used to perform disk based large sorts, as well as for internal and explicit temporary tables.<br />
<br />
Create the directory with appropriate permissions:<br />
$ mkdir -pv /var/lib/mysqltmp<br />
$ chown mysql:mysql /var/lib/mysqltmp<br />
<br />
Find the id and gid of the "mysql" user and group:<br />
$ id mysql<br />
uid=27(mysql) gid=27(mysql) groups=27(mysql)<br />
<br />
Add to your {{ic|/etc/fstab}} file.<br />
tmpfs /var/lib/mysqltmp tmpfs rw,gid=27,uid=27,size=100m,mode=0750,noatime 0 0<br />
<br />
Add to your {{ic|/etc/mysql/my.cnf}} file under the "mysqld" group:<br />
tmpdir = /var/lib/mysqltmp<br />
<br />
Then reboot or ( shutdown mysql, mount the tmpdir, start mysql ).<br />
<br />
== Backup ==<br />
<br />
The database can be dumped to a file for easy backup. The following shell script will do this for you, creating a {{ic|db_backup.gz}} file in the same directory as the script, containing your database dump:<br />
<br />
{{bc|1=<br />
#!/bin/bash<br />
<br />
THISDIR=$(dirname $(readlink -f "$0"))<br />
<br />
mysqldump --single-transaction --flush-logs --master-data=2 --all-databases \<br />
<nowiki>| gzip > $THISDIR/db_backup.gz<br />
echo 'purge master logs before date_sub(now(), interval 7 day);' |</nowiki> mysql<br />
}}<br />
<br />
See also the official {{ic|mysqldump}} [http://dev.mysql.com/doc/refman/5.6/en/mysqldump.html page] in the MySQL manual.<br />
<br />
== Troubleshooting ==<br />
<br />
=== MySQL daemon cannot start ===<br />
<br />
If MySQL fails to start and there is no entry in the log files, you might want to check the permissions of files in the directories {{ic|/var/lib/mysql}} and {{ic|/var/lib/mysql/mysql}}. If the owner of files in these directories is not {{ic|mysql:mysql}}, you should do the following:<br />
# chown mysql:mysql /var/lib/mysql -R<br />
If you run into permission problems despite having followed the above, ensure that your {{ic|my.cnf}} is copied to {{ic|/etc/}}:<br />
# cp /etc/mysql/my.cnf /etc/my.cnf<br />
Now try and start the daemon.<br />
<br />
If you get these messages in your {{ic|/var/lib/mysql/hostname.err}}<br />
[ERROR] Can't start server : Bind on unix socket: Permission denied<br />
[ERROR] Do you already have another mysqld server running on socket: /var/run/mysqld/mysqld.sock ?<br />
[ERROR] Aborting<br />
The permissions of {{ic|/var/run/mysqld}} could be the culprit.<br />
# chown mysql:mysql /var/run/mysqld -R<br />
<br />
If you run mysqld and the following error appears:<br />
Fatal error: Can’t open and lock privilege tables: Table ‘mysql.host’ doesn’t exist<br />
Run the following command from the {{ic|/usr}} directory to install the default tables:<br />
# cd /usr<br />
# mysql_install_db --user=mysql --ldata=/var/lib/mysql/<br />
<br />
=== Unable to run mysql_upgrade because MySQL cannot start ===<br />
<br />
Try run MySQL in safemode:<br />
# mysqld_safe --datadir=/var/lib/mysql/<br />
And then run:<br />
# mysql_upgrade -u root -p<br />
<br />
=== Reset the root password ===<br />
<br />
Stop the ''mysqld'' [[daemon]]. Issue the following command:<br />
# mysqld_safe --skip-grant-tables &<br />
Connect to the mysql server. Issue the following command:<br />
# mysql -u root mysql<br />
Change root password:<br />
mysql> UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root';<br />
mysql> FLUSH PRIVILEGES;<br />
mysql> exit<br />
Start the ''mysqld'' daemon.<br />
<br />
=== Check and repair all tables ===<br />
<br />
Check and auto repair all tables in all databases, [http://dev.mysql.com/doc/refman/5.7/en/mysqlcheck.html see more]<br />
# mysqlcheck -A --auto-repair -u root -p<br />
<br />
=== Optimize all tables ===<br />
<br />
Forcefully Optimize all tables, automatically fixing table errors that may come up.<br />
# mysqlcheck -A --auto-repair -f -o -u root -p<br />
<br />
== See also ==<br />
<br />
* [[LAMP]] - Arch wiki article covering the setup of a LAMP server (Linux Apache MySQL PHP)<br />
* [[PhpMyAdmin]] - Arch wiki article covering the web-based tool to help manage MySQL databases using an Apache/PHP frontend.<br />
* [[PHP]] - Archi wiki article on PHP.<br />
<br />
== External links ==<br />
<br />
* [https://mariadb.org/ MariaDB Official Website]<br />
* [http://www.mysql.com/ Oracle MySQL Official Website]<br />
* [http://www.percona.com/software Percona Software for MySQL]<br />
* [http://www.askapache.com/mysql/performance-tuning-mysql.html MySQL Performance Tuning Scripts and Know-How]</div>Buergihttps://wiki.archlinux.org/index.php?title=Very_Secure_FTP_Daemon&diff=259009Very Secure FTP Daemon2013-05-26T19:43:11Z<p>Buergi: /* Configuration */ Add port config and iptables section (esp. ip_conntrack_ftp module)</p>
<hr />
<div>[[Category:File Transfer Protocol]]<br />
[[cs:Very Secure FTP Daemon]]<br />
[[es:Very Secure FTP Daemon]]<br />
[[it:Very Secure FTP Daemon]]<br />
[[ru:Very Secure FTP Daemon]]<br />
[[zh-CN:Very Secure FTP Daemon]]<br />
'''vsftpd''' (Very Secure FTP Daemon) is a lightweight, stable and secure FTP server for UNIX-like systems.<br />
<br />
== Installation ==<br />
Simply install {{pkg|vsftpd}} from the [[Official Repositories]].<br />
<br />
To start the server:<br />
# systemctl start vsftpd.service<br />
<br />
If you want it to be started automatically at boot:<br />
# systemctl enable vsftpd.service<br />
<br />
See the xinetd section below for procedures to use vsftpd with xinetd.<br />
<br />
== Configuration ==<br />
Most of the settings in vsftpd are done by editing the file {{ic|/etc/vsftpd.conf}}. The file itself is well-documented, so this section only highlights some important changes you may want to modify. For all available options and documentation, one can man vsftpd.conf (5). Files are served by default from {{ic|/srv/ftp}}.<br />
<br />
=== Enabling uploading ===<br />
The {{Ic|WRITE_ENABLE}} flag must be set to YES in {{ic|/etc/vsftpd.conf}} in order to allow changes to the filesystem, such as uploading:<br />
write_enable=YES<br />
<br />
=== Local user login ===<br />
One must set the line to {{ic|/etc/vsftpd.conf}} to allow users in {{ic|/etc/passwd}} to login:<br />
local_enable=YES<br />
<br />
=== Anonymous login ===<br />
The line in {{ic|/etc/vsftpd.conf}} controls whether anonymous users can login:<br />
anonymous_enable=YES # Allow anonymous login<br />
no_anon_password=YES # No password is required for an anonymous login<br />
anon_max_rate=30000 # Maximum transfer rate for an anonymous client in Bytes/second<br />
anon_root=/example/directory/ # Directory to be used for an anonymous login<br />
<br />
=== Chroot jail ===<br />
One can set up a chroot environment which prevents the user from leaving its home directory. To enable this, add the following lines to {{ic|/etc/vsftpd.conf}}:<br />
chroot_list_enable=YES<br />
chroot_list_file=/etc/vsftpd.chroot_list<br />
The {{Ic|chroot_list_file}} variable specifies the file which contains users that are jailed.<br />
<br />
For a more restricted environment, one can specify the line:<br />
chroot_local_user=YES<br />
This will make local users jailed by default. In this case, the file specified by {{Ic|chroot_list_file}} lists users that are '''not''' in a chroot jail.<br />
<br />
=== Limiting user login ===<br />
It's possible to prevent users from logging into the FTP server by adding two lines to {{ic|/etc/vsftpd.conf}}:<br />
userlist_enable=YES<br />
userlist_file=/etc/vsftpd.user_list<br />
{{Ic|userlist_file}} now specifies the file which lists users that are not able to login.<br />
<br />
If you only want to allow certain users to login, add the line:<br />
userlist_deny=NO<br />
The file specified by {{Ic|userlist_file}} will now contain users that are able to login.<br />
<br />
=== Limiting connections ===<br />
One can limit the data transfer rate, number of clients and connections per IP for local users by adding the information in {{ic|/etc/vsftpd.conf}}:<br />
local_max_rate=1000000 # Maximum data transfer rate in bytes per second<br />
max_clients=50 # Maximum number of clients that may be connected<br />
max_per_ip=2 # Maximum connections per IP<br />
<br />
=== Using xinetd ===<br />
{{Out of date|Contains reference to rc.conf, which does not exist anymore.}}<br />
If you want to use vsftpd with xinetd, add the following lines to {{ic|/etc/xinetd.d/vsftpd}}:<br />
<pre><br />
service ftp<br />
{<br />
socket_type = stream<br />
wait = no<br />
user = root<br />
server = /usr/sbin/vsftpd<br />
log_on_success += HOST DURATION<br />
log_on_failure += HOST<br />
disable = no<br />
}<br />
</pre><br />
<br />
The option below should be set in {{ic|/etc/vsftpd.conf}}:<br />
pam_service_name=ftp<br />
<br />
Finally, add xinetd to your daemons line in {{ic|/etc/rc.conf}}. You do not need to add vsftpd, as it will be called by xinetd whenever necessary.<br />
<br />
If you get errors like this while connecting to the server:<br />
500 OOPS: cap_set_proc<br />
You need to add ''capability'' in MODULES= line in {{ic|/etc/rc.conf}}.<br />
<br />
While upgrading to version 2.1.0 you might get an error like this when connecting to the server from a client:<br />
500 OOPS: could not bind listening IPv4 socket<br />
In earlier versions it has been enough to leave the following lines commented:<br />
# Use this to use vsftpd in standalone mode, otherwise it runs through (x)inetd<br />
# listen=YES<br />
In this newer version, and maybe future releases, it is necessary however to explicitly configure it to '''not''' run in a standalone mode, like this:<br />
# Use this to use vsftpd in standalone mode, otherwise it runs through (x)inetd<br />
listen=NO<br />
<br />
=== Using SSL to Secure FTP ===<br />
<br />
Generate an SSL Cert, e.g. like that: <br />
# cd /etc/ssl/certs<br />
# openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/ssl/certs/vsftpd.pem -out /etc/ssl/certs/vsftpd.pem<br />
# chmod 600 /etc/ssl/certs/vsftpd.pem<br />
You will be asked a lot of Questions about your Company etc., as your Certificate is not a trusted one it doesn't really matter what you fill in. You will use this for encryption! If you plan to use this in a matter of trust get one from a CA like thawte, verisign etc. <br />
<br />
edit your configuration {{ic|/etc/vsftpd.conf}}<br />
<pre><br />
#this is important<br />
ssl_enable=YES<br />
<br />
#choose what you like, if you accept anon-connections<br />
# you may want to enable this<br />
# allow_anon_ssl=NO<br />
<br />
#choose what you like,<br />
# it's a matter of performance i guess<br />
# force_local_data_ssl=NO<br />
<br />
#choose what you like<br />
force_local_logins_ssl=YES<br />
<br />
#you should at least enable this if you enable ssl...<br />
ssl_tlsv1=YES<br />
#choose what you like<br />
ssl_sslv2=YES<br />
#choose what you like<br />
ssl_sslv3=YES<br />
#give the correct path to your currently generated *.pem file<br />
rsa_cert_file=/etc/ssl/certs/vsftpd.pem<br />
#the *.pem file contains both the key and cert<br />
rsa_private_key_file=/etc/ssl/certs/vsftpd.pem<br />
</pre><br />
<br />
=== Dynamic DNS ===<br />
Make sure you put the following two lines in {{ic|/etc/vsftpd.conf}}:<br />
pasv_addr_resolve=YES<br />
pasv_address=yourdomain.noip.info<br />
It is '''not''' necessary to use a script that updates pasv_address periodically and restarts the server, as it can be found elsewhere!<br />
{{Note|You won't be able to connect in passive mode via LAN anymore. Try the active mode on your LAN PC's FTP client.}}<br />
<br />
<br />
=== Port configurations ===<br />
Especially for private FTP servers that are exposed to the web it's recommended to change the listening port to something other that the standard port 21. This can be done using the following lines in {{ic|/etc/vsftpd.conf}}:<br />
listen_port=2211<br />
Furthermore a custom passive port range can be given by:<br />
pasv_min_port=49152<br />
pasv_max_port=65534<br />
<br />
=== Configuring iptables ===<br />
Often the server running the FTP daemon is protected by an [[iptables]] firewall. To allow access to the FTP server the corresponding port needs to be opened using something like<br />
# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 2211 -j ACCEPT<br />
This article won't provide any guide how to set up iptables, check out for example [[Simple stateful firewall]].<br />
<br />
However, there are some kernel modules needed for proper FTP connection handling by iptables that should be referenced here. Among those especially ''ip_conntrack_ftp''. It is needed as FTP uses the given ''listen_port'' (21 by default) for commands only. All the data transfer is done over some different ports, which are chosen randomly by the FTP daemon for each session (also depending if active or passive mode is used). To tell iptables that packets on those specific, randomly chosen ports should also accepted ''ip_conntrack_ftp'' is required. To load it automatically on boot create a new file in {{ic|/etc/modules-load.d}} e.g.:<br />
# echo ip_conntrack_ftp > /etc/modules-load.d/ip_conntrack_ftp.conf<br />
<br />
If you changed the ''listen_port'' you also need to configure the conntrack module correspondingly:<br />
{{hc|/etc/modprobe.d/ip_conntrack_ftp.conf|<nowiki><br />
options nf_conntrack_ftp ports=2211<br />
options ip_conntrack_ftp ports=2211</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
=== PAM with virtual users ===<br />
Using virtual users has the advantage of not requiring a real login account on the system. Keeping the environment in a container is of course a more secure option.<br />
<br />
A virtual users database has to be created by first making a simple text file like this:<br />
user1<br />
password1<br />
user2<br />
password2<br />
Include as many virtual users as you wish according to the structure in the example. Save it as logins.txt; the file name does not have any significance. Next step depends on Berkeley database system, which is included in the core system of Arch. As root create the actual database with the help of the logins.txt file, or what you chose to call it:<br />
# db_load -T -t hash -f logins.txt /etc/vsftpd_login.db<br />
It is recommended to restrict permissions for the now created {{ic|vsftpd_login.db}} file:<br />
# chmod 600 /etc/vsftpd_login.db<br />
{{Warning|Be aware that stocking passwords in plain text is not safe. Don't forget to remove your temporary file with {{Ic|rm logins.txt}}.}}<br />
PAM should now be set to make use of vsftpd_login.db. To make PAM check for user authentication create a file named ftp in the {{ic|/etc/pam.d/}} directory with the following information:<br />
auth required pam_userdb.so db=/etc/vsftpd_login crypt=hash <br />
account required pam_userdb.so db=/etc/vsftpd_login crypt=hash<br />
{{Note|We use /etc/vsftpd_login without .db extension in PAM-config!}}<br />
Now it is time to create a home for the virtual users. In the example {{ic|/srv/ftp}} is decided to host data for virtual users, which also reflects the default directory structure of Arch. First create the general user virtual and make {{ic|/srv/ftp}} its home:<br />
# useradd -d /srv/ftp virtual<br />
Make virtual the owner:<br />
# chown virtual:virtual /srv/ftp<br />
Configure vsftpd to use the created environment by editing {{ic|/etc/vsftpd.conf}}. These are the necessary settings to make vsftpd restrict access to virtual users, by user-name and password, and restrict their access to the specified area {{ic|/srv/ftp}}:<br />
anonymous_enable=NO<br />
local_enable=YES<br />
chroot_local_user=YES<br />
guest_enable=YES<br />
guest_username=virtual<br />
virtual_use_local_privs=YES<br />
If the xinetd method is used start the service. You should now only be allowed to login by user-name and password according to the made database.<br />
<br />
==== Adding private folders for the virtual users ====<br />
First create directories for users:<br />
# mkdir /srv/ftp/user1<br />
# mkdir /srv/ftp/user2<br />
# chown virtual:virtual /srv/ftp/user?/<br />
<br />
Then, add the following lines to {{ic|/etc/vsftpd.conf}}:<br />
local_root=/srv/ftp/$USER<br />
user_sub_token=$USER<br />
<br />
== Troubleshooting ==<br />
<br />
=== vsftpd: refusing to run with writable root inside chroot() ===<br />
As of vsftpd 2.3.5, the chroot directory that users are locked to must not be writable. This is in order to prevent a security vulnerabilty.<br />
To do this:<br />
# chmod a-w /home/user<br />
<br />
Workaround:<br />
You can put this into your {{ic|/etc/vsftpd.conf}} to workaround this security enhancement (since vsftpd 3.0.0; from [http://www.benscobie.com/fixing-500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/ Fixing 500 OOPS: vsftpd: refusing to run with writable root inside chroot ()]):<br />
allow_writeable_chroot=YES<br />
or alternative:<br />
<br />
Install vsftpd-ext from AUR and set in the conf file allow_writable_root=YES<br />
<br />
=== FileZilla Client: GnuTLS error -8 when connecting via SSL ===<br />
vsftpd tries to display plain-text error messages in the SSL session. In order to debug this, temporarily disable encryption and you will see the correct error message.[http://ramblings.linkerror.com/?p=45]<br />
<br />
== See also ==<br />
* [http://vsftpd.beasts.org/ vsftpd official homepage]<br />
* [http://vsftpd.beasts.org/vsftpd_conf.html vsftpd.conf man page]</div>Buergihttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_from_existing_Linux&diff=247565Install Arch Linux from existing Linux2013-02-16T17:00:52Z<p>Buergi: readd Direct Bootstrapping, @Danielwallace pls don't remove a section without correcting the references (1. method etc.), direct bootstrapping is the quickest and most memory efficient way and absolute crucial for installation on remote hosts</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[de:Schnellinstallation von einem bestehenden Linuxsystem]]<br />
[[es:Install from Existing Linux]]<br />
[[fr:Install chroot]]<br />
[[it:Install from Existing Linux]]<br />
[[ru:Install from Existing Linux]]<br />
[[uk:Install from Existing Linux]]<br />
[[zh-CN:Install from Existing Linux]]<br />
[[zh-TW:Install from Existing Linux]]<br />
This guide is intended for anybody who wants to install Arch Linux from any other running Linux -- be it off a LiveCD or a pre-existing install of a different distro.<br />
<br />
This is useful for:<br />
* remotely installing Archlinux (e.g. a (virtual) root server)<br />
* creating a new linux distribution or LiveCD based on Archlinux<br />
* creating an Archlinux chroot environments<br />
* [[Diskless_network_boot_NFS_root|rootfs-over-NFS for diskless machines]]<br />
<br />
This guide requires that the existing host system be able to execute the new target Arch Linux architecture programs. In the case of an x86_64 host, it is possible to use i686-pacman to build a 32-bit chroot environment. See [[Arch64 Install bundled 32bit system]]. However it is not so easy to build a 64-bit environment when the host only supports running 32-bit programs.<br />
<br />
{{Note|If you are already using Arch, instead of following this guide, just install {{Pkg|arch-install-scripts}} from the [[Official Repositories|official repositories]] and follow the [[Installation Guide]]}}<br />
<br />
'''This guide provides additional steps to the [[Installation Guide]]. The steps of that guide must still be followed as needed.'''<br />
<br />
==Prepare the system==<br />
<br />
Follow the [[Installation Guide]] steps, until you have your partitions, keyboard and internet connection ready.<br />
<br />
==Setup the environment for pacman==<br />
<br />
You need to create an environment where ''pacman'' and the ''arch install scripts'' can run on your current linux distro. (If you choose the Method 2, only pacman is necessary)<br />
<br />
There are in principle two different methods to prepare that environment: either by '''installing pacman natively (Method 4 below)''' on your linux distro or by setting up a '''chroot environment'''.<br />
The latter way will generally be easier and is discussed next:<br />
<br />
There are two possible ways of using the ''chroot'' method:<br />
* '''Using chroot as an installation environment''': The prepared Archlinux chroot environment will be used temporarily to set up the actual Archlinux installation using the ''arch-install-scripts''. This is a bit more work and takes longer but once you set up the installation system you can quickly install several Archlinux systems. '''However''', if you want to set up only a single Archlinux this might be overkill. You are actually setting up the system twice, have a lot more network traffic and especially need a lot more RAM and disk space, mostly due to the quite big iso image.<br />
<br />
* '''Installing Archlinux directly/Direct Bootstrapping''': Thanks to tokland's ''arch-bootstrap'' script this method is effectively a one-liner and very fast. After that one line of code your Archlinux base system is installed to disk. '''However''', if setting up multiple copies of Archlinux, this method requires the re-downloading of the base packages every time, so is slower.<br />
<br />
The best advice is probably to use '''Direct bootstrapping''' to set up only a small number of systems. If you set up many Archlinux systems the '''chroot install environment''' or even the '''native pacman''' installation might suit you better.<br />
<br />
===Method 1: Chroot into LiveCD-image===<br />
<br />
It is possible to mount the root image of the latest Archlinux installation media and then chroot into it. This method has the advantage of providing you with a working Arch Linux installation right within your host system without the need to prepare it by installing specific packages.<br />
<br />
{{Note|Before proceeding, make sure the latest version of {{Pkg|squashfs-tools}} is installed on the host system. Otherwise you will get errors like: {{ic|FATAL ERROR aborting: uncompress_inode_table: failed to read block}}.}}<br />
<br />
* Download the lastest installation CD image from https://www.archlinux.org/download/<br />
<br />
* Mount the Live CD image:<br />
{{bc|# mount -o loop archlinux-{date}-dual.iso /mnt}}<br />
<br />
* The root image exists in [[Wikipedia:Squashfs|squashfs format]] on the Live CD. The squashfs format is not editable as such. Hence, we unsquash the root image and then mount it.<br />
<br />
To unsquash the x86_64 (or i686 respectively) root image, run<br />
{{bc|# unsquashfs -d /squashfs-root /mnt/arch/x86_64/root-image.fs.sfs}}<br />
<br />
* Now you can unmount and remove the iso image<br />
{{bc|<br />
# umount /mnt<br />
# rm archlinux-{date}-dual.iso<br />
}}<br />
<br />
* Now you can loop mount the root image<br />
{{bc|# mount -o loop /squashfs-root/root-image.fs /arch}}<br />
<br />
* Before [[Change Root|chrooting]] to it, we need to set up some mount points.<br />
{{bc|<br />
# mount -t proc none /arch/proc<br />
# mount -t sysfs none /arch/sys<br />
# mount -o bind /dev /arch/dev<br />
# mount -o bind /dev/pts /arch/dev/pts # important for pacman (for signature check)<br />
}}<br />
<br />
* Now everything is prepared to chroot into your newly installed Arch environment<br />
{{bc|# chroot /arch bash}}<br />
<br />
This chroot is able to execute the arch install scripts. The destination partitions should be mounted under the {{ic|/mnt}} directory from this chroot.<br />
<br />
===Method 2: Direct bootstrapping Archlinux===<br />
<br />
This method will install a basic Archlinux system directly onto your previously prepared root file system mounted as {{ic|/mnt}}. This is known as [http://en.wikipedia.org/wiki/Bootstrapping#Computing bootstrapping] and is definitely the '''quickest way''' to install a single Archlinux system from a foreign distribution. Moreover, it is less disk consuming as method 1 as it does not require to download the whole Archlinux installation image. Therefore bootstrapping is the method of choice for installing Archlinux on a '''remote host''', such as a virtual root server using some arbitrary GNU/Linux-based rescue environment.<br />
<br />
As described in the [[Installation Guide]] we assume your disk which should become your root device is mountet at {{ic|/mnt}}. At first grab ''tokland's'' ''arch-bootstrap'' script, c.f. [[Archbootstrap]],<br />
<br />
# cd /tmp<br />
# wget http://tokland.googlecode.com/svn/trunk/archlinux/arch-bootstrap.sh<br />
# chmod +x arch-bootstrap.sh<br />
<br />
This script will bootstrap a basic archlinux system, i.e., it will download the linux kernel, pacman basic tools like bash and all needed dependencies and unpack them to the given directory, in this case {{ic|/mnt}}. <br />
<br />
If you are wanting to install a 32-bit system:<br />
# ./arch-bootstrap.sh -a i686 -r "ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org" /mnt/<br />
Or a 64-bit system:<br />
# ./arch-bootstrap.sh -a x86_64 -r "ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org" /mnt/<br />
<br />
The bootstrapping will take 2-5 minutes depending on the speed of your system.<br />
<br />
If the architecture of the foreign distribution is not the same as the one of the newly bootstrapped system you might have to change the architecture in {{ic|/etc/pacman.conf}}.<br />
<br />
If your bootstrapped system is 32-bit system:<br />
Architecture = i686<br />
Or for a 64-bit system:<br />
Architecture = x86_64<br />
<br />
Before chrooting into the newly created system we need to set up some mount points.<br />
This is essential for the installation of a bootloader later on, c.f. [[Change Root]].<br />
# mount -t proc none /mnt/proc<br />
# mount -t sysfs none /mnt/sys<br />
# mount -o bind /dev /mnt/dev<br />
# mount -o bind /dev/pts /mnt/dev/pts # important for pacman (for signature check)<br />
<br />
Now everything is prepared to chroot into your newly installed Arch environment<br />
# chroot /mnt bash<br />
<br />
Before you can use ''pacman'' you have to initialize its keyring as explained below, in [[#Fix the Pacman Signature Keyring]].<br />
<br />
From here on proceed with [[Installation Guide#Install the base system]], '''but''' remember, you are already working in your final system, thus no need for {{ic|pacstrap}}, simply use {{ic|pacman}}. So the next command you are most likely to execute will be<br />
<br />
# pacman -S base # and evtl. also base-devel<br />
<br />
''Credit goes to [https://github.com/tokland Arnau Sanchez] alias tokland, the author of the arch-bootstrap script.''<br />
<br />
===Method 3: Bootstrapping the arch installation scripts===<br />
<br />
Contrary to the other methods, '''this method is one-step only'''; you only have to execute the script below and thats it.<br />
<br />
This method can be considered an hybrid between Method 1 and Method 2. It provides a chroot enviroment from where to execute the arch install scripts (similar to Method 1), by using a bootstrapping script (similar to Method 2).<br />
<br />
The script below is going to create a directory called {{ic|archinstall-pkg}} and download the required packages there. Then, is going to extract them into the {{ic|archinstall-chroot}} directory. Finally, is going to prepare mount points, configure pacman and enter into a chroot.<br />
{{Note|This is '''only''' an enviroment to execute the arch install scripts: '''this is not your final installation'''. }}<br />
<br />
This chroot is able to execute the arch install scripts. '''The destination partitions should be mounted under the {{ic|/mnt}} directory from this chroot'''. After that, continue with the next step, which is [[#Fix the Pacman Signature Keyring]].<br />
<br />
'''CHROOT_DIR=archinstall-chroot Must Change First, or you might ruin your /etc/'''<br />
<br />
{{hc|archinstall-bootstrap.sh|<nowiki><br />
#!/bin/bash<br />
# This script is inspired on the archbootstrap script.<br />
<br />
PACKAGES=(acl attr bzip2 curl expat glibc gpgme libarchive libassuan libgpg-error libssh2 openssl pacman xz zlib pacman-mirrorlist coreutils bash grep gawk file tar ncurses readline libcap util-linux pcre arch-install-scripts)<br />
# Change the mirror as necessary<br />
MIRROR='http://mirrors.kernel.org/archlinux' <br />
# You can set the ARCH variable to i686 or x86_64<br />
ARCH=`uname -m`<br />
LIST=`mktemp`<br />
CHROOT_DIR=archinstall-chroot<br />
DIR=archinstall-pkg<br />
mkdir -p "$DIR"<br />
mkdir -p "$CHROOT_DIR"<br />
# Create a list with urls for the arch packages<br />
for REPO in core community extra; do <br />
wget -q -O- "$MIRROR/$REPO/os/$ARCH/" |sed -n "s|.*href=\"\\([^\"]*\\).*|$MIRROR\\/$REPO\\/os\\/$ARCH\\/\\1|p"|grep -v 'sig$'|uniq >> $LIST <br />
done<br />
# Download and extract each package.<br />
for PACKAGE in ${PACKAGES[*]}; do<br />
URL=`grep "$PACKAGE-[0-9]" $LIST|head -n1`<br />
FILE=`echo $URL|sed 's/.*\/\([^\/][^\/]*\)$/\1/'`<br />
wget "$URL" -c -O "$DIR/$FILE" <br />
xz -dc "$DIR/$FILE" | tar x -k -C "$CHROOT_DIR"<br />
done<br />
# Create mount points<br />
mkdir -p "$CHROOT_DIR/dev" "$CHROOT_DIR/proc" "$CHROOT_DIR/sys" "$CHROOT_DIR/mnt"<br />
mount -t proc proc "$CHROOT_DIR/proc/"<br />
mount -t sysfs sys "$CHROOT_DIR/sys/"<br />
mount -o bind /dev "$CHROOT_DIR/dev/"<br />
mkdir -p "$CHROOT_DIR/dev/pts"<br />
mount -t devpts pts "$CHROOT_DIR/dev/pts/"<br />
<br />
# Hash for empty password Created by doing: openssl passwd -1 -salt ihlrowCo and entering an empty password (just press enter)<br />
echo 'root:$1$ihlrowCo$sF0HjA9E8up9DYs258uDQ0:10063:0:99999:7:::' > "$CHROOT_DIR/etc/shadow"<br />
echo "root:x:0:0:root:/root:/bin/bash" > "$CHROOT_DIR/etc/passwd" <br />
touch "$CHROOT_DIR/etc/group"<br />
echo "myhost" > "$CHROOT_DIR/etc/hostname"<br />
test -e "$CHROOT_DIR/etc/mtab" || echo "rootfs / rootfs rw 0 0" > "$CHROOT_DIR/etc/mtab"<br />
[ -f "/etc/resolv.conf" ] && cp "/etc/resolv.conf" "$CHROOT_DIR/etc/"<br />
sed -ni '/^[ \t]*CheckSpace/ !p' "$CHROOT_DIR/etc/pacman.conf"<br />
sed -i "s/^[ \t]*SigLevel[ \t].*/SigLevel = Never/" "$CHROOT_DIR/etc/pacman.conf"<br />
echo "Server = $MIRROR/\$repo/os/$ARCH" >> "$CHROOT_DIR/etc/pacman.d/mirrorlist"<br />
<br />
chroot $CHROOT_DIR /usr/bin/pacman -Sy <br />
chroot $CHROOT_DIR /bin/bash<br />
</nowiki>}}<br />
<br />
===Method 4: Install pacman natively on non-arch distro (advanced)===<br />
{{Warning|This method is potentially difficult, your mileage may vary from distro to distro. If you just want to do an arch installation from another distro and you are not interested in have pacman as a regular program under such distro, is better to use a different method.}}<br />
<br />
This method is about installing pacman and the arch install scripts directly under another distro, so they become regular programs on that distro.<br />
<br />
This is really useful if you are planning to use another distro regularly to install arch linux, or do fancy things like updating packages of an arch installation using another distro. This is the only method that not imply creating a chroot to be able to execute pacman and the arch install scripts. (but since part of the installation includes entering inside a chroot, you'll end using a chroot anyway)<br />
<br />
==== Download pacman source code and pacman packages ====<br />
Visit the pacman homepage: https://www.archlinux.org/pacman/#_releases and download the latest release.<br />
<br />
Now, download the following packages:<br />
<br />
* pacman-mirrorlist: https://www.archlinux.org/packages/core/any/pacman-mirrorlist/download/<br />
* arch-install-scripts: https://www.archlinux.org/packages/extra/any/arch-install-scripts/download/<br />
* pacman (necessary for the config files): https://www.archlinux.org/packages/core/x86_64/pacman/download/ (change x86_64 as necessary)<br />
<br />
==== Install dependencies ====<br />
Using your distribution mechanisms, install the required packages for pacman and the arch install scripts. libcurl, libarchive, fakeroot, xz, asciidoc, wget, and sed are among them. Of course, gcc, make and maybe some other "devel" packages are necessary too.<br />
<br />
==== Compile pacman ====<br />
<br />
* Decompress the pacman source code and cd inside.<br />
* Execute configure, adapting the paths as necessary: {{bc|<nowiki> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-doc</nowiki>}}<br />
If you get errors here, chances are you are missing dependencies, or your current libcurl, libarchive or others, are too old. Install the dependencies missing using your distro options, or if they are too old, compile them from source.<br />
* Compile {{bc|make}}<br />
* If there were no errors, install the files {{bc|make install}}<br />
* You may need to manually call {{ic|ldconfig}} to make your distro detect libalpm.<br />
==== Prepare configuration files ====<br />
Now is time to extract the configuration files. Change the x86_64 as necessary.<br />
* Extract the pacman.conf and makepkg.conf files from the pacman package, and disable signature checking: {{bc|<nowiki>tar xJvf pacman-*-x86_64.pkg.tar.xz etc -C / ; sed -i 's/SigLevel.*/SigLevel = Never/g' /etc/pacman.conf</nowiki>}}<br />
* Extract the mirror list: {{bc|tar xJvf pacman-mirrorlist-*-any.pkg.tar.xz -C /}}<br />
* Enable some mirrors on {{ic|/etc/pacman.d/mirrorlist}}<br />
* Extract the arch-install-scripts {{bc|tar xJvf arch-install-scripts-*-any.pkg.tar.xz -C /}}<br />
<br />
Another option is using the {{ic|alien}} tool to convert the {{ic|pacman-mirrorlist}} and {{ic|arch-install-scripts}} (but no {{ic|pacman}}) to native packages of your distro.<br />
<br />
==Fix the Pacman Signature Keyring==<br />
<br />
It is necessary to initialize ''pacman's'' keyring for signature checking.<br />
<br />
This is done using<br />
# pacman-key --init # read the note below!<br />
# pacman-key --populate archlinux<br />
<br />
'''However''', when connected via SSH you might run out of [http://en.wikipedia.org/wiki/Entropy_(computing) entropy]. In this case you can try something like<br />
<br />
# cat /usr/bin/* > /dev/null &<br />
# find / > /dev/null &<br />
<br />
before executing {{ic|pacman-key --init}}.<br />
<br />
It might take some time. If nevertheless all this does help install {{Pkg|haveged}} and run prior to {{ic|pacman-key --init}}<br />
# /usr/sbin/haveged -w 1024 -v 1<br />
<br />
<br />
==Setup the target system==<br />
<br />
At this point, follow the normal steps of [[Installation Guide]]. Remember to mount the destination partition under the {{ic|/mnt}} of the chroot.<br />
<br />
# pacstrap /mnt base base-devel<br />
# # ...<br />
<br />
===Edit the fstab file===<br />
<br />
Probably the {{ic|genfstab}} script won't work. In that case, you'll need to edit the {{ic|/mnt/etc/fstab}} file by hand.<br />
You can use the content of {{ic|/etc/mtab}} as reference.<br />
<br />
===Finish the Installation===<br />
Now just do the rest of the steps normally.<br />
<br />
==Tips and tricks==<br />
* In case you want to replace an existing system, but can for some reason not use a LiveCD, since, e.g., you have no physical access to the computer, the following tip might help: If you manage to get ~500MB of free space somewhere on the disk (e.g. by partitioning a swap partition) you can install the new Archlinux system there, reboot into the newly created system and [[Full_System_Backup_with_rsync#With_a_single_command|rsync the entire system]] to the primary partition. Finally don't forget to fix the bootloader configuration before rebooting.</div>Buergihttps://wiki.archlinux.org/index.php?title=Lighttpd&diff=242180Lighttpd2012-12-29T16:02:12Z<p>Buergi: merge code blocks</p>
<hr />
<div>[[cs:Lighttpd]]<br />
[[de:Lighttpd]]<br />
[[es:Lighttpd]]<br />
[[ru:Lighttpd]]<br />
[[zh-CN:Lighttpd]]<br />
[[zh-TW:Lighttpd]]<br />
[[Category:Web Server]]<br />
<br />
[http://www.lighttpd.net/ Lighttpd] is "a secure, fast, compliant, and very flexible [[Wikipedia:Web server|web-server]] that has been optimized for high-performance environments. It has a very low memory footprint compared to other webservers and takes care of cpu-load. Its advanced feature-set ([[Wikipedia:FastCGI|FastCGI]], [[Wikipedia:Common Gateway Interface|CGI]], Auth, Output-Compression, URL-Rewriting and many more) make lighttpd the perfect webserver-software for every server that suffers load problems."<br />
<br />
==Installation==<br />
Install the {{pkg|lighttpd}} package from the official repositories.<br />
<br />
==Configuration==<br />
===Basic Setup===<br />
The lighttpd configuration file is: {{ic|/etc/lighttpd/lighttpd.conf}}. By default it should produce a working test page. <br />
<br />
To check your {{ic|lighttpd.conf}} for bugs you can use this command - helps finding misconfigurations very fast:<br />
<br />
$ lighttpd -t -f /etc/lighttpd/lighttpd.conf<br />
<br />
The default configuration file specifies {{ic|/srv/http/}} as the document directory served.<br />
<br />
It may be necessary to add a user and group for {{ic|http}} if you do not already have one. That user needs to have write permissions to {{ic|/var/log/lighttpd}} as well, so we will make it the owner of the folder:<br />
# groupadd http<br />
# adduser http<br />
# chown -R http /var/log/lighttpd<br />
<br />
To test the install:<br />
# echo 'TestMe!' >> /srv/http/index.html<br />
# chmod 755 /srv/http/index.html<br />
<br />
To start the server:<br />
# systemctl start lighttpd<br />
<br />
Then point your browser to {{ic|localhost}}, and you should see the test page.<br />
<br />
To start the server on every boot:<br />
<br />
# systemctl enable lighttpd<br />
<br />
Example configuration files are available in {{ic|/usr/share/doc/lighttpd/}}.<br />
<br />
===FastCGI===<br />
<br />
Install {{pkg|fcgi}}.<br />
Now you have lighttpd with fcgi support. If it was that what you wanted you are all set. People that want Ruby on Rails, PHP or Python should continue.<br />
{{Box Note | New default user and group: Instead of group "nobody" lighttpd now runs as user/group "http" by default.}}<br />
<br />
First copy the example config file form {{ic|/usr/share/doc/lighttpd/config/conf.d/fastcgi.conf}} to {{ic|/etc/lighttpd/conf.d}}<br />
<br />
The following needs adding to the config file, {{ic|/etc/lighttpd/conf.d/fastcgi.conf}}<br />
server.modules += ( "mod_fastcgi" )<br />
<br />
#server.indexfiles += ( "dispatch.fcgi" ) #this is deprecated<br />
index-file.names += ( "dispatch.fcgi" ) #dispatch.fcgi if rails specified<br />
<br />
server.error-handler-404 = "/dispatch.fcgi" #too<br />
fastcgi.server = (<br />
".fcgi" => (<br />
"localhost" => ( <br />
"socket" => "/run/lighttpd/rails-fastcgi.sock",<br />
"bin-path" => "/path/to/rails/application/public/dispatch.fcgi"<br />
)<br />
)<br />
)<br />
<br />
Then in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
include "conf.d/fastcgi.conf"<br />
<br />
For PHP or Ruby on Rails see the next sections.<br />
<br />
====PHP====<br />
<br />
Install {{pkg|php}} and {{pkg|php-cgi}} (see also [[PHP]] and [[LAMP]]).<br />
<br />
Check that php-cgi is working {{Ic|php-cgi --version}}<br />
<br />
PHP 5.4.3 (cgi-fcgi) (built: May 8 2012 17:10:17)<br />
Copyright (c) 1997-2012 The PHP Group<br />
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies<br />
<br />
If you get a similar output then php is installed correctly.<br />
<br />
{{Note|Please keep in mind if you receive errors like ''No input file found'' after attempting to access your php files then make sure {{ic|/etc/php/php.ini}} has the directives enabled:}}<br />
cgi.fix_pathinfo=1<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/another/path:/second/path<br />
And that the files are world readable, <br />
# chmod -R 755<br />
<br />
In {{ic|/etc/lighttpd/conf.d/fastcgi.conf}} add:<br />
server.modules += ( "mod_fastcgi" )<br />
<br />
#server.indexfiles += ( "index.php" ) #this is deprecated<br />
index-file.names += ( "index.php" )<br />
<br />
fastcgi.server = (<br />
".php" => (<br />
"localhost" => ( <br />
"bin-path" => "/usr/bin/php-cgi",<br />
"socket" => "/run/lighttpd/php-fastcgi.sock",<br />
"max-procs" => 4, # default value<br />
"bin-environment" => (<br />
"PHP_FCGI_CHILDREN" => "1", # default value<br />
),<br />
"broken-scriptfilename" => "enable"<br />
))<br />
)<br />
<br />
Then in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
include "conf.d/fastcgi.conf"<br />
<br />
Finally reload the configuration<br />
# systemctl reload lighttpd<br />
<br />
===== Using php-fpm =====<br />
<br />
There is no adaptive spawning anymore in recent lighttpd releases. For dynamic management of PHP processes, you can use {{Pkg|php-fpm}}.<br />
# pacman -S php-fpm<br />
# rc.d start php-fpm<br />
{{Note|You can configure the number of servers in the pool and tweak other configuration options by editing the file {{ic|/etc/php/php-fpm.conf}}. More details on ''php-fpm'' can be found on the [http://php-fpm.anight.org/ php-fpm website]. You should also note that when you make changes to /etc/php/php.ini you will need to restart php-fpm}}<br />
<br />
In {{ic|/etc/lighttpd/conf.d/fastcgi.conf}} add:<br />
server.modules += ( "mod_fastcgi" )<br />
<br />
index-file.names += ( "index.php" ) <br />
<br />
fastcgi.server = (<br />
".php" => (<br />
"localhost" => ( <br />
"socket" => "/run/php-fpm/php-fpm.sock",<br />
"broken-scriptfilename" => "enable"<br />
))<br />
)<br />
<br />
===== eAccelerator =====<br />
<br />
Install {{AUR|eaccelerator}} from the [[Arch User Repository|AUR]].<br />
<br />
Add own config file for eaccelerator:<br />
<br />
{{hc|/etc/php/conf.d/eaccelerator-own.ini|2=<br />
zlib.output_compression = On<br />
cgi.fix_pathinfo=1<br />
eaccelerator.cache_dir="/home/phpuser/eaccelerator/cache"<br />
}}<br />
<br />
{{Tip|I additionally set {{ic|safe_mod}} to {{ic|On}} in my setup, but this is not required.}}<br />
<br />
===== Try a php page =====<br />
Create the following php page, name it index.php, and place a copy in both /srv/http/ and /srv/http-ssl/html/<br />
<?php<br />
phpinfo();<br />
?><br />
Try navigating with a web browser to both the http and https address of your server. You should see the phpinfo page.<br />
<br />
Check eaccelerator caching:<br />
# ls -l /home/phpuser/eaccelerator/cache<br />
<br />
If the above command outputs the following:<br />
-rw------- 1 phpuser phpuser 456 2005-05-05 14:53 eaccelerator-277.58081<br />
-rw------- 1 phpuser phpuser 452 2005-05-05 14:53 eaccelerator-277.88081<br />
Then eaccelerator is happily caching your php scripts to help speed things up.<br />
<br />
====Ruby on Rails====<br />
Install and configure FastCGI (see [[#FastCGI]] above).<br />
<br />
Install [[ruby]] from [extra] and {{AUR|ruby-fcgi}} from [[AUR]].<br />
<br />
Follow instructions on [[RubyOnRails]].<br />
<br />
==== Python FastCGI ====<br />
Install and configure FastCGI (see [[#FastCGI]] above).<br />
<br />
Install flup:<br />
# pacman -S python2-flup<br />
Configure:<br />
fastcgi.server = (<br />
".py" =><br />
(<br />
"python-fcgi" =><br />
(<br />
"socket" => "/run/lighttpd/fastcgi.python.socket",<br />
"bin-path" => "test.py",<br />
"check-local" => "disable",<br />
"max-procs" => 1,<br />
)<br />
)<br />
)<br />
Put the test.py in the root of your server (don't forget to chmod +x it)<br />
<br />
{{bc|1=<br />
#!/usr/bin/env python2<br />
<br />
def myapp(environ, start_response):<br />
print 'got request: %s' % environ<br />
start_response('200 OK', [('Content-Type', 'text/plain')])<br />
return ['Hello World!']<br />
<br />
if __name__ == '__main__':<br />
from flup.server.fcgi import WSGIServer<br />
WSGIServer(myapp).run()<br />
}}<br />
<br />
[https://bbs.archlinux.org/viewtopic.php?pid=734173#p734173 Thanks to firecat53 for his explanation]<br />
<br />
=== SSL ===<br />
Generate an SSL Cert, e.g. like that: <br />
# mkdir /etc/lighttpd/certs<br />
# openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/lighttpd/certs/www.example.com.pem -out /etc/lighttpd/certs/www.example.com.pem<br />
# chmod 600 /etc/lighttpd/certs/www.example.com.pem<br />
<br />
Edit {{ic|/etc/lighttpd/lighttpd.conf}}.<br />
To make lighttpd SSL-only (you probably need to set the server port to 443 as well)<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem"<br />
To enable SSL in addition to normal HTTP<br />
$SERVER["socket"] == ":443" {<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" <br />
}<br />
If you want to serve different sites, you can change the document root inside the socket conditional:<br />
$SERVER["socket"] == ":443" {<br />
server.document-root = "/srv/ssl" # use your ssl directory here<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" # use the path where you created your pem file<br />
}<br />
or as alternative you can use the scheme conditional to distinguish between secure and normal requests. <br />
$HTTP["scheme"] == "https" {<br />
server.document-root = "/srv/ssl" # use your ssl directory here<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" # use the path where you created your pem file<br />
}<br />
Note that you cannot use the scheme conditional around ssl.engine above, since lighttpd needs to know on what port to enable SSL.<br />
<br />
===== Server Name Indication =====<br />
<br />
To use [http://en.wikipedia.org/wiki/Server_Name_Indication SNI] with lighttpd, simply put additional ssl.pemfile configuration directives inside host conditionals. It seems a default ssl.pemfile is still required, though.<br />
<br />
$HTTP["host"] == "www.example.org" {<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.org.pem" <br />
}<br />
<br />
$HTTP["host"] == "mail.example.org" {<br />
ssl.pemfile = "/etc/lighttpd/certs/mail.example.org.pem" <br />
}<br />
<br />
==== Redirect HTTP requests to HTTPS ====<br />
You should add "mod_redirect" in server.modules array in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
server.modules += ( "mod_redirect" )<br />
<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["host"] =~ "example.org" {<br />
url.redirect = ( "^/(.*)" => "https://example.org/$1" )<br />
server.name = "example.org" <br />
}<br />
}<br />
<br />
$SERVER["socket"] == ":443" {<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/ssl/server.pem" <br />
server.document-root = "..." <br />
}<br />
<br />
To redirect all hosts to their secure equivalents use the following in place of the socket 80 configuration above:<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["host"] =~ "(.*)" {<br />
url.redirect = ( "^/(.*)" => "https://%1/$1" )<br />
}<br />
}<br />
<br />
To redirect all hosts for part of the site (e.g. secure or phpmyadmin):<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["url"] =~ "^/secure" {<br />
url.redirect = ( "^/(.*)" => "https://example.com/$1" )<br />
}<br />
}<br />
<br />
=== Output Compression ===<br />
<br />
In {{ic|/etc/lighttpd/lighttpd.conf}} add<br />
var.cache_dir = "/var/cache/lighttpd"<br />
Then create directory for a compressed files:<br />
# mkdir /var/cache/lighttpd/compress<br />
# chown http:http /var/cache/lighttpd/compress<br />
Copy example configuration file:<br />
# mkdir /etc/lighttpd/conf.d<br />
# cp /usr/share/doc/lighttpd/config/conf.d/compress.conf /etc/lighttpd/conf.d/<br />
Add following in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
include "conf.d/compress.conf"<br />
{{Box Note | You can not do this (copy compress.conf) and add a needed content in {{ic|/etc/lighttpd/lighttpd.conf}} instead.}}<br />
<br />
==Troubleshooting==<br />
=== Lighttpd downloads .php files ===<br />
If lighttpd downloads {{ic|.php}} files instead of "initializing" them you probably missed to add these lines to your {{ic|/etc/lighttpd/lighttpd.conf}}.<br />
<br />
{{bc|1=<br />
server.modules = (<br />
"mod_fastcgi",<br />
)<br />
<br />
fastcgi.server = ( ".php" => ((<br />
"bin-path" => "/usr/bin/php-cgi", #depends where your php-cgi has been installed. Default here.<br />
"socket" => "/tmp/php.socket",<br />
"max-procs" => 2,<br />
"bin-environment" => (<br />
"PHP_FCGI_CHILDREN" => "16",<br />
"PHP_FCGI_MAX_REQUESTS" => "10000"<br />
),<br />
"bin-copy-environment" => (<br />
"PATH", "SHELL", "USER"<br />
),<br />
"broken-scriptfilename" => "enable"<br />
)))<br />
<br />
}}<br />
<br />
=== Styles (CSS) not working properly ===<br />
The default lighttpd config does not include a mimetype definition for CSS so when standards compliant browsers get text/html instead of text/css they get confused and nothing displays properly. To fix this add an entry for CSS.<br />
<br />
{{bc|1=<br />
mimetype.assign = (<br />
".html" => "text/html",<br />
".txt" => "text/plain",<br />
".jpg" => "image/jpeg",<br />
".png" => "image/png",<br />
".css" => "text/css",<br />
"" => "application/octet-stream"<br />
)<br />
}}<br />
New lines are not needed and are only used here for readability.<br />
<br />
Note: The "application/octet-stream" declaration must be at the end. It is a catch-all, and any declarations after it will be ignored.<br />
<br />
== See also ==<br />
* [http://redmine.lighttpd.net/projects/lighttpd/wiki Lighttpd wiki]</div>Buergihttps://wiki.archlinux.org/index.php?title=Lighttpd&diff=242171Lighttpd2012-12-29T15:39:47Z<p>Buergi: /* PHP */ add reload configuration</p>
<hr />
<div>[[cs:Lighttpd]]<br />
[[de:Lighttpd]]<br />
[[es:Lighttpd]]<br />
[[ru:Lighttpd]]<br />
[[zh-CN:Lighttpd]]<br />
[[zh-TW:Lighttpd]]<br />
[[Category:Web Server]]<br />
<br />
[http://www.lighttpd.net/ Lighttpd] is "a secure, fast, compliant, and very flexible [[Wikipedia:Web server|web-server]] that has been optimized for high-performance environments. It has a very low memory footprint compared to other webservers and takes care of cpu-load. Its advanced feature-set ([[Wikipedia:FastCGI|FastCGI]], [[Wikipedia:Common Gateway Interface|CGI]], Auth, Output-Compression, URL-Rewriting and many more) make lighttpd the perfect webserver-software for every server that suffers load problems."<br />
<br />
==Installation==<br />
Install the {{pkg|lighttpd}} package from the official repositories.<br />
<br />
==Configuration==<br />
===Basic Setup===<br />
The lighttpd configuration file is: {{ic|/etc/lighttpd/lighttpd.conf}}. By default it should produce a working test page. <br />
<br />
To check your {{ic|lighttpd.conf}} for bugs you can use this command - helps finding misconfigurations very fast:<br />
<br />
$ lighttpd -t -f /etc/lighttpd/lighttpd.conf<br />
<br />
The default configuration file specifies {{ic|/srv/http/}} as the document directory served.<br />
<br />
It may be necessary to add a user and group for {{ic|http}} if you do not already have one. That user needs to have write permissions to {{ic|/var/log/lighttpd}} as well, so we will make it the owner of the folder:<br />
# groupadd http<br />
# adduser http<br />
# chown -R http /var/log/lighttpd<br />
<br />
To test the install:<br />
# echo 'TestMe!' >> /srv/http/index.html<br />
# chmod 755 /srv/http/index.html<br />
<br />
To start the server:<br />
# systemctl start lighttpd<br />
<br />
Then point your browser to {{ic|localhost}}, and you should see the test page.<br />
<br />
To start the server on every boot:<br />
<br />
# systemctl enable lighttpd<br />
<br />
Example configuration files are available in {{ic|/usr/share/doc/lighttpd/}}.<br />
<br />
===FastCGI===<br />
<br />
Install {{pkg|fcgi}}.<br />
Now you have lighttpd with fcgi support. If it was that what you wanted you are all set. People that want Ruby on Rails, PHP or Python should continue.<br />
{{Box Note | New default user and group: Instead of group "nobody" lighttpd now runs as user/group "http" by default.}}<br />
<br />
First copy the example config file form {{ic|/usr/share/doc/lighttpd/config/conf.d/fastcgi.conf}} to {{ic|/etc/lighttpd/conf.d}}<br />
<br />
The following needs adding to the config file, {{ic|/etc/lighttpd/conf.d/fastcgi.conf}}<br />
server.modules += ( "mod_fastcgi" )<br />
<br />
#server.indexfiles += ( "dispatch.fcgi" ) #this is deprecated<br />
index-file.names += ( "dispatch.fcgi" ) #dispatch.fcgi if rails specified<br />
<br />
server.error-handler-404 = "/dispatch.fcgi" #too<br />
fastcgi.server = (<br />
".fcgi" => (<br />
"localhost" => ( <br />
"socket" => "/run/lighttpd/rails-fastcgi.sock",<br />
"bin-path" => "/path/to/rails/application/public/dispatch.fcgi"<br />
)<br />
)<br />
)<br />
<br />
Then in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
include "conf.d/fastcgi.conf"<br />
<br />
For PHP or Ruby on Rails see the next sections.<br />
<br />
====PHP====<br />
<br />
Install {{pkg|php}} and {{pkg|php-cgi}} (see also [[PHP]] and [[LAMP]]).<br />
<br />
Check that php-cgi is working {{Ic|php-cgi --version}}<br />
<br />
PHP 5.4.3 (cgi-fcgi) (built: May 8 2012 17:10:17)<br />
Copyright (c) 1997-2012 The PHP Group<br />
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies<br />
<br />
If you get a similar output then php is installed correctly.<br />
<br />
{{Note|Please keep in mind if you receive errors like ''No input file found'' after attempting to access your php files then make sure {{ic|/etc/php/php.ini}} has the directives enabled:}}<br />
cgi.fix_pathinfo=1<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/another/path:/second/path<br />
And that the files are world readable, <br />
# chmod -R 755<br />
<br />
In {{ic|/etc/lighttpd/conf.d/fastcgi.conf}} add:<br />
server.modules += ( "mod_fastcgi" )<br />
<br />
#server.indexfiles += ( "index.php" ) #this is deprecated<br />
index-file.names += ( "index.php" )<br />
<br />
fastcgi.server = (<br />
".php" => (<br />
"localhost" => ( <br />
"bin-path" => "/usr/bin/php-cgi",<br />
"socket" => "/run/lighttpd/php-fastcgi.sock",<br />
"max-procs" => 4, # default value<br />
"bin-environment" => (<br />
"PHP_FCGI_CHILDREN" => "1", # default value<br />
),<br />
"broken-scriptfilename" => "enable"<br />
))<br />
)<br />
<br />
Then in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
include "conf.d/fastcgi.conf"<br />
<br />
Finally reload the configuration<br />
# systemctl reload lighttpd<br />
<br />
===== Using php-fpm =====<br />
<br />
There is no adaptive spawning anymore in recent lighttpd releases. For dynamic management of PHP processes, you can use {{Pkg|php-fpm}}.<br />
# pacman -S php-fpm<br />
# rc.d start php-fpm<br />
{{Note|You can configure the number of servers in the pool and tweak other configuration options by editing the file {{ic|/etc/php/php-fpm.conf}}. More details on ''php-fpm'' can be found on the [http://php-fpm.anight.org/ php-fpm website]. You should also note that when you make changes to /etc/php/php.ini you will need to restart php-fpm}}<br />
<br />
In {{ic|/etc/lighttpd/conf.d/fastcgi.conf}} add:<br />
server.modules += ( "mod_fastcgi" )<br />
<br />
index-file.names += ( "index.php" ) <br />
<br />
fastcgi.server = (<br />
".php" => (<br />
"localhost" => ( <br />
"socket" => "/run/php-fpm/php-fpm.sock",<br />
"broken-scriptfilename" => "enable"<br />
))<br />
)<br />
<br />
===== eAccelerator =====<br />
<br />
Install {{AUR|eaccelerator}} from the [[Arch User Repository|AUR]].<br />
<br />
Add own config file for eaccelerator:<br />
<br />
{{hc|/etc/php/conf.d/eaccelerator-own.ini|2=<br />
zlib.output_compression = On<br />
cgi.fix_pathinfo=1<br />
eaccelerator.cache_dir="/home/phpuser/eaccelerator/cache"<br />
}}<br />
<br />
{{Tip|I additionally set {{ic|safe_mod}} to {{ic|On}} in my setup, but this is not required.}}<br />
<br />
===== Try a php page =====<br />
Create the following php page, name it index.php, and place a copy in both /srv/http/ and /srv/http-ssl/html/<br />
<?php<br />
phpinfo();<br />
?><br />
Try navigating with a web browser to both the http and https address of your server. You should see the phpinfo page.<br />
<br />
Check eaccelerator caching:<br />
# ls -l /home/phpuser/eaccelerator/cache<br />
<br />
If the above command outputs the following:<br />
-rw------- 1 phpuser phpuser 456 2005-05-05 14:53 eaccelerator-277.58081<br />
-rw------- 1 phpuser phpuser 452 2005-05-05 14:53 eaccelerator-277.88081<br />
Then eaccelerator is happily caching your php scripts to help speed things up.<br />
<br />
====Ruby on Rails====<br />
Install and configure FastCGI (see [[#FastCGI]] above).<br />
<br />
Install [[ruby]] from [extra] and {{AUR|ruby-fcgi}} from [[AUR]].<br />
<br />
Follow instructions on [[RubyOnRails]].<br />
<br />
==== Python FastCGI ====<br />
Install and configure FastCGI (see [[#FastCGI]] above).<br />
<br />
Install flup:<br />
# pacman -S python2-flup<br />
Configure:<br />
fastcgi.server = (<br />
".py" =><br />
(<br />
"python-fcgi" =><br />
(<br />
"socket" => "/run/lighttpd/fastcgi.python.socket",<br />
"bin-path" => "test.py",<br />
"check-local" => "disable",<br />
"max-procs" => 1,<br />
)<br />
)<br />
)<br />
Put the test.py in the root of your server (don't forget to chmod +x it)<br />
<br />
{{bc|1=<br />
#!/usr/bin/env python2<br />
<br />
def myapp(environ, start_response):<br />
print 'got request: %s' % environ<br />
start_response('200 OK', [('Content-Type', 'text/plain')])<br />
return ['Hello World!']<br />
<br />
if __name__ == '__main__':<br />
from flup.server.fcgi import WSGIServer<br />
WSGIServer(myapp).run()<br />
}}<br />
<br />
[https://bbs.archlinux.org/viewtopic.php?pid=734173#p734173 Thanks to firecat53 for his explanation]<br />
<br />
=== SSL ===<br />
Generate an SSL Cert, e.g. like that: <br />
# mkdir /etc/lighttpd/certs<br />
# openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/lighttpd/certs/www.example.com.pem -out /etc/lighttpd/certs/www.example.com.pem<br />
# chmod 600 /etc/lighttpd/certs/www.example.com.pem<br />
<br />
Edit {{ic|/etc/lighttpd/lighttpd.conf}}.<br />
To make lighttpd SSL-only (you probably need to set the server port to 443 as well)<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem"<br />
To enable SSL in addition to normal HTTP<br />
$SERVER["socket"] == ":443" {<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" <br />
}<br />
If you want to serve different sites, you can change the document root inside the socket conditional:<br />
$SERVER["socket"] == ":443" {<br />
server.document-root = "/srv/ssl" # use your ssl directory here<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" # use the path where you created your pem file<br />
}<br />
or as alternative you can use the scheme conditional to distinguish between secure and normal requests. <br />
$HTTP["scheme"] == "https" {<br />
server.document-root = "/srv/ssl" # use your ssl directory here<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" # use the path where you created your pem file<br />
}<br />
Note that you cannot use the scheme conditional around ssl.engine above, since lighttpd needs to know on what port to enable SSL.<br />
<br />
===== Server Name Indication =====<br />
<br />
To use [http://en.wikipedia.org/wiki/Server_Name_Indication SNI] with lighttpd, simply put additional ssl.pemfile configuration directives inside host conditionals. It seems a default ssl.pemfile is still required, though.<br />
<br />
$HTTP["host"] == "www.example.org" {<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.org.pem" <br />
}<br />
<br />
$HTTP["host"] == "mail.example.org" {<br />
ssl.pemfile = "/etc/lighttpd/certs/mail.example.org.pem" <br />
}<br />
<br />
==== Redirect HTTP requests to HTTPS ====<br />
You should add "mod_redirect" in server.modules array in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
server.modules = (<br />
...<br />
"mod_redirect", <br />
...<br />
)<br />
<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["host"] =~ "example.org" {<br />
url.redirect = ( "^/(.*)" => "https://example.org/$1" )<br />
server.name = "example.org" <br />
}<br />
}<br />
<br />
$SERVER["socket"] == ":443" {<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/ssl/server.pem" <br />
server.document-root = "..." <br />
}<br />
<br />
To redirect all hosts to their secure equivalents use the following in place of the socket 80 configuration above:<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["host"] =~ "(.*)" {<br />
url.redirect = ( "^/(.*)" => "https://%1/$1" )<br />
}<br />
}<br />
<br />
To redirect all hosts for part of the site (e.g. secure or phpmyadmin):<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["url"] =~ "^/secure" {<br />
url.redirect = ( "^/(.*)" => "https://example.com/$1" )<br />
}<br />
}<br />
<br />
=== Output Compression ===<br />
<br />
In {{ic|/etc/lighttpd/lighttpd.conf}} add<br />
var.cache_dir = "/var/cache/lighttpd"<br />
Then create directory for a compressed files:<br />
# mkdir /var/cache/lighttpd/compress<br />
# chown http:http /var/cache/lighttpd/compress<br />
Copy example configuration file:<br />
# mkdir /etc/lighttpd/conf.d<br />
# cp /usr/share/doc/lighttpd/config/conf.d/compress.conf /etc/lighttpd/conf.d/<br />
Add following in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
include "conf.d/compress.conf"<br />
{{Box Note | You can not do this (copy compress.conf) and add a needed content in {{ic|/etc/lighttpd/lighttpd.conf}} instead.}}<br />
<br />
==Troubleshooting==<br />
=== Lighttpd downloads .php files ===<br />
If lighttpd downloads {{ic|.php}} files instead of "initializing" them you probably missed to add these lines to your {{ic|/etc/lighttpd/lighttpd.conf}}.<br />
<br />
{{bc|1=<br />
server.modules = (<br />
"mod_fastcgi",<br />
)<br />
<br />
fastcgi.server = ( ".php" => ((<br />
"bin-path" => "/usr/bin/php-cgi", #depends where your php-cgi has been installed. Default here.<br />
"socket" => "/tmp/php.socket",<br />
"max-procs" => 2,<br />
"bin-environment" => (<br />
"PHP_FCGI_CHILDREN" => "16",<br />
"PHP_FCGI_MAX_REQUESTS" => "10000"<br />
),<br />
"bin-copy-environment" => (<br />
"PATH", "SHELL", "USER"<br />
),<br />
"broken-scriptfilename" => "enable"<br />
)))<br />
<br />
}}<br />
<br />
=== Styles (CSS) not working properly ===<br />
The default lighttpd config does not include a mimetype definition for CSS so when standards compliant browsers get text/html instead of text/css they get confused and nothing displays properly. To fix this add an entry for CSS.<br />
<br />
{{bc|1=<br />
mimetype.assign = (<br />
".html" => "text/html",<br />
".txt" => "text/plain",<br />
".jpg" => "image/jpeg",<br />
".png" => "image/png",<br />
".css" => "text/css",<br />
"" => "application/octet-stream"<br />
)<br />
}}<br />
New lines are not needed and are only used here for readability.<br />
<br />
Note: The "application/octet-stream" declaration must be at the end. It is a catch-all, and any declarations after it will be ignored.<br />
<br />
== See also ==<br />
* [http://redmine.lighttpd.net/projects/lighttpd/wiki Lighttpd wiki]</div>Buergihttps://wiki.archlinux.org/index.php?title=Google_Authenticator&diff=240992Google Authenticator2012-12-20T15:13:32Z<p>Buergi: corr some typos</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[Category:Security]]<br />
<br />
The [http://code.google.com/p/google-authenticator/ Google Authenticator project] provides a two-step authentication procedure using one-time passcodes (OTP). The OTP generator application is available for iOS, Android and Blackberry. Similar to [[S/KEY_Authentication]] the authentication mechanism integrates into the Linux PAM system. This guide shows the installation and configuration of this mechanism.<br />
<br />
==Installation==<br />
<br />
The required software is available in the {{Aur|google-authenticator-libpam-git}} package in the AUR. It is most conveniently installed using [[Yaourt]]<br />
<br />
$ yaourt -S google-authenticator-libpam-git<br />
<br />
==Setting up the PAM==<br />
<br />
{{Warning|If you do all configuration via SSH do not close the session before you tested that everything is working, else you may lock yourself out. Furthermore consider generating the key file before activating the PAM.}}<br />
<br />
Usually one demands two-pass authentication only for remote login. The corresponding PAM configuration file is {{ic|/etc/pam.d/sshd}}. In case you want to use Google Authenticator globally you would need to change {{ic|/etc/pam.d/system-auth}}, however, in this case proceed with extreme caution to not lock yourself out.<br />
In this guide we proceed with editing {{ic|/etc/pam.d/sshd}} which is most safely (but not necessarily) be done in a local session.<br />
<br />
To enter both, your unix password and your OTP add {{ic|pam_google_authenticator.so}} the following way.<br />
<br />
auth required pam_google_authenticator.so<br />
auth required pam_unix.so<br />
auth required pam_env.so<br />
<br />
This will ask for the OTP before prompting for your Unix password. Changing the order of the two modules will reverse this order.<br />
<br />
{{Warning|Only users that have generated a secret key file (see below) will be allowed to log in using SSH.}}<br />
<br />
To allow login with either the OTP or your Unix password use<br />
<br />
auth sufficient pam_google_authenticator.so<br />
auth sufficient pam_unix.so<br />
auth required pam_env.so<br />
<br />
Finally enable challenge-response authentication in {{ic|/etc/ssh/sshd_config}}:<br />
ChallengeResponseAuthentication yes<br />
and reload {{ic|sshd}}'s configuration<br />
# systemctl reload sshd<br />
<br />
==Generating a secret key file==<br />
<br />
Every user who wants to use two-pass authentication needs to generate a secret key file in his home folder.<br />
This can very easily be done using {{ic|google-authenticator}} as included in {{Aur|google-authenticator-libpam-git}}.<br />
<br />
$ google-authenticator<br />
Do you want authentication tokens to be time-based (y/n) y<br />
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/username@hostname%3Fsecret%3DZVZG5UZU4D7MY4DH<br />
Your new secret key is: ZVZG5UZU4D7MY4DH<br />
Your verification code is 269371<br />
Your emergency scratch codes are:<br />
70058954<br />
97277505<br />
99684896<br />
56514332<br />
82717798<br />
<br />
Do you want me to update your "/home/username/.google_authenticator" file (y/n) y<br />
<br />
Do you want to disallow multiple uses of the same authentication<br />
token? This restricts you to one login about every 30s, but it increases<br />
your chances to notice or even prevent man-in-the-middle attacks (y/n) y<br />
<br />
By default, tokens are good for 30 seconds and in order to compensate for<br />
possible time-skew between the client and the server, we allow an extra<br />
token before and after the current time. If you experience problems with poor<br />
time synchronization, you can increase the window from its default<br />
size of 1:30min to about 4min. Do you want to do so (y/n) n<br />
<br />
If the computer that you are logging into isn't hardened against brute-force<br />
login attempts, you can enable rate-limiting for the authentication module.<br />
By default, this limits attackers to no more than 3 login attempts every 30s.<br />
Do you want to enable rate-limiting (y/n) y<br />
<br />
It's recommended to '''store the emergency scratch codes safely''' (print them out and keep them in a save location) as they are your only way to log in (via SSH) when you lost your mobile phone (i.e. your OTP-generator). They are also stored in {{ic|~/.google_authenticator}}, so you can look them up any time as long as you are logged in.<br />
<br />
<br />
==Setting up your OTP-generator==<br />
Install the corresponding generator application on your mobile phone from the corresponding store by browsing to [http://m.google.com/authenticator http://m.google.com/authenticator] from your mobile device.<br />
In the applications menu click the corresponding button to create a new account and either scan the QR code from the URL you were told when generating the secret key file, or enter the secret key (in the example above 'ZVZG5UZU4D7MY4DH') manually.<br />
<br />
Now you should see a new passcode token being generated every 30 seconds on your phone.<br />
<br />
==Testing==<br />
SSH to your host from another machine or from another terminal window and check if it works.<br />
<br />
$ssh username@hostname<br />
login as: username<br />
Verification code:<br />
Password:<br />
$</div>Buergihttps://wiki.archlinux.org/index.php?title=Google_Authenticator&diff=240991Google Authenticator2012-12-20T15:10:25Z<p>Buergi: /* Setting up the PAM */ add 'ChallengeResponseAuthentication yes'</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[Category:Security]]<br />
<br />
The [http://code.google.com/p/google-authenticator/ Google Authenticator project] provides a two-step authentication procedure using one-time passcodes (OTP). The OTP generator application is available for iOS, Android and Blackberry. Similar to [[S/KEY_Authentication]] the authentication mechanism integrates into the Linux PAM system. This guide shows the installation and configuration of this mechanism.<br />
<br />
==Installation==<br />
<br />
The required software is available in the {{Aur|google-authenticator-libpam-git}} package in the AUR. It is most conveniently installed using [[Yaourt]]<br />
<br />
$ yaourt -S google-authenticator-libpam-git<br />
<br />
==Setting up the PAM==<br />
<br />
{{Warning|If you do all configuration via SSH do not close the session before you tested that everything is working, else you may lock yourself out. Furthermore consider generating the key file before activating the PAM.}}<br />
<br />
Usually one demands two-pass authentication only for remote login. The corresponding PAM configuration file is {{ic|/etc/pam.d/sshd}}. In case you want to use Google Authenticator globally you would need to change {{ic|/etc/pam.d/system-auth}}, however, in this case proceed with extreme caution to not lock yourself out.<br />
In this guide we proceed with editing {{ic|/etc/pam.d/sshd}} which is most safely (but not necessarly) be done in a local session.<br />
<br />
To enter both, your unix password and your OTP add {{ic|pam_google_authenticator.so}} the following way.<br />
<br />
auth required pam_google_authenticator.so<br />
auth required pam_unix.so<br />
auth required pam_env.so<br />
<br />
This will ask for the OTP before prompting for your unix password. Changing the order of the two modules will reverse this order.<br />
<br />
{{Warning|Only users that have generated a secret key file (see below) will be allowed to log in using SSH.}}<br />
<br />
To allow login with either the OTP or your unix password use<br />
<br />
auth sufficient pam_google_authenticator.so<br />
auth sufficient pam_unix.so<br />
auth required pam_env.so<br />
<br />
Finally enable challenge-response authentication in {{ic|/etc/ssh/sshd_config}}:<br />
ChallengeResponseAuthentication yes<br />
and reload {{ic|sshd}}'s configuration<br />
# systemctl reload sshd<br />
<br />
==Generating a secret key file==<br />
<br />
Every user who wants to use two-pass authentication needs to generate a secret key file in his home folder.<br />
This can very easily be done using {{ic|google-authenticator}} as included in {{Aur|google-authenticator-libpam-git}}.<br />
<br />
$ google-authenticator<br />
Do you want authentication tokens to be time-based (y/n) y<br />
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/username@hostname%3Fsecret%3DZVZG5UZU4D7MY4DH<br />
Your new secret key is: ZVZG5UZU4D7MY4DH<br />
Your verification code is 269371<br />
Your emergency scratch codes are:<br />
70058954<br />
97277505<br />
99684896<br />
56514332<br />
82717798<br />
<br />
Do you want me to update your "/home/username/.google_authenticator" file (y/n) y<br />
<br />
Do you want to disallow multiple uses of the same authentication<br />
token? This restricts you to one login about every 30s, but it increases<br />
your chances to notice or even prevent man-in-the-middle attacks (y/n) y<br />
<br />
By default, tokens are good for 30 seconds and in order to compensate for<br />
possible time-skew between the client and the server, we allow an extra<br />
token before and after the current time. If you experience problems with poor<br />
time synchronization, you can increase the window from its default<br />
size of 1:30min to about 4min. Do you want to do so (y/n) n<br />
<br />
If the computer that you are logging into isn't hardened against brute-force<br />
login attempts, you can enable rate-limiting for the authentication module.<br />
By default, this limits attackers to no more than 3 login attempts every 30s.<br />
Do you want to enable rate-limiting (y/n) y<br />
<br />
It's recommended to '''store the emergency scratch codes savely''' (print them out and keep them in a save location) as they are your only way to log in (via SSH) when you lost your mobile phone (i.e. your OTP-generator). They are also stored in {{ic|~/.google_authenticator}}, so you can look them up any time as long as you are logged in.<br />
<br />
<br />
==Setting up your OTP-generator==<br />
Install the corresponding generator application on your mobile phone from the corresponding store by browsing to [http://m.google.com/authenticator http://m.google.com/authenticator] from your mobile device.<br />
In the applications menu click the corresponding button to create a new account and either scan the QR code from the URL you were told when generating the secret key file, or enter the secret key (in the example above 'ZVZG5UZU4D7MY4DH') manually.<br />
<br />
Now you should see a new passcode token beeing generated every 30 seconds on your phone.<br />
<br />
==Testing==<br />
SSH to your host from another machine or from another terminal window and check if it works.<br />
<br />
$ssh username@hostname<br />
login as: username<br />
Verification code:<br />
Password:<br />
$</div>Buergihttps://wiki.archlinux.org/index.php?title=Google_Authenticator&diff=240990Google Authenticator2012-12-20T15:05:37Z<p>Buergi: Initial version</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[Category:Security]]<br />
<br />
The [http://code.google.com/p/google-authenticator/ Google Authenticator project] provides a two-step authentication procedure using one-time passcodes (OTP). The OTP generator application is available for iOS, Android and Blackberry. Similar to [[S/KEY_Authentication]] the authentication mechanism integrates into the Linux PAM system. This guide shows the installation and configuration of this mechanism.<br />
<br />
==Installation==<br />
<br />
The required software is available in the {{Aur|google-authenticator-libpam-git}} package in the AUR. It is most conveniently installed using [[Yaourt]]<br />
<br />
$ yaourt -S google-authenticator-libpam-git<br />
<br />
==Setting up the PAM==<br />
<br />
{{Warning|If you do all configuration via SSH do not close the session before you tested that everything is working, else you may lock yourself out. Furthermore consider generating the key file before activating the PAM.}}<br />
<br />
Usually one demands two-pass authentication only for remote login. The corresponding PAM configuration file is {{ic|/etc/pam.d/sshd}}. In case you want to use Google Authenticator globally you would need to change {{ic|/etc/pam.d/system-auth}}, however, in this case proceed with extreme caution to not lock yourself out.<br />
In this guide we proceed with editing {{ic|/etc/pam.d/sshd}} which is most safely (but not necessarly) be done in a local session.<br />
<br />
To enter both, your unix password and your OTP add {{ic|pam_google_authenticator.so}} the following way.<br />
<br />
auth required pam_google_authenticator.so<br />
auth required pam_unix.so<br />
auth required pam_env.so<br />
<br />
This will ask for the OTP before prompting for your unix password. Changing the order of the two modules will reverse this order.<br />
<br />
{{Warning|Only users that have generated a secret key file (see below) will be allowed to log in using SSH.}}<br />
<br />
To allow login with either the OTP or your unix password use<br />
<br />
auth sufficient pam_google_authenticator.so<br />
auth sufficient pam_unix.so<br />
auth required pam_env.so<br />
<br />
<br />
==Generating a secret key file==<br />
<br />
Every user who wants to use two-pass authentication needs to generate a secret key file in his home folder.<br />
This can very easily be done using {{ic|google-authenticator}} as included in {{Aur|google-authenticator-libpam-git}}.<br />
<br />
$ google-authenticator<br />
Do you want authentication tokens to be time-based (y/n) y<br />
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/username@hostname%3Fsecret%3DZVZG5UZU4D7MY4DH<br />
Your new secret key is: ZVZG5UZU4D7MY4DH<br />
Your verification code is 269371<br />
Your emergency scratch codes are:<br />
70058954<br />
97277505<br />
99684896<br />
56514332<br />
82717798<br />
<br />
Do you want me to update your "/home/username/.google_authenticator" file (y/n) y<br />
<br />
Do you want to disallow multiple uses of the same authentication<br />
token? This restricts you to one login about every 30s, but it increases<br />
your chances to notice or even prevent man-in-the-middle attacks (y/n) y<br />
<br />
By default, tokens are good for 30 seconds and in order to compensate for<br />
possible time-skew between the client and the server, we allow an extra<br />
token before and after the current time. If you experience problems with poor<br />
time synchronization, you can increase the window from its default<br />
size of 1:30min to about 4min. Do you want to do so (y/n) n<br />
<br />
If the computer that you are logging into isn't hardened against brute-force<br />
login attempts, you can enable rate-limiting for the authentication module.<br />
By default, this limits attackers to no more than 3 login attempts every 30s.<br />
Do you want to enable rate-limiting (y/n) y<br />
<br />
It's recommended to '''store the emergency scratch codes savely''' (print them out and keep them in a save location) as they are your only way to log in (via SSH) when you lost your mobile phone (i.e. your OTP-generator). They are also stored in {{ic|~/.google_authenticator}}, so you can look them up any time as long as you are logged in.<br />
<br />
<br />
==Setting up your OTP-generator==<br />
Install the corresponding generator application on your mobile phone from the corresponding store by browsing to [http://m.google.com/authenticator http://m.google.com/authenticator] from your mobile device.<br />
In the applications menu click the corresponding button to create a new account and either scan the QR code from the URL you were told when generating the secret key file, or enter the secret key (in the example above 'ZVZG5UZU4D7MY4DH') manually.<br />
<br />
Now you should see a new passcode token beeing generated every 30 seconds on your phone.<br />
<br />
==Testing==<br />
SSH to your host from another machine or from another terminal window and check if it works.<br />
<br />
$ssh username@hostname<br />
login as: username<br />
Verification code:<br />
Password:<br />
$</div>Buergihttps://wiki.archlinux.org/index.php?title=User_talk:Kynikos.bot&diff=238604User talk:Kynikos.bot2012-12-05T17:07:35Z<p>Buergi: /* Wrong substitution. */ new section</p>
<hr />
<div>==<s>URL update requests</s>==<br />
<br />
I'm requesting another round of this:<br />
Replace "http://aur.archlinux.org" with "https://aur.archlinux.org" (from Special:LinkSearch using the bot's RegExp replace plugin)<br />
And I'd also like to see it replace "http://bbs.archlinux.org" with "https://bbs.archlinux.org" which is a [https://wiki.archlinux.org/index.php?title=Special%3ALinkSearch&target=http%3A%2F%2Fbbs.archlinux.org&namespace= daunting task]. Same thing for "http://www.archlinux.org" with "https://www.archlinux.org" and "http://bugs.archlinux.org" with "https://bugs.archlinux.org"<br />
<br>Thanks!<br />
<br>-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 23:52, 26 October 2012 (UTC)<br />
<br />
:Acknowledged, however I think I'll attempt something even more comprehensive, using [https://wiki.archlinux.org/index.php?title=Special:LinkSearch&target=http%3A%2F%2F*.archlinux.org&namespace=0]. Unfortunately I'm really short of time in this period, as you've probably noticed... And time's not the only problem, I don't have frequent access to a computer that can stay connected for many hours continuously, so of course if somebody else was willing to learn how to use [[Wiki Monkey]], which should be very easy (and I'd be willing to assist), these tasks could be performed more frequently.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:13, 28 October 2012 (UTC)<br />
<br />
::Closing, the task is added to the bot's schedule. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:22, 5 December 2012 (UTC)<br />
<br />
== Wrong substitution. ==<br />
<br />
I found the bot made at least one wrong substitution, check out the following [https://wiki.archlinux.org/index.php?title=Installing_on_Btrfs_root&diff=238603&oldid=238502 diff] of the article [[Installing on Btrfs root]]. Perhaps you can check if the bot made this mistake on other pages, too. -- [[User:Buergi|Buergi]] ([[User talk:Buergi|talk]]) 17:07, 5 December 2012 (UTC)</div>Buergihttps://wiki.archlinux.org/index.php?title=Mkinitcpio-btrfs&diff=238603Mkinitcpio-btrfs2012-12-05T16:59:06Z<p>Buergi: /* Preparing the root drive */ Fix Problem introduced by Kynikos.bot</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
{{Article summary start}}<br />
{{Article summary text|Installing on btrfs root Outlines a process for installing (or converting) Arch Linux to a btrfs root drive with syslinux or GRUB2.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary text|[[Wikipedia:Btrfs|Btrfs &mdash; Wikipedia]]}}<br />
{{Article summary link|FAQ &mdash; Btrfs Wiki|https://btrfs.wiki.kernel.org/articles/f/a/q/FAQ_1fe9.html#Is_btrfs_stable.3F}}<br />
{{Article summary link|GNU GRUB &mdash; GNU Project|https://gnu.org/s/grub/}}<br />
{{Article summary link|Syslinux Website|http://www.syslinux.org/wiki/index.php/The_Syslinux_Project}}<br />
{{Article summary text|[[Wikipedia:GUID Partition Table|GUID Partition Table &mdash; Wikipedia]]}}<br />
{{Article summary end}}<br />
<br />
[[btrfs]] provides a number of features (such as checksumming, snapshots, and subvolumes) that make it an excellent candidate for using it as the root partition in an Arch Linux installation. For a tour of btrfs features see [http://www.youtube.com/watch?v=hxWuaozpe2I A tour of btrfs]. As is common with FLOSS, there are a number of ways to configure btrfs as the root filesystem.<br />
<br />
This article assumes your are doing a fresh install from the [https://www.archlinux.org/download/ Arch Linux installation media]. It is also possible to create a backup of an existing Arch Linux installation and restore it to a fresh btrfs configuration. This technique is also shown in this article.<br />
<br />
{{Note|This article is for more advanced Arch Linux users, but if you are a newbie and are one with the command line, you shouldn't have any trouble as long as you are determined.}}<br />
<br />
== btrfs-progs ==<br />
<br />
To create a btrfs filesystem you will need to [[pacman|install]] the {{Pkg|btrfs-progs}} from [[Official Repositories]]. If using [[Archboot]], it's already available.<br />
<br />
== mkinitcpio-btrfs ==<br />
<br />
To get rollback features on your btrfs root device, you will need to install the {{AUR|mkinitcpio-btrfs}} package from the [[Arch User Repository]].<br />
<br />
For reference, here are the internal variables used by {{AUR|mkinitcpio-btrfs}}:<br />
<br />
${BTRFS_HAS_ROLLBACK:=true}<br />
${BTRFS_BOOT_SUBVOL:="__active"}<br />
${BTRFS_DIR_WORK:="/new_root"}<br />
${BTRFS_DIR_SNAP:="/__snapshot"}<br />
${BTRFS_DIR_ACTIVE:="/__active"}<br />
${BTRFS_DIR_ROLLBACK:="/__rollback"}<br />
${BTRFS_ROLLBACK_CHOICE:="default"}<br />
${BTRFS_ROLLBACK_LIST:="default"}<br />
${BTRFS_ROLLBACK_LIST_COUNT:=0}<br />
<br />
{{Note|The ''btrfs_advanced'' mkinitcpio hook (provided by ''mkinitcpio-btrfs'' package) is needed specifically for rollback and possibly other advanced features. The standard ''btrfs'' hook is enough to get multi-device (RAID) support. The kernel is capable of booting a single-device btrfs root on its own.}}<br />
<br />
== Back up an existing Arch Linux installation ==<br />
<br />
{{Tip|Skip this section if you are doing a fresh installation.}}<br />
<br />
Having a complete backup strategy before messing with the partitioning of storage drives is vitally '''''important'''''. So before doing anything you must back up, and you must also know how to recover from a backup. There are of course a number of ways to do this. But the easiest by far is to mount a spare backup drive and use rsync:<br />
<br />
# rsync -aAXv --exclude={dev,sys,proc,mnt,tmp,media} / <dest>/`date +%Y-%m-%d-%T`/<br />
<br />
To restore from an rsync backup, just reverse the paths. It is also possible to use tar:<br />
<br />
{{bc|1=# tar -cvpPJf $BACKUPDIR/$FILENAME --exclude="/proc/*" --exclude="/sys/*" \<br />
--exclude="/mnt/*" --exclude="/media/*" --exclude="/dev/*" --exclude="/tmp/*" /}}<br />
<br />
and to restore from a tar backup:<br />
<br />
# tar -xvpJf <backup_file> -C <root><br />
<br />
== Boot into a live image ==<br />
<br />
It is recommended that you boot and install from the latest [https://www.archlinux.org/download/ Archlinux Netinstall Image], or and up-to-date Archlinux installation, or [[Archboot]]. The latter is capable of installing to a btrfs partition natively but does not support the unified setup detailed here; it is however a good option for this procedure because it includes recent builds of all the necessary packages.<br />
<br />
== Preparing the root drive ==<br />
<br />
Now it is time to actually install the btrfs filesystem. Please make sure that {{Pkg|btrfs-progs}} is installed and functioning correctly:<br />
<br />
# btrfs --help<br />
<br />
{{Warning|1=If you need swap support, either make a partition, or use the loop method detailed below. '''DO NOT''' simply use a swap file! [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=35054394c4b3cecd52577c2662c84da1f3e73525 Doing so will corrupt your btrfs filesystem].}}<br />
<br />
{{Note|It is possible to allow btrfs to use the entire hard drive without using a partitioning scheme, but that is not recommended. [[GRUB2#Install_to_Partition_or_Partitionless_Disk]].The method used for the syslinux directions in this article does not use a partitioning system. This portion of the article will be updated in the future, but until then you can study the [[GUID Partition Table]] + [[syslinux]] installation method [http://tincman.wordpress.com/2011/01/20/installing-arch-linux-onto-a-gpt-partitioned-btrfs-root-ssd-on-a-legacy-bios-system/ here].}}<br />
<br />
{{Note|[[syslinux]] and [[GRUB2]] allow booting from a drive without a separate boot partition. However, syslinux does not currently support boot directories within a btrfs subvolume. Both syslinux and GRUB2 allow the use of modern GPT partitioning.}}<br />
<br />
=== GPT partitioning for GRUB2 ===<br />
<br />
To get started partitioning, we must [[pacman|install]] the {{Pkg|gptfdisk}} package from the [[Official Repositories]]:<br />
<br />
# pacman -S gptfdisk<br />
<br />
[[GRUB2]] requires a +2M boot partition at the front of the drive [[GRUB2#GPT_specific_instructions]]. You can create that with gdisk:<br />
<br />
# gdisk /dev/sda<br />
<br />
Once gdisk has loaded, you can begin entering commands into the command prompt. Type {{ic|?}} to see the available commands. Press {{ic|o}} to create a new partition table. Just use the help command and create two partitions and<br />
then use {{ic|p}} to verify the output:<br />
<br />
{{bc|<br />
GPT fdisk (gdisk) version 0.8.2<br />
<br />
Partition table scan:<br />
MBR: protective<br />
BSD: not present<br />
APM: not present<br />
GPT: present<br />
<br />
Found valid GPT with protective MBR; using GPT.<br />
<br />
Command (? for help): p<br />
Disk /dev/sda: 234441648 sectors, 111.8 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): C75A01F9-D34E-4895-9AAB-2C8118118211<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 234441614<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 6143 2.0 MiB EF02 BIOS boot partition<br />
2 6144 234441614 111.8 GiB 8300 Linux filesystem<br />
<br />
Command (? for help):<br />
}}<br />
<br />
{{Note|Notice the {{ic|EF02}} hex code for the partition type for the 2Mb GRUB2 boot partition. This is needed to allow GRUB2 to install the {{ic|core.img}} file into that partition for booting}}<br />
<br />
Once you have created the partitions, we will need to set the boot flag on the btrfs partition. Press {{ic|x}} for advanced options and then press {{ic|a}} to set attributes. Press the number for the partition you want to alter, in this<br />
example it is {{ic|2}}. Now press {{ic|2}} to set the legacy boot flag:<br />
<br />
{{bc|<br />
Command (? for help): x<br />
<br />
Expert command (? for help): a<br />
Partition number (1-2): 2<br />
Known attributes are:<br />
0: system partition<br />
1: hide from EFI<br />
2: legacy BIOS bootable<br />
60: read-only<br />
62: hidden<br />
63: do not automount<br />
<br />
Attribute value is 0000000000000000. Set fields are:<br />
No fields set<br />
<br />
Toggle which attribute field (0-63, 64 or <Enter> to exit): 2<br />
Have enabled the 'legacy BIOS bootable' attribute.<br />
Attribute value is 0000000000000004. Set fields are:<br />
2 (legacy BIOS bootable)<br />
<br />
Toggle which attribute field (0-63, 64 or <Enter> to exit):<br />
}}<br />
<br />
Finally, press {{ic|w}} to write the data to the disk.<br />
<br />
=== GPT partitioning for Syslinux ===<br />
<br />
This section hasn't been written yet. For a quick tutorial go [http://tincman.wordpress.com/2011/01/20/installing-arch-linux-onto-a-gpt-partitioned-btrfs-root-ssd-on-a-legacy-bios-system/ here];<br />
<br />
=== Configure the btrfs filesystem ===<br />
<br />
With the drive partitioned and ready for a filesystem, make sure {{Pkg|btrfs-progs}} is installed and create the filesystem on the root partition:<br />
<br />
# mkfs.btrfs -L btrfs-root /dev/sda2<br />
<br />
Now it is time to mount the new filesystem. First create the mount directory:<br />
<br />
# mkdir /mnt/btrfs-root<br />
<br />
and mount the partition:<br />
<br />
# mount -o defaults,noatime,discard,ssd /dev/sda2 /mnt/btrfs-root && cd /mnt/btrfs-root<br />
<br />
{{Note|If you are not using an SSD drive, remove {{ic|discard,ssd}} from the mount options.}}<br />
<br />
Now you should be in the newly mounted btrfs filesystem! If you plan on using the rollback features of btrfs, create a {{ic|__snapshot}} directory for containing snapshots:<br />
<br />
# mkdir __snapshot<br />
<br />
{{Note|{{ic|__snapshot}} is chosen for integration with current {{AUR|mkinitcpio-btrfs}}. See the variable reference above, or the source mkinitcpio-btrfs package.}}<br />
<br />
If you plan on using [[Syslinux]] as your boot loader, you will need to create a boot directory:<br />
<br />
# mkdir boot<br />
<br />
{{Note|Syslinux currently does not support boot directories within btrfs subvolumes. For this reason a boot directory must be created in the root directory of the btrfs filesystem and bound to a boot directory within the subvolume.}}<br />
<br />
Next we will create the subvolumes. To see all the commands available to manage subvolumes with btrfs:<br />
<br />
# btrfs subvolume --help<br />
<br />
To allow us to easily snapshot the root of our Arch Linux installation, it is recommended it be contained in a subvolume named {{ic|__active}}:<br />
<br />
{{Note|{{ic|__active}} is chosen for integration with current {{AUR|mkinitcpio-btrfs}}. See the variable reference above, or the source mkinitcpio-btrfs package.}}<br />
<br />
# btrfs subvolume create __active && cd __active<br />
<br />
Now we will create separate subvolumes for important [http://www.pathname.com/fhs/ FHS] directories. This would allow us to monitor and adjust the size allocations for each subvolume:<br />
<br />
# btrfs subvolume create home<br />
# btrfs subvolume create var<br />
# btrfs subvolume create usr<br />
<br />
To see your handy work:<br />
<br />
{{hc|# btrfs subvolume list -p .|<br />
ID 256 parent 5 top level 5 path __active<br />
ID 258 parent 256 top level 5 path __active/home<br />
ID 259 parent 256 top level 5 path __active/usr<br />
ID 260 parent 256 top level 5 path __active/var<br />
}}<br />
<br />
Fix the permissions:<br />
<br />
chmod 755 ../\__active var usr home<br />
<br />
Now that the subvolumes are created and we have a layout, lets mount the root subvolume directly:<br />
<br />
# mkdir /mnt/btrfs-active<br />
# mount -o defaults,discard,noatime,ssd,subvol=__active /dev/sda2 /mnt/btrfs-active && cd /mnt/btrfs-active<br />
<br />
{{Note|If you are not using an SSD drive, remove {{ic|discard,ssd}} from the mount options.}}<br />
<br />
And that's it! You should be ready to install a fresh copy of Arch Linux or restore from a backup. For example, if you made a tar backup with the techniques described above, simply:<br />
<br />
# tar -xvpJf <backup_file> -C .<br />
<br />
or if using rsync:<br />
<br />
# rsync -avhHPS --exclude={dev,sys,proc,mnt,tmp,media} <backup_dir> .<br />
<br />
=== btrfs and syslinux ===<br />
<br />
In order to continue the installation (or restoration), boot in the root of the btrfs filesystem must be bound to the boot directory contained in the {{ic|__active}} subvolume. First we should create a boot directory within the subvolume:<br />
<br />
# mkdir /mnt/btrfs-active/boot<br />
<br />
and then bind the two directories using mount:<br />
<br />
# mount --bind /mnt/btrfs-root/boot /mnt/btrfs-active/boot<br />
<br />
== Installing the base system ==<br />
<br />
{{Accuracy}}<br />
<br />
We will not be relying on AIF to do the install automatically and instead perform it manually.<br />
<br />
{{Note|The AIF is no longer supported. Installing manually is now the official way. See the [[Installation Guide]] for more info}}<br />
<br />
{{Note|You may need to uncomment a mirror from {{ic|/mnt/btrfs-active/etc/pacman.d/mirrorlist}}, and/or make other adjustments to {{ic|/mnt/btrfs-active/etc/pacman.conf}}.}}<br />
<br />
Lets begin by creating the necessary directories:<br />
<br />
# mkdir -p dev proc sys var/lib/pacman<br />
<br />
Now we bind the system directories to our installation directory:<br />
<br />
# mount -o bind /dev dev/<br />
# mount -t proc /proc proc/<br />
# mount -t sysfs /sys sys/<br />
<br />
Install base, btrfs-progs, and a bootloader (grub-bios, grub-efi, syslinux, etc). Switch {{ic|<boot_loader>}} to your preferred boot loader.<br />
<br />
Also install base-devel to build mkinitcpio-btrfs from the AUR.<br />
<br />
# pacman -r . -Sy base btrfs-progs mkinitcpio-btrfs <boot_loader> --ignore grub<br />
<br />
=== Configuration ===<br />
<br />
Once the you have successfully configured btrfs and installed (or recovered) your Arch Linux, it is important that we tweak some settings to get everything working together so when you reboot everything will work correctly.<br />
<br />
=== /etc/fstab ===<br />
<br />
This section has two different configurations depending on the bootloader you selected. We can begin by editing {{ic|/mnt/btrfs-active/etc/fstab}}:<br />
<br />
# nano /mnt/btrfs-active/etc/fstab<br />
<br />
==== GRUB2 ====<br />
<br />
Add the following line, supplement {{ic|<uuid>}} for the UUID of the btrfs root partition:<br />
<br />
UUID=<uuid> / btrfs defaults,noatime,discard,ssd,subvol=__active 0 0<br />
<br />
{{Note|If you are not using an SSD drive, remove {{ic|discard,ssd}} from the mount options.}}<br />
<br />
==== Syslinux ====<br />
<br />
{{Tip|Locations chosen for integration with upcoming release of mkinitcpio-btrfs}}<br />
<br />
Add everything to {{ic|/mnt/btrfs-active/etc/fstab}} ... {{ic|(btrfs-root)/boot}} will be --bind mounted so kernel upgrades work:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/disk/by-label/btrfs-root / btrfs defaults,noatime,subvolid=0 0 0<br />
/dev/disk/by-label/btrfs-root /var/lib/btrfs-root btrfs defaults,noatime 0 0<br />
/var/lib/btrfs-root/boot /boot none bind 0 0<br />
/var/lib/btrfs-root/empty/ /var/lib/btrfs-root/__active none bind 0 0}}<br />
<br />
It is not necessary to add a {{ic|1=subvol=XX}} option for /, as it '''must''' be handled by either the initramfs ''[btrfs_advanced]'' or via the kernel boot line ''[extlinux]'', and it may not be accurate anyways (e.g. rollback mode). {{ic|1=subvolid=0}} corresponds to the btrfs root, and guarantees it will always be mounted correctly, even if the default is changed.<br />
<br />
Optional bind an empty folder over the {{ic|/var/lib/btrfs-root/__active}} folder to prevent apps such as 'find' from complaining of any loops.<br />
<br />
==== mkinitcpio-btrfs ====<br />
<br />
Download the mkinitcpio-btrfs tarball:<br />
<br />
# wget -O /mnt/btrfs-active/root/mkinitcpio-btrfs.tar.gz https://aur.archlinux.org/packages/mk/mkinitcpio-btrfs/mkinitcpio-btrfs.tar.gz<br />
<br />
Add {{ic|btrfs_advanced}} to the {{ic|HOOKS}} section of {{ic|/mnt/btrfs-active/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|# nano /mnt/btrfs-active/etc/mkinitcpio.conf|2=<br />
...<br />
HOOKS="[...] btrfs_advanced"<br />
...}}<br />
<br />
Once you've chroot'ed into the btrfs installation, first install mkinitcpio-btrfs:<br />
<br />
# cd /root<br />
# tar -xvzf mkinitcpio-btrfs.tar.gz<br />
# cd mkinitcpio-btrfs<br />
# makepkg<br />
# pacman -U mkinitcpio-btrfs-${version}.pkg.tar.xz<br />
<br />
Then rebuild the initramfs:<br />
<br />
# mkinitcpio -p linux<br />
<br />
== Installing the bootloader ==<br />
<br />
If everything went smoothly (when does it ever?), you should have the great pleasure of installing your bootloader into the mbr of your root drive.<br />
<br />
=== GRUB ===<br />
<br />
See [[GRUB]] for advanced instructions. Once you have GRUB configured, and you chrooted into your install directory, install the boot loader.<br />
<br />
Chroot:<br />
<br />
If you decided that you liked your current Arch Linux and are restoring from a backup, you will need to chroot into your installation after doing all the necessary steps:<br />
<br />
# cp /etc/resolv.conf etc/<br />
# mount -o bind /dev dev/<br />
# mount -t proc /proc proc/<br />
# mount -t sysfs /sys sys/<br />
# chroot . /bin/bash<br />
<br />
And now:<br />
<br />
# grub-install --directory=/usr/lib/grub/i386-pc --target=i386-pc --boot-directory=/boot --recheck /dev/sda<br />
<br />
Don't forget to update {{ic|/boot/grub/grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
You should now be able to reboot into GRUB, provided there were no problems encountered doing the steps above.<br />
<br />
=== Syslinux ===<br />
<br />
Syslinux now has an automatic installer that creates the necessary folders, sets bootflags, installs MBR etc. See [[Syslinux#Automatic_Install]] for more info. Make sure you have /mnt bind mounted then run:<br />
<br />
# syslinux-install_update -iam<br />
<br />
Then edit the {{ic|syslinux.cfg}}:<br />
<br />
Sample config:<br />
<br />
{{hc|/boot/syslinux/syslinux.cfg|2=<br />
PROMPT 0<br />
TIMEOUT 0<br />
DEFAULT arch<br />
<br />
LABEL arch<br />
LINUX ../vmlinuz-linux<br />
APPEND root=/dev/disk/by-label/btrfs-root rootflags=subvol=__active ro<br />
INITRD ../initramfs-linux.img}}<br />
<br />
If you '''ARE''' using the mkinitcpio hook, remove {{ic|1=rootflags=subvol=__active}} from the APPEND line.<br />
<br />
== Final configuration ==<br />
<br />
Almost done... be sure to edit {{ic|/mnt/etc/rc.conf}}, set the root password, and similar. Good luck on reboot!<br />
<br />
# reboot<br />
<br />
== Known issues ==<br />
<br />
=== Rollback support ===<br />
<br />
Rollback support, while fully functional, currently has one important caveat... it '''cannot''' handle kernel rollbacks because the kernel is not a part of the snapshot. This is due to the limitations of the bootloader described above. Until bootloaders support subvolumes, you '''must''' remember to manually back up your kernel + initramfs before a snapshot. Upcoming releases of {{AUR|mkinitcpio-btrfs}} will attempt to address this shortcoming.<br />
<br />
=== Syslinux ===<br />
<br />
* Syslinux operates successfully through times, but sometimes fails.<br />
<br />
* Installing syslinux with compression enabled, or editing the configuration file after enabling compression, causes boot to fail because syslinux cannot read compressed files. This probably also affects installing a new kernel with btrfs enabled but I haven't tested this.<br />
<br />
=== Slow meta-data after installation ===<br />
<br />
Do a defragmentation of / after the installation is done to fix the slow metadata issue. (a simple {{ic|ls}} may take seconds)<br />
<br />
# btrfs filesystem defrag /</div>Buergihttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_from_existing_Linux&diff=238578Install Arch Linux from existing Linux2012-12-05T15:15:27Z<p>Buergi: restructure, cleanup and improve overview</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[de:Schnellinstallation von einem bestehenden Linuxsystem]]<br />
[[es:Install from Existing Linux]]<br />
[[fr:Install chroot]]<br />
[[it:Install from Existing Linux]]<br />
[[ru:Install from Existing Linux]]<br />
[[uk:Install from Existing Linux]]<br />
[[zh-CN:Install from Existing Linux]]<br />
[[zh-TW:Install from Existing Linux]]<br />
<br />
This guide is intended for anybody who wants to install Arch Linux from any other running Linux -- be it off a LiveCD or a pre-existing install of a different distro.<br />
<br />
This is useful for:<br />
* remotely installing Archlinux (e.g. a (virtual) root server)<br />
* creating a new linux distribution or LiveCD based on Archlinux<br />
* creating an Archlinux chroot environments<br />
* [[Diskless_network_boot_NFS_root|rootfs-over-NFS for diskless machines]]<br />
<br />
This guide requires that the existing host system be able to execute the new target Arch Linux architecture programs. In the case of an x86_64 host, it is possible to use i686-pacman to build a 32-bit chroot environment. See [[Arch64 Install bundled 32bit system]]. However it is not so easy to build a 64-bit environment when the host only supports running 32-bit programs.<br />
<br />
If you are already using Arch, instead of following this guide, just install {{Pkg|arch-install-scripts}} from the [[Official Repositories|official repositories]] and follow the [[Installation Guide]].<br />
<br />
'''This guide provides additional steps to the [[Installation Guide]]. The steps of that guide must still be followed as needed.'''<br />
<br />
==Prepare the system==<br />
<br />
Follow the [[Installation Guide]] steps, until you have your partitions, keyboard and internet connection ready.<br />
<br />
==Setup the environment for pacman==<br />
<br />
You need to create an environment where ''pacman'' and (optionally) the arch install scripts can run on your current linux distro.<br />
<br />
There are in principle two different methods to prepare that environment: either by '''installing pacman natively''' on your linux distro or by setting up a '''chroot environment'''.<br />
The latter way should in general be considered as easier.<br />
<br />
Considering the ''chroot'' way one further has two possibilities:<br />
* '''Using chroot as installation environment''': The prepared Archlinux chroot environment will be used temporarily to set up the actual Archlinux installation using the ''arch-install-scripts''. This is a bit more work and takes longer but once you set up the installation system you can quickly install Archlinux systems. '''However''', if you want to set up only a single Archlinux this might be overkill. You are actually setting up the system twice, have a lot more network traffic and especially need a lot more RAM, mostly due to the quite big iso image.<br />
<br />
* '''Installing Archlinux directly/Direct Bootstrapping''': Thanks to tokland's ''arch-bootstrap'' script this method is effectively a one-liner and very fast. After that one line of code your Archlinux base system is installed to disk. '''However''', when setting up multiple Archlinux the scripts downloads the base packages every time again.<br />
<br />
As a subjective conclusion, I, personally, would recommend using '''Direct bootstrapping''' as long as you want to set up only a small number of systems. If you set up lots of Archlinux based systems the chroot install environment or event the native pacman installation might suite you better.<br />
<br />
===Method 1: Directly bootstrapping Archlinux===<br />
<br />
This method will install a basic Archlinux system directly onto your previously prepared root file system mounted as {{ic|/mnt}}. This is known as [http://en.wikipedia.org/wiki/Bootstrapping#Computing bootstrapping].<br />
It is the recommended and easiest way to install an Archlinux from a foreign distribution.<br />
<br />
It is also possible to set up a separate chroot environment and run the archlinux installer from there, however in this case the first LiveCD-image method above is easier.<br />
<br />
This works best if you are in a LiveCD environment or, in the case of servers, a GNU/Linux-based rescue environment.<br />
<br />
As described in the [[Installation Guide]] we assume your disk which should become your root device is mountet at {{ic|/mnt}}. At first grab ''tokland's'' ''arch-bootstrap'' script, c.f. [[Archbootstrap]],<br />
<br />
# cd /tmp<br />
# wget http://tokland.googlecode.com/svn/trunk/archlinux/arch-bootstrap.sh<br />
# chmod +x arch-bootstrap.sh<br />
<br />
This script will bootstrap a basic archlinux system, i.e., it will download the linux kernel, pacman basic tools like bash and all needed dependencies and unpack them to the given directory, in this case {{ic|/mnt}}. <br />
<br />
{{Note|For an alternative, however, not so sophisticated script check out the [[#Appendix: Alternative Bootstrapping script|appendix]] of this article}}<br />
<br />
If you are wanting to install a 32-bit system:<br />
# ./arch-bootstrap.sh -a i686 -r "ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org" /mnt/<br />
Or a 64-bit system:<br />
# ./arch-bootstrap.sh -a x86_64 -r "ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org" /mnt/<br />
<br />
The bootstrapping will take 2-5 minutes depending on the speed of your system.<br />
<br />
If your LiveCD's architecture is not the same as the one of the newly bootstrapped system you might have to change the architecture in {{ic|/etc/pacman.conf}}.<br />
<br />
If your bootstrapped system is 32-bit system:<br />
Architecture = i686<br />
Or for a 64-bit system:<br />
Architecture = x86_64<br />
<br />
Before chrooting into the newly created system we need to set up some mount points.<br />
This is essential for the installation of a bootloader later on, c.f. [[Change Root]].<br />
# mount -t proc none /mnt/proc<br />
# mount -t sysfs none /mnt/sys<br />
# mount -o bind /dev /mnt/dev<br />
# mount -o bind /dev/pts /mnt/dev/pts # important for pacman (for signature check)<br />
<br />
Now everything is prepared to chroot into your newly installed Arch environment<br />
# chroot /mnt bash<br />
<br />
Before you can use ''pacman'' you have to initialize its keyring as explained below, in [[#Fix the Pacman Signature Keyring]].<br />
<br />
From here on proceed with [[Installation Guide#Install the base system]], '''but''' remember, you are already working in your final system, thus no need for {{ic|pacstrap}}, simply use {{ic|pacman}}. So the next command you are most likely to execute will be<br />
<br />
# pacman -S base # and evtl. also base-devel<br />
<br />
''Credit goes to [https://github.com/tokland Arnau Sanchez] alias tokland, the author of the arch-bootstrap script.''<br />
<br />
===Method 2: Chroot into LiveCD-image===<br />
<br />
It is possible to mount the root image of the latest Archlinux installation media and then chroot into it. This method has the advantage of providing you with a working Arch Linux installation right within your host system without the need to prepare it by installing specific packages.<br />
<br />
{{Note|Before proceeding, make sure the latest version of {{Pkg|squashfs-tools}} is installed on the host system. Otherwise you will get errors like: {{ic|FATAL ERROR aborting: uncompress_inode_table: failed to read block}}.}}<br />
<br />
Download the lastest installation CD image from https://www.archlinux.org/download/<br />
# wget http://{mirror-domain}/mirror/ftp.archlinux.org/iso/{date}/archlinux-{date}-dual.iso<br />
<br />
Mount the Live CD image:<br />
# mount -o loop archlinux-{date}-dual.iso /mnt<br />
<br />
The root image exists in squashfs format on the Live CD. The squashfs format is not editable as such. Hence, we unsquash the root image and then mount it.<br />
<br />
To unsquash the x86_64 (or i686 respectively) root image, run<br />
# unsquashfs -d /squashfs-root /mnt/arch/x86_64/root-image.fs.sfs<br />
<br />
Not you can unmount and remove the iso image<br />
# unmount /mnt<br />
# rm archlinux-{date}-dual.iso<br />
<br />
Now you can loop mount the root image<br />
# mount -o loop /squashfs-root/root-image.fs /arch<br />
<br />
Before chrooting to it we need to set up some mount points.<br />
This is essential for the installation of a bootloader later on, c.f. [[Change Root]].<br />
# mount -t proc none /arch/proc<br />
# mount -t sysfs none /arch/sys<br />
# mount -o bind /dev /arch/dev<br />
# mount -o bind /dev/pts /arch/dev/pts # important for pacman (for signature check)<br />
<br />
Now everything is prepared to chroot into your newly installed Arch environment<br />
# chroot /arch bash<br />
<br />
This chroot is able to execute the arch install scripts. The destination partitions should be mounted under the {{ic|/mnt}} directory from this chroot.<br />
<br />
<br />
===Method 3: Install pacman natively on non-arch distro (advanced)===<br />
{{Warning|This method is potentially difficult, your mileage may vary from distro to distro. If you just want to do an arch installation from another distro and you are not interested in have pacman as a regular program under such distro, is better to use a different method.}}<br />
<br />
This method is about installing pacman and the arch install scripts directly under another distro, so they become regular programs on that distro.<br />
<br />
This is really useful if you are planning to use another distro regularly to install arch linux, or do fancy things like updating packages of an arch installation using another distro. This is the only method that not imply creating a chroot to be able to execute pacman and the arch install scripts. (but since part of the installation includes entering inside a chroot, you'll end using a chroot anyway)<br />
<br />
==== Download pacman source code and pacman packages ====<br />
Visit the pacman homepage: https://www.archlinux.org/pacman/#_releases and download the latest release.<br />
<br />
Now, download the following packages:<br />
<br />
* pacman-mirrorlist: https://www.archlinux.org/packages/core/any/pacman-mirrorlist/download/<br />
* arch-install-scripts: https://www.archlinux.org/packages/extra/any/arch-install-scripts/download/<br />
* pacman (necessary for the config files): https://www.archlinux.org/packages/core/x86_64/pacman/download/ (change x86_64 as necessary)<br />
<br />
==== Install dependencies ====<br />
Using your distribution mechanisms, install the required packages for pacman and the arch install scripts. libcurl, libarchive, fakeroot, xz, asciidoc, wget, and sed are among them. Of course, gcc, make and maybe some other "devel" packages are necessary too.<br />
<br />
==== Compile pacman ====<br />
<br />
* Decompress the pacman source code and cd inside.<br />
* Execute configure, adapting the paths as necessary: {{bc|<nowiki> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-doc</nowiki>}}<br />
If you get errors here, chances are you are missing dependencies, or your current libcurl, libarchive or others, are too old. Install the dependencies missing using your distro options, or if they are too old, compile them from source.<br />
* Compile {{bc|make}}<br />
* If there were no errors, install the files {{bc|make install}}<br />
* You may need to manually call {{ic|ldconfig}} to make your distro detect libalpm.<br />
==== Prepare configuration files ====<br />
Now is time to extract the configuration files. Change the x86_64 as necessary.<br />
* Extract the pacman.conf and makepkg.conf files from the pacman package, and disable signature checking: {{bc|<nowiki>tar xJvf pacman-*-x86_64.pkg.tar.xz etc -C / ; sed -i 's/SigLevel.*/SigLevel = Never/g' /etc/pacman.conf</nowiki>}}<br />
* Extract the mirror list: {{bc|tar xJvf pacman-mirrorlist-*-any.pkg.tar.xz -C /}}<br />
* Enable some mirrors on {{ic|/etc/pacman.d/mirrorlist}}<br />
* Extract the arch-install-scripts {{bc|tar xJvf arch-install-scripts-*-any.pkg.tar.xz -C /}}<br />
<br />
Another option is using the {{ic|alien}} tool to convert the {{ic|pacman-mirrorlist}} and {{ic|arch-install-scripts}} (but no {{ic|pacman}}) to native packages of your distro.<br />
<br />
<br />
==Fix the Pacman Signature Keyring==<br />
<br />
It is necessary to initialize ''pacman's'' keyring for signature checking.<br />
<br />
This is done using<br />
# pacman-key --init # read the note below!<br />
# pacman-key --populate archlinux<br />
<br />
'''However''', when connected via SSH you might run out of [http://en.wikipedia.org/wiki/Entropy_(computing) entropy]. In this case you can try something like<br />
<br />
# cat /usr/bin/* > /dev/null &<br />
# find / > /dev/null &<br />
<br />
before executing {{ic|pacman-key --init}}.<br />
<br />
It might take some time. If nevertheless all this does help install {{Pkg|haveged}} and run prior to {{ic|pacman-key --init}}<br />
# /usr/sbin/haveged -w 1024 -v 1<br />
<br />
<br />
==Setup the target system==<br />
<br />
At this point, follow the normal steps of [[Installation Guide]]. Remember to mount the destination partition under the {{ic|/mnt}} of the chroot.<br />
<br />
# pacstrap /mnt base base-devel<br />
# # ...<br />
<br />
===Edit the fstab file===<br />
<br />
Probably the {{ic|genfstab}} script won't work. In that case, you'll need to edit the {{ic|/mnt/etc/fstab}} file by hand.<br />
You can use the content of {{ic|/etc/mtab}} as reference.<br />
<br />
===Finish the Installation===<br />
Now just do the rest of the steps normally.<br />
<br />
==Tips and tricks==<br />
* In case you want to replace an existing system, but can for some reason not use a LiveCD, since, e.g., you have no physical access to the computer, the following tip might help: If you manage to get ~500MB of free space somewhere on the disk (e.g. by partitioning a swap partition) you can install the new Archlinux system there, reboot into the newly created system and [[Full_System_Backup_with_rsync#With_a_single_command|rsync the entire system]] to the primary partition. Finally don't forget to fix the bootloader configuration before rebooting.<br />
<br />
==Appendix: Alternative Bootstrapping script==<br />
<br />
The script below is going to create a directory called {{ic|archinstall-pkg}} and download the required packages there. Then, is going to extract them into the {{ic|archinstall-chroot}} directory. Finally, is going to prepare mount points, configure pacman and enter into a chroot.<br />
<br />
This chroot is able to execute the arch install scripts. The destination partitions should be mounted under the {{ic|/mnt}} directory from this chroot.<br />
<br />
{{hc|archinstall-bootstrap.sh|<nowiki><br />
#!/bin/bash<br />
# This script is inspired on the archbootstrap script.<br />
<br />
PACKAGES=(acl attr bzip2 curl expat glibc gpgme libarchive libassuan libgpg-error libssh2 openssl pacman xz zlib pacman-mirrorlist coreutils bash grep gawk file tar ncurses readline libcap util-linux pcre arch-install-scripts)<br />
# Change the mirror as necessary<br />
MIRROR='http://mirrors.kernel.org/archlinux' <br />
# You can set the ARCH variable to i686 or x86_64<br />
ARCH=`uname -m`<br />
LIST=`mktemp`<br />
CHROOT_DIR=archinstall-chroot<br />
DIR=archinstall-pkg<br />
mkdir -p "$DIR"<br />
mkdir -p "$CHROOT_DIR"<br />
# Create a list with urls for the arch packages<br />
for REPO in core community extra; do <br />
wget -q -O- "$MIRROR/$REPO/os/$ARCH/" |sed -n "s|.*href=\"\\([^\"]*\\).*|$MIRROR\\/$REPO\\/os\\/$ARCH\\/\\1|p"|grep -v 'sig$'|uniq >> $LIST <br />
done<br />
# Download and extract each package.<br />
for PACKAGE in ${PACKAGES[*]}; do<br />
URL=`grep "$PACKAGE-[0-9]" $LIST|head -n1`<br />
FILE=`echo $URL|sed 's/.*\/\([^\/][^\/]*\)$/\1/'`<br />
wget "$URL" -c -O "$DIR/$FILE" <br />
xz -dc "$DIR/$FILE" | tar x -k -C "$CHROOT_DIR"<br />
done<br />
# Create mount points<br />
mkdir -p "$CHROOT_DIR/dev" "$CHROOT_DIR/proc" "$CHROOT_DIR/sys" "$CHROOT_DIR/mnt"<br />
mount -t proc proc "$CHROOT_DIR/proc/"<br />
mount -t sysfs sys "$CHROOT_DIR/sys/"<br />
mount -o bind /dev "$CHROOT_DIR/dev/"<br />
mkdir -p "$CHROOT_DIR/dev/pts"<br />
mount -t devpts pts "$CHROOT_DIR/dev/pts/"<br />
<br />
# Hash for empty password Created by doing: openssl passwd -1 -salt ihlrowCo and entering an empty password (just press enter)<br />
echo 'root:$1$ihlrowCo$sF0HjA9E8up9DYs258uDQ0:10063:0:99999:7:::' > "$CHROOT_DIR/etc/shadow"<br />
echo "root:x:0:0:root:/root:/bin/bash" > "$CHROOT_DIR/etc/passwd" <br />
touch "$CHROOT_DIR/etc/group"<br />
echo "myhost" > "$CHROOT_DIR/etc/hostname"<br />
test -e "$CHROOT_DIR/etc/mtab" || echo "rootfs / rootfs rw 0 0" > "$CHROOT_DIR/etc/mtab"<br />
[ -f "/etc/resolv.conf" ] && cp "/etc/resolv.conf" "$CHROOT_DIR/etc/"<br />
sed -ni '/^[ \t]*CheckSpace/ !p' "$CHROOT_DIR/etc/pacman.conf"<br />
sed -i "s/^[ \t]*SigLevel[ \t].*/SigLevel = Never/" "$CHROOT_DIR/etc/pacman.conf"<br />
echo "Server = $MIRROR/\$repo/os/$ARCH" >> "$CHROOT_DIR/etc/pacman.d/mirrorlist"<br />
<br />
chroot $CHROOT_DIR /usr/bin/pacman -Sy <br />
chroot $CHROOT_DIR /bin/bash<br />
</nowiki>}}</div>Buergihttps://wiki.archlinux.org/index.php?title=Graphics_tablet&diff=230488Graphics tablet2012-10-21T22:27:20Z<p>Buergi: totally restructured and reworked, remove some deprecated stuff, add new sections, especially about button mapping</p>
<hr />
<div>[[Category:Input devices]]<br />
== Introduction ==<br />
<br />
Before we begin, I would like to point out that this guide was started for ''USB'' based Wacom tablets, so much of the info in here focuses on that. Usually it's recommended to rely on ''Xorg's'' auto-detection or to use a '''dynamic''' setup.<br />
However for an ''internal'' tablet device one might consider a '''static''' Xorg setup in case autodetection does not work.<br />
A static ''Xorg'' setup is usually not able to recognize your Wacom tablet when it's connected to a different ''USB'' port or even after unplugging and replugging it into the same port, and as such it should be considered as deprecated.<br />
<br />
It is also worth to mention that this wiki article is very much influenced by the very helpful [http://en.gentoo-wiki.com/wiki/HOWTO_Wacom_Tablet Gentoo Linux Wiki - HOWTO Wacom Tablet], which I recommend anyone visit if they would like to learn about things that are not covered here.<br />
<br />
== Installing ==<br />
<br />
=== Check if kernel drivers needed (usually not) ===<br />
<br />
After plugging in the tablet (in case of a USB device) check {{ic|lsusb}} and/or {{ic|dmesg | grep -i wacom}} to see if the kernel recognizes your tablet. It should also be listed in {{ic|/proc/bus/input/devices}}.<br />
<br />
In case it's not recognized, which might happen for new devices not supported by current kernel, it is also possible to install git version of kernel driver from: stable branch ({{AUR|wacom-linux-git}}), next branch ({{AUR|wacom-next-linux-git}}) or mainline branch ({{AUR|wacom-mainline-linux-git}}).<br />
<br />
=== Install Wacom drivers ===<br />
<br />
Thanks to [http://linuxwacom.sourceforge.net The Linux Wacom Project], you only need to install the {{Pkg|xf86-input-wacom}} package, which contains everything needed to use a Wacom tablet on Linux.<br />
<br />
# pacman -S xf86-input-wacom<br />
<br />
{{Note|There is also {{AUR|xf86-input-wacom-git}} in AUR which provides git version of ''xf86-input-wacom'', but you might encounter some troubles. For me the buttons for example did only work with the stable release, not with the git version. So it's recommended to try ''xf86-input-wacom'' irst.}}<br />
<br />
<br />
=== Automatical setup ===<br />
<br />
Newer versions of X should be able to automatically detect and configure your device. Before going any further, reboot your system and (re-)start X. Test if your device was recognized completely (i.e., that both pen and eraser work, if applicable), by issuing command<br />
<br />
$ xsetwacom --list devices<br />
<br />
which should detect all devices with type, for example<br />
<br />
Wacom Bamboo 2FG 4x5 Pen stylus id: 8 type: STYLUS <br />
Wacom Bamboo 2FG 4x5 Pen eraser id: 9 type: ERASER <br />
Wacom Bamboo 2FG 4x5 Finger touch id: 13 type: TOUCH <br />
Wacom Bamboo 2FG 4x5 Finger pad id: 14 type: PAD <br />
<br />
You can also test it by opening {{Pkg|Gimp}} or {{Pkg|Xournal}} and checking the extended input devices section, or whatever tablet-related configuration is supported by the software of your choice.<br />
<br />
For this to work you don't need any {{ic|xorg.conf}} file, any configurations are made in files in the {{ic|/etc/X11/xorg.conf.d/}} folder.<br />
If everything is working you can skip the manual configuration and '''proceed''' to the configuration section to learn how to further customize your tablet.<br />
<br />
With the arrival of Xorg 1.8 support for [[HAL]] was dropped in favor of udev which might break auto-detection for some tablets as fitting udev rules might not exist yet, so you may need to write your own.<br />
<br />
If you have {{Pkg|linuxwacom}} or {{Pkg|linuxwacom-dev}} remove those packages first. They are known to cause problems with newer version of X. ''xf86-input-wacom'' is the only package you need to install the X11 drivers.<br />
<br />
<br />
=== Manual setup ===<br />
A manual configuration is done in {{ic|/etc/X11/xorg.conf}} or in a separate file in the {{ic|/etc/X11/xorg.conf.d/}} directory.<br />
The Wacom tablet device is accessed using a input event interface in {{ic|/dev/input/}} which is provided by the kernel driver.<br />
The interface number {{ic|event??}} is likely to change when unplugging and replugging into the same or especially a different ''USB'' port.<br />
Therefore it's wise to don't refer to the device using it's concrete {{ic|event??}} interface ('''static''' configuration) but by letting ''udev'' dynamically create a symbolic link to the correct {{ic|event}} file ('''dynamic''' configuration).<br />
<br />
====Dynamic with udev====<br />
{{Note|In AUR there is wacom-udev package, which includes udev-rules-file. You might skip this part and move on to the {{ic|xorg.conf}} configuration if you are using the wacom-udev package from AUR.}}<br />
<br />
Assuming ''udev'' is already installed you simply need to install {{AUR|wacom-udev}} from AUR, e.g. by using<br />
$ yaourt -S wacom-udev<br />
<br />
=====USB-devices=====<br />
After (re-)plugging in your ''USB''-tablet (or at least after rebooting) some symbolic links should appear in {{ic|/dev/input}} refering to your tablet device.<br />
<br />
$ ls /dev/input/wacom* <br />
/dev/input/wacom /dev/input/wacom-stylus /dev/input/wacom-touch<br />
<br />
If not, your device is likely to be not yet included in the ''udev'' configuration from ''wacom-udev'' which resides in {{ic|/usr/lib/udev/rules.d/10-wacom.rules}}. It's a good idea to copy the file e.g. to {{ic|10-my-wacom.rules}} before modifiing it, else it might be reverted by a package upgrade.<br />
<br />
Add your device to the file by duplicating some line of another device and adapting ''idVendor'',''idProduct'' and the symlink name to your device.<br />
The two id's can by determined using<br />
<br />
$ lsusb | grep -i wacom<br />
Bus 002 Device 007: ID 056a:0062 Wacom Co., Ltd<br />
<br />
In this example idVendor is 056a and idProduct 0062.<br />
In case you have device with touch (e.g. Bamboo Pen&Touch) you might need to add a second line for the touch input interface.<br />
For details check the linuxwacom wiki [http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Fixed_device_files_with_udev Fixed device files with udev].<br />
<br />
Save the file and reload udev's configuration profile using the command ''udevadm control --reload-rules''<br />
Check again the content of ''/dev/input'' to make sure that the ''wacom'' symlinks appeared.<br />
Note that you may need to plug-in the tablet again for the device to appear.<br />
<br />
The files of further interest for the ''Xorg'' configuration are {{ic|/dev/input/wacom}} and for a touch-device also {{ic|/dev/input/wacom_touch}}.<br />
<br />
=====Serial devices=====<br />
The {{AUR|wacom-udev}} should also include support for serial devices. Users of serial tablets might be also interested in the inputattach tool from {{AUR|linuxconsole}} package. The inputattach command allows to bind serial device into /dev/input tree, for example with:<br />
<br />
# inputattach --w8001 /dev/ttyS0<br />
<br />
See ''man inputattach'' for help about available options.<br />
As for USB devices one should end up with a file {{ic|/dev/input/wacom}} and proceed with the ''Xorg'' configuration.<br />
<br />
====Static setup====<br />
If you insist in using a static setup just refer to your tablet in the ''Xorg'' configuration in the next section using the correct {{ic|/dev/input/event??}} files as one can find out by looking into {{ic|/proc/bus/input/devices}}.<br />
<br />
====Xorg configuration====<br />
<br />
In either case, dynamic or static setup you got now one or two files in {{ic|/dev/input/}} which refer to the correct input event devices of your tablet. All that is left to do is add the relevent information to {{ic|/etc/X11/xorg.conf}}, or a dedicated file under {{ic|/etc/X11/xorg.conf.d/}}.<br />
The exact configuration depends on your tablet's features of course. {{ic|xsetwacom --list devices}} might give helpful informations on what ''InputDevice'' sections are needed for your tablet.<br />
<br />
An example configuration for a ''Volito2'' might look like this<br />
<br />
Section "InputDevice"<br />
Driver "wacom"<br />
Identifier "stylus"<br />
Option "Device" "/dev/input/wacom" # or the corresponding event?? for a static setup<br />
Option "Type" "stylus"<br />
Option "USB" "on" # USB ONLY<br />
Option "Mode" "Relative" # other option: "Absolute"<br />
Option "Vendor" "WACOM"<br />
Option "tilt" "on" # add this if your tablet supports tilt<br />
Option "Threshold" "5" # the official linuxwacom howto advises this line<br />
EndSection<br />
Section "InputDevice"<br />
Driver "wacom"<br />
Identifier "eraser"<br />
Option "Device" "/dev/input/wacom" # or the corresponding event?? for a static setup<br />
Option "Type" "eraser"<br />
Option "USB" "on" # USB ONLY<br />
Option "Mode" "Relative" # other option: "Absolute"<br />
Option "Vendor" "WACOM"<br />
Option "tilt" "on" # add this if your tablet supports tilt<br />
Option "Threshold" "5" # the official linuxwacom howto advises this line<br />
EndSection<br />
Section "InputDevice"<br />
Driver "wacom"<br />
Identifier "cursor"<br />
Option "Device" "/dev/input/wacom" # or the corresponding event?? for a static setup<br />
Option "Type" "cursor"<br />
Option "USB" "on" # USB ONLY<br />
Option "Mode" "Relative" # other option: "Absolute"<br />
Option "Vendor" "WACOM"<br />
EndSection<br />
<br />
Make sure that you also change the path ({{Ic|"Device"}}) to your mouse, as it will be {{Ic|/dev/input/mouse_udev}} now.<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse1"<br />
Driver "mouse"<br />
Option "CorePointer"<br />
Option "Device" "/dev/input/mouse_udev"<br />
Option "SendCoreEvents" "true"<br />
Option "Protocol" "IMPS/2"<br />
Option "ZAxisMapping" "4 5"<br />
Option "Buttons" "5"<br />
EndSection<br />
Add this to the ''ServerLayout'' section<br />
<br />
InputDevice "cursor" "SendCoreEvents" <br />
InputDevice "stylus" "SendCoreEvents"<br />
InputDevice "eraser" "SendCoreEvents"<br />
And finally make sure to update the indentifier of your mouse in the ''ServerLayout'' section &ndash; as mine went from<br />
<br />
InputDevice "Mouse0" "CorePointer"<br />
to<br />
<br />
InputDevice "Mouse1" "CorePointer"<br />
<br />
== Configuration ==<br />
<br />
=== General concepts ===<br />
<br />
The configuration can be done in two ways temporary using the `xsetwacom` tool, which is included in ''xf86-input-wacom'' or permanent in {{ic|xorg.conf}} or better in a extra file in {{ic|/etc/X11/xorg.conf.d}}.<br />
The possible options are identical so it's recommended to first use `xsetwacom` for testing and later add the final config to the ''Xorg'' configuration files.<br />
<br />
==== Temporary configuration ====<br />
<br />
For the beginning it's a good idea to inspect the default configuration and all possible options using the following commands.<br />
<br />
$ xsetwacom --list devices # list the available devices for the get/set commands<br />
Wacom Bamboo 16FG 4x5 Finger touch id: 12 type: TOUCH<br />
Wacom Bamboo 16FG 4x5 Finger pad id: 13 type: PAD <br />
Wacom Bamboo 16FG 4x5 Pen stylus id: 17 type: STYLUS <br />
Wacom Bamboo 16FG 4x5 Pen eraser id: 18 type: ERASER<br />
$ xsetwacom --get "Wacom Bamboo 16FG 4x5" all # using the device name<br />
$ xsetwacom --get 17 all # or equivalently use the device id<br />
$ xsetwacom --list parameters # to get an explanation of the Options<br />
$ man wacom # get even more details<br />
<br />
'''Caution''', don't use the device id when writing shell scripts to set some options as the ids might change after an hotplug.<br />
<br />
Options can be changed with the {{ic|--set}} flag. Some useful examples are<br />
<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger touch" ScrollDistance 50 # change scrolling speed<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger touch" Gesture off # disable multitouch gestures<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger touch" Touch off # disable touch<br />
<br />
For further configuration tips and tricks see below in [[#Specific configuration tips]].<br />
{{Note|You can reset your temporary configuration at any time by unplugging and replugging in your tablet.}}<br />
<br />
==== Permanent configuration ====<br />
<br />
To make a permanent configuration the preferred way for ''Xorg''>1.8 is to create a new file in {{ic|/etc/X11/xorg.conf.d}}<br />
e.g. {{ic|52-wacom-options.conf}} with the following content.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/52-wacom-options.conf|<br />
Section "InputClass"<br />
Identifier "Wacom Bamboo stylus options"<br />
MatchDriver "wacom"<br />
MatchProduct "Pen"<br />
<br />
# Apply custom Options to this device below.<br />
Option "Rotate" "none"<br />
Option "RawSample" "20"<br />
Option "PressCurve" "0,10,90,100"<br />
EndSection<br />
<br />
Section "InputClass"<br />
Identifier "Wacom Bamboo eraser options"<br />
MatchDriver "wacom"<br />
MatchProduct "eraser"<br />
<br />
# Apply custom Options to this device below.<br />
Option "Rotate" "none"<br />
Option "RawSample" "20"<br />
Option "PressCurve" "5,0,100,95"<br />
EndSection<br />
<br />
Section "InputClass"<br />
Identifier "Wacom Bamboo touch options"<br />
MatchDriver "wacom"<br />
MatchProduct "Finger"<br />
<br />
# Apply custom Options to this device below.<br />
Option "Rotate" "none"<br />
Option "ScrollDistance" "18"<br />
Option "TapTime" "220"<br />
EndSection<br />
<br />
Section "InputClass"<br />
Identifier "Wacom Bamboo pad options"<br />
MatchDriver "wacom"<br />
MatchProduct "pad"<br />
<br />
# Apply custom Options to this device below.<br />
Option "Rotate" "none"<br />
<br />
# Setting up buttons<br />
Option "Button1" "1"<br />
Option "Button2" "2"<br />
Option "Button3" "3"<br />
Option "Button4" "0"<br />
EndSection<br />
}}<br />
<br />
The identifiers can be set arbitrarily. The option names are (except for the buttons) identical to the ones listed by {{ic|xsetwacom --list parameters}} and especially also in {{ic|man wacom}}. As noted in [[#Remapping Buttons]] the button ids seem to be different than the ones for {{ic|xsetwacom}}.<br />
<br />
=== Specific configuration tips ===<br />
<br />
Check out the [[http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Linuxwacom_HOWTO Howto section]] in the Linuxwacom wiki.<br />
<br />
==== Changing orientation ====<br />
<br />
If you want to use your tablet in a different orientation you have to tell this to the driver, else the movements don't cause the expected results.<br />
This is done by setting the '''Rotate''' option for all devices. Possible orientations are '''none''','''cw''','''ccw''' and '''half'''.<br />
A quick way is e.g.<br />
$ for i in 12 13 17 18; do xsetwacom --set $i Rotate half; done # remember the ids might change when hotplugging<br />
<br />
or use the following script like this {{ic|./wacomrot.sh half}}<br />
<br />
{{hc|1=wacomrot.sh|2=<br />
#!/bin/bash<br />
device="Wacom Bamboo 16FG 4x5"<br />
stylus="$device Pen stylus"<br />
eraser="$device Pen eraser"<br />
touch="$device Finger touch"<br />
pad="$device Finger pad"<br />
<br />
xsetwacom --set "$stylus" Rotate $1<br />
xsetwacom --set "$eraser" Rotate $1<br />
xsetwacom --set "$touch" Rotate $1<br />
xsetwacom --set "$pad" Rotate $1<br />
}}<br />
<br />
==== Remapping Buttons ====<br />
<br />
It's possible to remap the buttons with hotkeys.<br />
<br />
===== Finding out the button IDs =====<br />
Sometimes it needs some trial&error to find the correct button IDs. For me they even differ for {{ic|xsetwacom}} and the {{ic|xorg.conf}} configuration. Very helpful tools are {{ic|xev}} or {{ic|xbindkeys -mk}}. An easy way to proceed is the following<br />
<br />
$ xsetwacom --get "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 1<br />
$ xsetwacom --get "Wacom Bamboo 16FG 4x5 Finger pad" Button 2 2<br />
$ xsetwacom --get "Wacom Bamboo 16FG 4x5 Finger pad" Button 3 3<br />
$ # and so on<br />
<br />
Then fire up {{ic|xev}} from a terminal window, place your mouse cursor above the window and hit the buttons and write down the ids.<br />
<br />
===== The syntax =====<br />
<br />
The syntax of {{ic|xsetwacom}} is flexible but not very well documented. The general mapping syntax (extracted from the source code) for xsetwacom 0.17.0 is the following.<br />
<br />
KEYWORD [ARGS...] [KEYWORD [ARGS...] ...]<br />
<br />
KEYWORD + ARGS:<br />
key [+,-]KEY [[+,-]KEY ...] where +:key down, -:key up, no prefix:down and up<br />
button BUTTON [BUTTON ...] (1=left,2=middle,3=right mouse button, 4/5 scroll mouse wheel)<br />
modetoggle toggle absolute/relative tablet mode <br />
displaytoggle toggle cursor movement among all displays which include individual screens<br />
plus the whole desktop for the selected tool if it is not a pad.<br />
When the tool is a pad, the function applies to all tools that are asssociated<br />
with the tablet<br />
<br />
BUTTON: button ID as integer number<br />
<br />
KEY: MODIFIER, SPECIALKEY or ASCIIKEY<br />
MODIFIER: (each can be prefix with an '''l''' or an '''r''' for the left/right modifier (no prefix = left)<br />
ctrl=ctl=control, meta, alt, shift, super, hyper<br />
SPECIALKEY: f1-f35, esc=Esc, up,down,left,right, backspace=Backspace, tab, PgUp,PgDn<br />
ASCIIKEY: (usual characters the key produces, e.g. a,b,c,1,2,3 etc.)<br />
<br />
===== Some examples =====<br />
<br />
$ xsetwacom --get "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 3 # right mouse button<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 "key +ctrl z -ctrl"<br />
$ xsetwacom --get "Wacom Bamboo 16FG 4x5 Finger pad" Button 1<br />
key +Control_L +z -z -Control_L<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 "key +shift button 1 key -shift"<br />
<br />
even little macros are possible<br />
<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 "key +shift h -shift e l l o"<br />
<br />
{{Note|There seems to be a bug in the ''xf86-input-wacom'' driver version 0.17.0, at least for my ''Wacom Bamboo Pen & Touch'', but I guess this holds in general. It causes the keystrokes not to be overwritten correctly.<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 "key a b c" # press button 1 -> abc<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 "key d" # press button 1 -> dbc WRONG!<br />
<br />
A simple workaround is to reset the mapping by mapping to "":<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 "" # to reset the mapping<br />
$ xsetwacom --set "Wacom Bamboo 16FG 4x5 Finger pad" Button 1 "key d" # press button 1 -> d<br />
<br />
}}<br />
<br />
===== Execute custom commands =====<br />
<br />
Mapping custom commands to the buttons is a little bit tricky but actually very simple. You'll need {{Pkg|xbindkeys}} so install it using<br />
# pacman -S xbindkeys<br />
<br />
To get well defined button codes add the following to your permanent configuration file, e.g. {{ic|/etc/X11/xorg.conf.d/52-wacom-options.conf}}<br />
in the InputClass section of your '''pad''' device. Map the tablet's buttons to some unused button ids.<br />
<br />
# Setting up buttons (preferably choose the correct button order, so the topmost key is mapped to 10 and so on)<br />
Option "Button1" "10"<br />
Option "Button2" "11"<br />
Option "Button3" "12"<br />
Option "Button4" "13"<br />
<br />
Then restart your ''Xorg'' server and verify the buttons using {{ic|xev}} or {{ic|xbindkeys -mk}}.<br />
<br />
Now set up your xbindkeys configuration, if you don't already have one you might want to create a default configuration<br />
$ xbindkeys --defaults > ~/.xbindkeysrc<br />
<br />
Then add your custom key mapping to {{ic|~/.xbindkeysrc}}, for example<br />
<br />
"firefox"<br />
m:0x10 + b:10 (mouse)<br />
"xterm"<br />
m:0x10 + b:11 (mouse)<br />
"xdotool key ctrl-z"<br />
m:0x10 + b:12 (mouse)<br />
"send-notify Test "No need for escaping the quotes""<br />
m:0x10 + b:13 (mouse)<br />
<br />
===== Application specific hotkeys =====<br />
<br />
This is quite tricky as the usual tools don't allow application specific hotkeys.<br />
However I found the idea quite appealing to use the buttons for different thinks depending on the application.<br />
<br />
To make this possible I use a python script which uses {{Pkg|xorg-xprop}}, {{Pkg|xdotools}} and the custom commands setup from the last section, which depends on {{Pkg|xbindkeys}}.<br />
<br />
Change the mappings in {{ic|~/.xbindkeysrc}}<br />
<br />
"appkey 1"<br />
m:0x10 + b:10 (mouse)<br />
"appkey 2"<br />
m:0x10 + b:11 (mouse)<br />
"appkey 3"<br />
m:0x10 + b:12 (mouse)<br />
"appkey 4"<br />
m:0x10 + b:13 (mouse)<br />
<br />
And copy the following script to a file named {{ic|appkey}} somewhere in your path ({{ic|$PATH}}) and make it executable using<br />
chmod 755 /usr/local/bin/appkey<br />
<br />
{{hc|1=/usr/local/bin/appkey|2=<br />
#!/usr/bin/python<br />
# written in 2012 by buergi<br />
# this script is public domain, no rights reserved, CC0<br />
# do with it whatever you want<br />
<br />
import sys<br />
from subprocess import Popen,PIPE<br />
<br />
def get_active_window_class(sep=':'):<br />
p = Popen(['xdotool', 'getactivewindow'], stdout=PIPE)<br />
winid = p.communicate()[0]<br />
p = Popen(['xprop', '-id', winid, 'WM_CLASS'], stdout=PIPE)<br />
<br />
try:<br />
out = p.communicate()[0].decode('ascii')<br />
except UnicodeDecodeError as e:<br />
return ''<br />
<br />
try:<br />
tmp = out.split(' = ',1)[1]<br />
winclass = sep.join(tmp.split('", "'))[1:-2]<br />
except IndexError as e:<br />
return ''<br />
<br />
return winclass<br />
<br />
def send_key(keystroke):<br />
Popen(['xdotool', 'key', keystroke])<br />
<br />
def main(argc,argv):<br />
key=0<br />
if argc==2:<br />
key=argv[1]<br />
else:<br />
print("Usage: %s KEY"%argv[0])<br />
<br />
cls = get_active_window_class()<br />
if 'Firefox' in cls: # my configuration for Pentadactyl<br />
if key=='1':<br />
send_key('shift+h')<br />
if key=='2':<br />
send_key('shift+l')<br />
if key=='3':<br />
send_key('Escape')<br />
send_key('r')<br />
if 'Inkscape' in cls:<br />
if key=='1':<br />
send_key('F1')<br />
if key=='2':<br />
send_key('F2')<br />
if key=='3':<br />
send_key('ctrl+F6')<br />
if key=='4':<br />
# toggle finger touch<br />
p=Popen(['xsetwacom','--get','Wacom Bamboo 16FG 4x5 Finger touch','Touch'],stdout=PIPE)<br />
stat = p.communicate()[0].decode('ascii').strip()<br />
istat = 'on' if 'off' in stat else 'off'<br />
Popen(['xsetwacom','--set','Wacom Bamboo 16FG 4x5 Finger touch','Touch',istat])<br />
return 0<br />
<br />
if __name__ == '__main__':<br />
main(len(sys.argv),sys.argv)<br />
}}<br />
<br />
<br />
==== TwinView Setup ====<br />
<br />
If you are going to use two Monitors the aspect ratio while using the Tablet might feel unnatural. In order to fix this you need to add<br />
<br />
Option "TwinView" "horizontal"<br />
<br />
To all of your Wacom-InputDevice entries in the {{ic|xorg.conf}} file.<br />
You may read more about that [http://ubuntuforums.org/showthread.php?t=640898 HERE]<br />
<br />
==== Xrandr Setup ====<br />
xrandr sets two monitors as one big screen, mapping the tablet to the whole virtual screen and deforming aspect ratio.<br />
For a solution see this thread: [https://bbs.archlinux.org/viewtopic.php?pid=797617 archlinux forum].<br />
<br />
If you just want to map the tablet to one of your screens, first find out what the screens are called<br />
$ xrandr<br />
Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 16384 x 16384<br />
'''HDMI-0''' disconnected (normal left inverted right x axis y axis)<br />
'''DVI-0''' connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm<br />
1920x1080 60.0*+<br />
1680x1050 60.0 <br />
...<br />
'''VGA-0''' connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 477mm x 268mm<br />
1920x1080 60.0*+<br />
1680x1050 60.0 <br />
...<br />
Then you need to know what is the ID of your tablet.<br />
$ xsetwacom --list devices<br />
WALTOP International Corp. Slim Tablet stylus id: '''12''' type: STYLUS<br />
<br />
In my case I want to map the tablet (ID: '''12''') to the screen on the right, which is '''"VGA-0"'''. I can do that with this command<br />
$ xsetwacom --set '''12''' MapToOutput '''"VGA-0"'''<br />
This should immediately work, no root necessary.<br />
<br />
If xsetwacom replies with "Unable to find an output ..." an X11 geometry string of the form '''WIDTHxHEIGHT+X+Y''' can be specified instead of the screen identifier. In this example<br />
$ xsetwacom --set '''12''' MapToOutput '''"1920x1080+1920+0"'''<br />
should also map the tablet to the screen on the right.<br />
<br />
=== Pressure curves ===<br />
<br />
You can add two options to xorg.conf to change how the pressure is registered when putting pressure on the pen. Example:<br />
<br />
Option "PressCurve" "50,0,100,50" # Custom preference<br />
Option "Threshold" "60" # sensitivity to do a "click"<br />
<br />
== Application-specific configuration ==<br />
<br />
=== The GIMP ===<br />
<br />
To enabled proper usage, and pressure sensitive painting in [http://www.gimp.org The GIMP], just go to ''Preferences &rarr; Input Devices &rarr; Configure Extended Input Devices...''. Now for each of your ''eraser'', ''stylus'', and ''cursor'' '''devices''', set the '''mode''' to ''Screen'', and remember to save.<br />
<br />
*Please take note that if present, the ''pad'' '''device''' should be kept disabled as I do not think The GIMP supports such things. Alternatively, to use such features of your tablet you should map them to keyboard commands with a program such as [http://hem.bredband.net/devel/wacom/ Wacom ExpressKeys].<br />
<br />
*You should also take note that the tool selected for the ''stylus'' is independent to that of the ''eraser''. This can actually be quite handy, as you can have the ''eraser'' set to be used as any tool you like.<br />
<br />
For more information checkout the ''Setting up GIMP'' section of [http://www.gimptalk.com/forum/topic.php?t=17992&start=1 GIMP Talk - Community - Install Guide: Getting Wacom Drawing Tablets To Work In Gimp].<br />
<br />
=== Inkscape ===<br />
<br />
As in The GIMP, to do the same simply got to ''File &rarr; Input Devices...''. Now for each of your ''eraser'', ''stylus'', and ''cursor'' '''devices''', set the '''mode''' to ''Screen'', and remember to save.<br />
<br />
=== Krita ===<br />
<br />
Krita 2.0 and later only require that QT is able to use your tablet to function properly. If your tablet is not working in Krita, then make sure to check it is working in QT first. The effect of tablet pressure can then be tweaked in the painttop configuration, for example by selecting opacity, then selecting pressure from the drop down and adjusting the curve to your preference.<br />
<br />
For earlier versions of Krita, simply go to ''Settings &rarr; Configure Krita...'' Click on ''Tablet'' and then like in Inkscape and GIMP set ''stylus'' and any others' mode to screen.<br />
<br />
=== VirtualBox ===<br />
<br />
''My current setup is :<br />
Guest OS: Windows XP<br />
Tablet: Wacom Graphire4<br />
Linux Driver: xf86-input-wacom 0.8.4-1''<br />
<br />
First, make sure that your tablet works well under Arch. Then, download and install the last driver from [http://www.wacom.com/downloads/drivers.php Wacom website] on the guest OS. Shutdown the virtual machine, go to '''Settings > USB'''. Select '''Add Filter From Device''' and select your tablet (e.g. WACOM CTE-440-U V4.0-3 [0403]). Select '''Edit Filter''', and change the last item '''Remote''' to '''Any'''.<br />
<br />
<br />
==Newer tablets & Troubleshooting==<br />
<br />
Newer tablets's drivers might not be in the kernel yet, and additional manipulations might be needed.<br />
For example, for the Wacom Bamboo Connect CTL-470/k and Pen & Touch CTH670, follow the instructions in [https://bbs.archlinux.org/viewtopic.php?id=131831 this thread].<br />
'''There seems to be a problem with the CTH670 that is fixed in the attachment found in [http://www.mail-archive.com/linuxwacom-devel@lists.sourceforge.net/msg03922.html this post]'''<br />
To compile it use the same instructions as in [https://bbs.archlinux.org/viewtopic.php?id=131831 this thread]<br />
<br />
<br />
==Dynamic Xorg setup with HAL (deprecated)==<br />
{{Out of date|HAL support was dropped in Xorg 1.8 which entered the repos in June 2010, it should not be used anymore}}<br />
<br />
<br />
{{Note | In Xorg 1.8 and later, support for HAL is dropped. Input hotplugging will ''NOT'' work with these versions of X, you need to use udev (see above) instead. }}<br />
{{Note | The linuxwacom package from AUR already includes a fitting fdi file, so you might skip this part and just try out if it works after installing linuxwacom and restarting X.}}<br />
<br />
To use a Wacom/WALTOP/N-Trig tablet with HAL Xorg hotplugging create {{ic|/etc/hal/fdi/policy/10-tablet.fdi}} with this code:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?> &lt;!-- -*- SGML -*- --><br />
<br />
<deviceinfo version="0.2"><br />
<device><br />
<match key="info.capabilities" contains="input"><br />
<match key="info.product" contains="Wacom"><br />
<merge key="input.x11_driver" type="string">wacom</merge><br />
<merge key="input.x11_options.Type" type="string">stylus</merge><br />
</match><br />
<match key="info.product" contains="WALTOP"><br />
<merge key="input.x11_driver" type="string">wacom</merge><br />
<merge key="input.x11_options.Type" type="string">stylus</merge><br />
</match><br />
</match><br />
<!-- N-Trig Duosense Electromagnetic Digitizer --><br />
<match key="info.product" contains="HID 1b96:0001"><br />
<match key="info.parent" contains="if0"><br />
<merge key="input.x11_driver" type="string">wacom</merge><br />
<merge key="input.x11_options.Type" type="string">stylus</merge><br />
</match><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
Then kill your X server, restart HAL and start the X server again.<br />
<br />
Following fdi file is known to work with the Bamboo Fun tablet (model CTE-650). Using this file corrects several problems with the stylus that appear when using the default fdi file above. Create the file {{ic|/etc/hal/fdi/policy/10-tablet.fdi}} with the following contents:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!-- this is probably a bit imprecise --><br />
<deviceinfo version="0.2"><br />
<device><br />
<match key="info.category" contains="input"><br />
<match key="info.product" contains_outof="Wacom"><br />
<merge key="input.x11_driver" type="string">wacom</merge><br />
<merge key="input.x11_options.Type" type="string">pad</merge><br />
<append key="info.callouts.add" type="strlist">hal-setup-wacom</append><br />
<append key="wacom.types" type="strlist">eraser</append><br />
<append key="wacom.types" type="strlist">cursor</append><br />
<append key="wacom.types" type="strlist">stylus</append><br />
</match><br />
</match><br />
<match key="info.capabilities" contains="serial"><br />
<match key="@info.parent:pnp.id" contains_outof="WACf001;WACf002;WACf003;WACf004;WACf005;WACf006;WACf007;WACf008;WACf009;WACf00a;WACf00b;WACf00c;FUJ02e5"><br />
<append key="info.capabilities" type="strlist">input</append><br />
<merge key="input.x11_driver" type="string">wacom</merge><br />
<merge key="input.x11_options.Type" type="string">pad</merge><br />
<merge key="input.x11_options.ForceDevice" type="string">ISDV4</merge><br />
<merge key="input.device" type="copy_property">serial.device</merge><br />
<append key="info.callouts.add" type="strlist">hal-setup-wacom</append><br />
<append key="wacom.types" type="strlist">stylus</append><br />
<match key="@info.parent:pnp.id" contains_outof="WACf008;WACf009"><br />
<!-- Serial tablets with touch capabilities --><br />
<append key="wacom.types" type="strlist">touch</append><br />
</match><br />
</match><br />
</match><br />
</device><br />
<!-- Match the Wacom Bluetooth A5 pen tablet --><br />
<device><br />
<match key="info.capabilities" contains="input.mouse"><br />
<match key="info.product" contains="WACOM"><br />
<match key="info.product" contains="Tablet"><br />
<merge key="input.x11_driver" type="string">wacom</merge><br />
<merge key="input.x11_options.Type" type="string">pad</merge><br />
<append key="info.callouts.add" type="strlist">hal-setup-wacom</append><br />
<append key="wacom.types" type="strlist">eraser</append><br />
<append key="wacom.types" type="strlist">cursor</append><br />
<append key="wacom.types" type="strlist">stylus</append><br />
</match><br />
</match><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
=== HAL tablet calibration fix ===<br />
<br />
In order for calibration to work even when the screen is rotated (this applies for both serial and USB tablets), the wacom-names script is useful. It renames your X input devices so that they can be recognized by the linuxwacom driver. Download it from [http://ubuntuforums.org/attachment.php?attachmentid=109824&d=1239742307 here]. You need to be a Ubuntu forums member to download it. If you are not, here is the script. Remember, it was originally intended for Ubuntu so the instructions do not all apply to us Archers:<br />
<br />
# wacom-names script by Roger E. Critchlow, Jr. (4-12-09)<br />
# modified by gali98/Favux (4-14-09)<br />
#<br />
# Place the wacom-names script in /etc/init.d/wacom-names and link it as<br />
# /etc/rc{2,3,4,5}.d/S27wacom-names.<br />
# Use "sudo update-rc.d wacom start 27 2 3 4 5 ." or "sudo update-rc.d wacom defaults 27".<br />
# Using S27 starts the script after hal and before gdm. This allows us to modify the hal<br />
# properties before the xserver sees them for the first time.<br />
#<br />
# The script renames the input devices back to what wacomcpl and xsetwacom expect them to<br />
# be, so rotation and interactive calibration work. It also enables xorg.conf & .xinitrc<br />
# style configuration of Wacom features like the stylus button(s) and calibration.<br />
#<br />
# The script needs to be executable. chmod +x wacom-names<br />
<br />
#! /bin/sh<br />
## find any wacom devices<br />
for udi in `hal-find-by-property --key input.x11_driver --string wacom`<br />
do<br />
type=`hal-get-property --udi $udi --key input.x11_options.Type`<br />
## rewrite the names that the Xserver will use<br />
hal-set-property --udi $udi --key info.product --string $type<br />
#<br />
## To add a xorg.conf or xsetwacom (.xinitrc) style configuration, say mapping a stylus<br />
## button, you could add to the script:<br />
#case $type in<br />
#stylus|eraser)<br />
## eg: map stylus button 2 to mouse button 3 (right click)<br />
#hal-set-property --udi $udi --key input.x11_options.Button2 --string 3<br />
#<br />
#;;<br />
#esac<br />
done<br />
<br />
Copy and paste and (or directly) save it as wacom-names to '''/etc/rc.d''' and make it an executable.<br />
# chmod +x /etc/rc.d/wacom-names<br />
<br />
Add wacom-names to the DAEMONS line in your {{ic|[[rc.conf]]}}. Make sure to put it after HAL, and do not background HAL, because this script will not work if it runs before HAL has started. For example:<br />
DAEMONS=(syslog-ng @crond hal @acpid @alsa @gpm wacom-names)<br />
<br />
Reboot your computer. From here you can either keep wacom-names in your rc.conf if your rotation script calls on xsetwacom directly, or if you just need the calibration data, you can now use wacomcpl.<br />
<br />
If you are looking for more information, this [http://ubuntuforums.org/showthread.php?t=1038949 thread] at the Ubuntu forums is incredibly useful, and also provided the link to Rec's wacom-names script.<br />
<br />
<br />
<br />
== References ==<br />
*[http://gentoo-wiki.com/HOWTO_Wacom_Tablet Gentoo Linux Wiki - HOWTO Wacom Tablet]<br />
*[http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Main_Page Linux Wacom Project Wiki]<br />
*[http://www.gimptalk.com/forum/topic.php?t=17992&start=1 GIMP Talk - Community - Install Guide: Getting Wacom Drawing Tablets To Work In Gimp]<br />
*[https://help.ubuntu.com/community/Wacom Ubuntu Help: Wacom]<br />
*[http://ubuntuforums.org/showthread.php?t=1038949 Ubuntu Forums - Install a LinuxWacom Kernel Driver for Tablet PC's]</div>Buergihttps://wiki.archlinux.org/index.php?title=3D_Mouse&diff=2285193D Mouse2012-10-13T23:42:22Z<p>Buergi: Add section about spacenav open source drivers</p>
<hr />
<div>[[Category:Mice]]<br />
== What is a 3D Mouse? ==<br />
<br />
''"Also known as bats, flying mice, or wands, these devices generally function through ultrasound and provide at least three degrees of freedom. Probably the best known example would be 3DConnexion/Logitech's SpaceMouse from the early 1990s."'' - Wikipedia<br />
<br />
For more information: http://www.3dconnexion.com/products/what-is-a-3d-mouse.html<br />
<br />
== 3DConnexions 3D Mouse ==<br />
'''NOTE: The following instructions have been tested and proven to work on the most basic model (Space Navigator).'''<br />
<br />
=== Proprietary drivers ===<br />
<br />
1. Plug your 3D mouse into your USB port. Use {{ic|lsusb}} to check if it was recognised <br />
{{bc|1=$> lsusb<br />
Bus 003 Device 002: ID 046d:c626 Logitech, Inc. 3Dconnexion Space Navigator 3D Mouse}}<br />
<br />
2. Install {{Pkg|openmotif}} or if you need {{Pkg|lesstif}} (e.g. for {{Pkg|xpdf}}) you can just get the {{ic|libXm.so.4}} library from it:<br />
{{bc|1=$> sudo pacman -Sw openmotif # download openmotif to cache, do not install<br />
$> tar xJOf /var/cache/pacman/pkg/openmotif-* usr/lib/libXm.so.4.0.3 > libXm.so.4<br />
$> sudo mv libXm.so.4 /usr/lib/libXm.so.4}}<br />
<br />
3. Symlink {{ic|libXm.so.4}} to {{ic|libXm.so.3}}<br />
{{bc|1=$> sudo ln -s /usr/lib/libXm.so.4 /usr/lib/libXm.so.3}}<br />
<br />
4. The driver has some problems to get the username from {{ic|/var/run/utmp}} and will output a "failed to get user" error.<br />
<br />
To fix this problem compile the following program. It appends the given username to {{ic|/var/run/utmp}} in such a way that the driver can read it.<br />
{{hc|3dmouse.c|2=<nowiki><br />
/* source: http://forums.gentoo.org/viewtopic-t-609224.html<br />
* http://www.3dconnexion.com/forum/viewtopic.php?t=1039<br />
*/<br />
#include <stdio.h><br />
#include <string.h><br />
#include <stdlib.h><br />
#include <utmpx.h><br />
<br />
int main(int argc, char ** argv) {<br />
if (argc != 2) {<br />
fprintf(stderr, "Need a name to put in the structure\n");<br />
exit(1);<br />
}<br />
struct utmpx u;<br />
memset(&u, 0, sizeof(u));<br />
u.ut_type = USER_PROCESS;<br />
u.ut_pid = getpid();<br />
strcpy(u.ut_id, ":0");<br />
strcpy(u.ut_line, ":0");<br />
strcpy(u.ut_user, argv[1]);<br />
setutxent();<br />
pututxline(&u);<br />
endutxent();<br />
} <br />
</nowiki>}}<br />
{{bc|1=$> gcc 3dmouse.c -o 3dmouse<br />
$> sudo ./3dmouse root}}<br />
<br />
5. Download the linux drivers to {{ic|/tmp}} from here: http://www.3dconnexion.com/service/drivers.html<br />
<br />
6. Unpack the install script and run it<br />
{{bc|1=$> tar xfz 3dxware-linux-v1-5-2.i386.tar.gz install-3dxunix.sh<br />
$> sudo ./install-3dxunix.sh<br />
Password:<br />
<br />
<nowiki><br />
This installs 3DxWareUnix V1.5.2 on this machine. Continue? (y/n) [y]<br />
y<br />
<br />
Choose one of the following platforms:<br />
<br />
1. HP-UX<br />
2. Solaris<br />
3. AIX 5<br />
4. Linux<br />
5. Exit<br />
<br />
Please enter your choice (1-5)[4]:<br />
4<br />
<br />
Installing files for 3DxWare for Unix / linux......<br />
<br />
Uninstalling a running driver. Please wait ...<br />
Done.<br />
<br />
Converting default configs V5.x to V5.3.<br />
(User configs will be converted when used)<br />
Please wait a moment...<br />
Converting configs... found 27 configurations<br />
Configuration file Configuration name Version Status<br />
/etc/3DxWare/UGSNX2_01.scg ("UGS NX 2 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/4DNav.scg ("4D Navigator ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX5_02.scg ("UGS NX 5 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/CatiaV5_02.scg ("CATIA V5 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/Maya2011.scg ("Maya 2011 ") 5.3 Ok.<br />
/etc/3DxWare/CatiaV4_01.scg ("CATIA V4 ") 5.3 Ok.<br />
/etc/3DxWare/Patran_01.scg ("Patran ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX4_01.scg ("UGS NX 4 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/Pr(...)ire_02.scg ("ProE Wildfire config 02 ") 5.3 Ok.<br />
/etc/3DxWare/Pr(...)ire_01.scg ("ProE Wildfire config 01 ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX2_02.scg ("UGS NX 2 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/CatiaV5_03.scg ("CATIA V5 config 03 ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX3_02.scg ("UGS NX 3 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/default_10.scg ("Driver Protocol 1.0 ") 5.3 Ok.<br />
/etc/3DxWare/CADDS_R14.scg ("CADDS5 R14 + ") 5.3 Ok.<br />
/etc/3DxWare/CatiaV5_01.scg ("CATIA V5 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/DMUNav.scg ("DMU Navigator ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX4_02.scg ("UGS NX 4 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/Enovia_VPM.scg ("Enovia VPM ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX5_01.scg ("UGS NX 5 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/ICEM_MED.scg ("ICEM MED ") 5.3 Ok.<br />
/etc/3DxWare/CADDS_R13.scg ("CADDS5 -R13 ") 5.3 Ok.<br />
/etc/3DxWare/DVise.scg ("DVise ") 5.3 Ok.<br />
/etc/3DxWare/Op(...)alizer.scg ("Optegra Visualizer ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX3_01.scg ("UGS NX 3 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/IDEAS_01.scg ("IDEAS ") 5.3 Ok.<br />
/etc/3DxWare/default.scg ("Any Application ") 5.3 Ok.<br />
<br />
Done.<br />
<br />
Do you want 3DxWareUnix being started with every login (from the /etc/inittab)? (y/n) [y]<br />
n<br />
<br />
Please start the driver manually. [/etc/3DxWare/daemon/3dxsrv -d <port>]<br />
<br />
****************************************************************<br />
For testing purposes you can find the demos<br />
xcube and xvalues at /tmp<br />
****************************************************************<br />
</nowiki>}}<br />
NOTE: I chose not to run the driver everytime I login.<br />
<br />
7. You can run the driver manually by calling it like this (for USB version):<br />
{{bc|1=$> sudo /etc/3DxWare/daemon/3dxsrv -d USB}}<br />
<br />
8. You should now have a working 3D mouse in Arch Linux!<br />
You can test it by extracting the demos from the driver archive.<br />
{{bc|1=$> tar xfz 3dxware-linux-v1-5-2.i386.tar.gz xcube<br />
$> ./xcube}}<br />
<br />
=== Open Source Drivers ===<br />
There exists also an open source driver for 3Dconnexion devices maintained by the spacenav project.<br />
Unfortunately the list of supported applications is very short.<br />
Actually there is only one major software supporting the spacenav driver, namely the 3D creation suite Blender.<br />
For it to work three things must be fulfilled<br />
# The device must be recognized by the kernel as input device<br />
# The spacenavd daemon must be running<br />
# The application must be compiled with spacenav support. (community/{{Pkg|blender}} isn't)<br />
<br />
The first requirement should be fulfilled automatically after plugging in the device.<br />
It can be checked by looking if the device is listed in {{ic|/proc/bus/input/devices}} e.g. by<br />
{{bc|1=$> grep 3Dconnexion /proc/bus/input/devices<br />
N: Name="3Dconnexion SpaceNavigator"}}<br />
<br />
For the second point install {{AUR|libspnav}} and {{AUR|spacenavd}} from AUR.<br />
For testing it's a good idea to start the daemon on foreground mode. The output should look similar to this:<br />
{{bc|1=$> sudo spacenavd -v -d<br />
Spacenav daemon 0.5<br />
Device detection, parsing /proc/bus/input/devices<br />
using device: /dev/input/event21<br />
device name: 3Dconnexion SpaceNavigator<br />
trying to open X11 display ":0"<br />
XAUTHORITY=/home/user/.Xauthority<br />
}}<br />
If it works you can simply shut down the daemon by hitting CTRL-C and run it using {{ic|sudo /etc/rc.d/spacenavd start}}.<br />
On a systemd-only system the following service script can be used to start the daemon with {{ic|sudo systemctl start spacenavd.service}}<br />
{{hc|1=/etc/systemd/system/spacenavd.service|2=<br />
[Unit]<br />
Description=Userspace Daemon of the spacenav driver.<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/var/run/spnavd.pid<br />
ExecStart=/usr/bin/spacenavd<br />
<br />
[Install]<br />
WantedBy=multi-user.target}}<br />
<br />
<br />
Now everything is up and running and every supported application should be able to use the 3D Mouse.<br />
<br />
==== Rebuild Blender with spacenav support ====<br />
Unfortunately the {{Pkg|blender}} package in the community repository is not compiled with spacenav support.<br />
So you have to compile it yourself which is very easy<br />
{{bc|1=$> yaourt -S libspnav # blender will automatically build with NDOF(=spacenav) support when libspnav is installed<br />
$> yaourt -G blender<br />
$> cd blender<br />
$> makepkg<br />
$> sudo pacman -U blender-*.tar.xz<br />
}}<br />
<br />
Now you can fire up blender and test your 3D Mouse.<br />
{{bc|1=$> blender<br />
ndof: using SpaceNavigator}}<br />
<br />
{{Gentoo|SpaceNavigator}}<br />
<br />
== More Information ==<br />
* [http://www.3dconnexion.com/forum/viewforum.php?f=22 3dconnexion linux forum]<br />
* [http://www.3dconnexion.com/forum/viewtopic.php?t=1039 Source of C program used]<br />
* [http://www.3dconnexion.com/forum/viewtopic.php?t=1757 Information about libXm.so.4 and libXm.so.3]<br />
* [http://spacenav.sourceforge.net/ Website of the open source driver spacenav]<br />
* [http://spacemice.wikidot.com/ Community Wiki about Spacemice]</div>Buergihttps://wiki.archlinux.org/index.php?title=Systemd/Services&diff=218322Systemd/Services2012-08-16T21:51:14Z<p>Buergi: /* Static ethernet network */ Remove whitespace at end of lines</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
{{Article summary start}}<br />
{{Article summary text|This page will be useful to publish [[systemd]] service files that are missing in the {{pkg|systemd-arch-units}} package. These files can be copied from other distributions or created by yourself.}}<br />
<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Systemd}}<br />
{{Article summary end}}<br />
<br />
Currently, systemd is mostly at feature parity with Arch's initscripts. However, a lot more testing is needed. If you would like to help out, you can fork the [https://github.com/falconindy/initscripts-systemd initscripts-systemd] or [http://github.com/falconindy/systemd-arch-units systemd-arch-units] git repos and submit pull requests for your additions. This wiki page can serve as a staging area for these files.<br />
<br />
== mysqld ==<br />
{{Note|Mysqld requires an extra script to work properly. Remember to {{ic|chmod +x /usr/bin/mysqld-post}} before attempting to start {{ic|mysqld.service}}.}}<br />
{{Note|You have to either reboot or use {{ic|systemd-tmpfiles --create mysqld.conf}} for the tmpfile to take effect.}}<br />
{{hc|/etc/systemd/system/mysqld.service|<nowiki><br />
[Unit]<br />
Description=MySQL Server<br />
<br />
[Service]<br />
User=mysql<br />
ExecStart=/usr/bin/mysqld --user=mysql<br />
ExecStartPost=/usr/bin/mysqld-post<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki>}}<br />
<br />
{{hc|/usr/bin/mysqld-post|<nowiki><br />
#!/bin/sh<br />
while true; do<br />
response=`/usr/bin/mysqladmin -uUNKNOWN_USER ping 2>&1` && break<br />
echo "$response" | grep -q "mysqld is alive" && break<br />
sleep 1<br />
done<br />
</nowiki>}}<br />
<br />
{{hc|/etc/tmpfiles.d/mysqld.conf|<nowiki>d /var/run/mysqld 0755 mysql mysql -</nowiki>}}<br />
<br />
== atd ==<br />
{{hc|/etc/systemd/system/atd.service|<nowiki><br />
<br />
[Unit]<br />
Description=Execution Queue Daemon<br />
<br />
[Service]<br />
ExecStart=/usr/sbin/atd -f<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== irexecd ==<br />
{{hc|/etc/systemd/system/irexecd.service|<nowiki><br />
<br />
[Unit]<br />
Description=LIRC irexec Daemon<br />
Requires=lircd.service<br />
After=lircd.service<br />
<br />
[Service]<br />
Type=forking<br />
EnvironmentFile=/etc/conf.d/irexec.conf<br />
ExecStart=/usr/bin/irexec --daemon $IREXEC_OPTS<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
References:<br />
* http://lists.freedesktop.org/archives/systemd-devel/2011-January/001182.html<br />
<br />
== lircd ==<br />
{{hc|/etc/systemd/system/lircd.service|<nowiki><br />
<br />
[Unit]<br />
Description=LIRC Daemon<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
EnvironmentFile=/etc/conf.d/lircd.conf<br />
PIDFile=/run/lirc/lircd.pid<br />
ExecStartPre=/bin/mkdir -p /run/lirc<br />
ExecStartPre=/bin/rm -f /dev/lircd<br />
ExecStartPre=/bin/rm -f /run/lirc/lircd<br />
ExecStartPre=/bin/ln -s /run/lirc/lircd /dev/lircd<br />
<br />
ExecStart=/usr/sbin/lircd -d $LIRC_DEVICE -P /run/lirc/lircd.pid -H $LIRC_DRIVER $LIRC_CONFIGFILE<br />
ExecStopPost=/bin/rm -f /dev/lircd<br />
ExecStopPost=/bin/rm -fR /run/lirc<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Note|{{ic|$LIRC_EXTRAOPTS}} set in {{ic|/etc/conf.d/lircd.conf}} will not work, as {{ic|lircd}} will print an error about the argument count. Any extra options should be hardcoded into the unit file.}}<br />
<br />
References:<br />
* http://lists.freedesktop.org/archives/systemd-devel/2011-January/001182.html<br />
* https://bbs.archlinux.org/viewtopic.php?id=141300<br />
<br />
== rc.local ==<br />
<br />
{{hc|/etc/systemd/system/rc-local.service|<nowiki><br />
[Unit]<br />
Description=/etc/rc.local Compatibility<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/etc/rc.local<br />
TimeoutSec=0<br />
StandardInput=tty<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Note|Also available through the unrecommended {{Pkg|initscripts-systemd}} (see: [[Systemd#Arch_integration]]).}}<br />
<br />
== apache2 ==<br />
{{Note|You have to either reboot or use {{ic|systemd-tmpfiles --create httpd.conf}} for the tmpfile to take effect.}}<br />
{{hc|/etc/systemd/system/httpd.service|<nowiki><br />
[Unit]<br />
Description=Apache Webserver<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
EnvironmentFile=/etc/conf.d/apache<br />
ExecStart=/usr/sbin/httpd -k start $OPTIONS<br />
ExecStop=/usr/sbin/httpd -k graceful-stop $OPTIONS<br />
ExecReload=/usr/sbin/httpd -k graceful $OPTIONS<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{hc|/etc/tmpfiles.d/httpd.conf|<nowiki><br />
D /var/run/httpd 0755 http http -<br />
</nowiki>}}<br />
<br />
== memcached ==<br />
<br />
{{hc|/etc/systemd/system/memcached.service|<nowiki><br />
[Unit]<br />
Description=memcached daemon<br />
After=network.target<br />
<br />
[Service]<br />
EnvironmentFile=/etc/conf.d/memcached<br />
PIDFile=/var/run/memcached.pid<br />
ExecStart=/usr/bin/memcached -d -P /var/run/memcached.pid -u $MEMCACHED_USER $MEMCACHED_ARGS<br />
ExecStop=/bin/kill -15 $MAINPID<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Static ethernet network ==<br />
This is a custom service file for static ethernet configurations. For other configurations, see [[Systemd#Network]]<br />
{{hc|/etc/conf.d/network|<nowiki><br />
interface=eth0<br />
address=192.168.0.1<br />
netmask=24<br />
broadcast=192.168.0.255<br />
gateway=192.168.0.254</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/network.service|<nowiki><br />
[Unit]<br />
Description=Network Connectivity<br />
Wants=network.target<br />
Before=network.target<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
EnvironmentFile=/etc/conf.d/network<br />
ExecStart=/sbin/ip link set dev ${interface} up<br />
ExecStart=/sbin/ip addr add ${address}/${netmask} broadcast ${broadcast} dev ${interface}<br />
ExecStart=/sbin/ip route add default via ${gateway}<br />
ExecStop=/sbin/ip addr flush dev ${interface}<br />
ExecStop=/sbin/ip link set dev ${interface} down<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki>}}<br />
<br />
== Remote filesystem mounts ==<br />
<br />
''See: [[Systemd#Remote_filesystem_mounts]]''<br />
<br />
== distccd ==<br />
<br />
{{hc|/etc/systemd/system/distccd.service|<nowiki><br />
[Unit]<br />
Description=distcc<br />
<br />
[Service]<br />
Type=forking<br />
EnvironmentFile=/etc/conf.d/distccd<br />
ExecStart=/usr/bin/distccd --daemon $DISTCC_ARGS<br />
ExecStop=/bin/kill -15 $MAINPID<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Verynice ==<br />
<br />
{{hc|/etc/systemd/system/verynice.service|<nowiki><br />
[Unit]<br />
Description=A tool for dynamically adjusting the nice-level of processes<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/var/run/verynice.pid<br />
ExecStart=/usr/sbin/verynice -d /var/run/verynice.pid<br />
ExecStop=/bin/kill -15 $MAINPID<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== cpufreq ==<br />
<br />
{{hc|/etc/systemd/system/cpufreq.service|<nowiki><br />
[Unit]<br />
Description=CPU frequency scaling daemon<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
EnvironmentFile=/etc/conf.d/cpufreq<br />
ExecStart=/usr/bin/cpufreq-set -r -g $governor -d $min_freq -u $max_freq<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
This sets the governor of all cores to the one specified in<br />
{{ic|/etc/conf.d/cpufreq}}.<br />
<br />
If you use the {{ic|freq}} option, use to the following instead:<br />
{{hc|/etc/systemd/system/cpufreq.service|<nowiki><br />
[Unit]<br />
Description=CPU frequency scaling daemon<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
EnvironmentFile=/etc/conf.d/cpufreq<br />
ExecStart=/usr/bin/cpufreq-set -r -f $freq<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== transmission daemon ==<br />
<br />
Set {{ic|1=User=}} to the user the daemon should run as.<br />
<br />
{{hc|/etc/systemd/system/transmissiond.service|<br />
2=[Unit]<br />
Description=transmission daemon<br />
<br />
[Service]<br />
User=''transmission''<br />
ExecStart=/usr/bin/transmission-daemon -f<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
== BOINC Daemon ==<br />
<br />
{{hc|/etc/systemd/system/boinc.service|<nowiki><br />
[Unit]<br />
Description=BOINC Daemon<br />
<br />
[Service]<br />
User=boinc<br />
Nice=19<br />
ExecStart=/usr/bin/boinc_client --dir /var/lib/boinc --redirectio<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Logmein Hamachi ==<br />
<br />
{{hc|/etc/systemd/system/hamachi.service|<nowiki><br />
[Unit]<br />
Description=Hamachi Daemon<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/opt/logmein-hamachi/bin/hamachid<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== tftpd ==<br />
<br />
{{hc|/etc/systemd/system/tftpd.service|<nowiki><br />
[Unit]<br />
Description=TFTPD Server<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
EnvironmentFile=/etc/conf.d/tftpd<br />
ExecStart=/usr/sbin/in.tftpd $TFTPD_ARGS<br />
ExecStop=/bin/kill -15 $MAINPID<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
[[systemd]]</div>Buergihttps://wiki.archlinux.org/index.php?title=CD_Burning&diff=213115CD Burning2012-07-15T22:32:19Z<p>Buergi: /* Burning an audio CD */ Some tips added</p>
<hr />
<div>[[Category:Optical]]<br />
[[it:CD Burning]]<br />
[[zh-CN:CD Burning]]<br />
{{Article summary start}}<br />
{{Article summary text|This document outlines various methods of burning CDs.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|DVD Burning}}<br />
{{Article summary end}}<br />
== Command-line CD-burning == <br />
===Install CD-burning utilities===<br />
From http://www.cdrkit.org/:<br />
<br />
:''{{Ic|cdrkit}} is a suite of programs for recording CDs and DVDs, blanking CD-RW media, creating ISO-9660 filesystem images, extracting audio CD data, and more. The programs included in the {{Ic|cdrkit}} package were originally derived from several sources, most notably {{Ic|mkisofs}} by Eric Youngdale and others, {{Ic|cdda2wav}} by Heiko Eissfeldt, and {{Ic|cdrecord}} by Jörg Schilling. However, {{Ic|cdrkit}} is not affiliated with any of these authors; it is now an independent project.<br />
<br />
The {{pkg|cdrkit}} package is available in the [[Official Repositories|official repositories]].<br />
<br />
If you intend to use {{pkg|cdrdao}} (for writing {{ic|cue}}/{{ic|bin}} files to CD), install that package instead.<br />
<br />
{{Note|If you face any issues with {{Ic|cdrkit}}, it is recommended to install {{pkg|cdrtools}} from the community repository ({{Ic|cdrkit}} is a fork of {{Ic|cdrtools}}). {{Ic|cdrtools}} is being actively developed and supports CD, DVD and Blu-ray burning along with complete CDRWIN {{ic|cue}}/{{ic|bin}} support. {{Ic|cdrtools}} does not depend on {{Ic|cdrdao}}.}}<br />
<br />
{{Note|Make sure that you build a package using [[makepkg]] and install with pacman. Pacman wrappers may resolve to cdrkit instead.}}<br />
<br />
===Setting permissions===<br />
Users that should be able to use CD/DVD burning devices must have permissions to access the devices. If you are using [[udev]] (which is default in Arch Linux kernels), you only need to add the user(s) to the optical [[Users and Groups|group]]:<br />
# gpasswd -a <username> optical<br />
<br />
Log out and back in for the changes to take effect.<br />
<br />
===Modifying the CD-RW===<br />
For the remainder of this section the name of your recording device is assumed to be {{ic|/dev/cdrw}}. If that is not the case, modify the commands accordingly. In order to write to the CD it needs to be unmounted. If it is not, {{Ic|wodim}} will give you an error message.<br />
<br />
You can try to let wodim locate your burning device with this command:<br />
$ wodim -checkdrive<br />
<br />
===Erasing CD-RW===<br />
CD-RW media usually need to be erased before you can write new data on it. To blank CD-RW medium use this command:<br />
$ wodim -v dev=/dev/cdrw -blank=fast<br />
<br />
As you might have guessed, this blanks your medium really fast, but you can also use some other options, just replace the word ''fast'' with one of the following:<br />
<br />
;all: blank the entire disk<br />
;disc: blank the entire disk<br />
;disk: blank the entire disk<br />
;fast: minimally blank the entire disk (PMA, TOC, pregap)<br />
;minimal: minimally blank the entire disk (PMA, TOC, pregap)<br />
;track: blank a track<br />
;unreserve: unreserve a track<br />
;trtail: blank a track tail<br />
;unclose: unclose last session<br />
;session: blank last session<br />
<br />
===Burning an ISO image===<br />
To burn an ISO image run:<br />
$ wodim -v dev=/dev/cdrw isoimage.iso<br />
<br />
===Burning an audio CD===<br />
1. Create your audio tracks and store them as uncompressed, 16-bit stereo WAV files.<br />
{{Tip|To convert MP3 to WAV, ensure {{pkg|lame}} is installed, {{ic|cd}} to the directoy with your MP3 files, and run:<br />
{{bc|<br />
$ for i in *.mp3; do lame --decode "$i" "`basename "$i" .mp3`".wav; done<br />
}}<br />
'''Note:''' In case you get an error when trying to burn WAV files converted with lame try decoding with {{pkg|mpg123}}:<br />
{{bc|<br />
$ for i in *.mp3; do mpg123 --rate 44100 --stereo --buffer 3072 --resync -w `basename $i .mp3`.wav $i; done<br />
}}<br />
}}<br />
<br />
2. Name the audio files in a manner that will cause them to be listed in the desired track order when listed alphabetically, such as {{ic|01.wav}}, {{ic|02.wav}}, {{ic|03.wav}}, etc.<br />
<br />
3. Use the following command to simulate burning the wav files as an audio CD:<br />
$ wodim -dummy -v -pad speed=1 dev=/dev/cdrw -dao -swab *.wav<br />
In case you detect errors or empty tracks like<br />
Track 01: audio 0 MB (00:00.00) no preemp pad<br />
try another decoder (e.g. mpg123) or try using cdrecord from the {{pkg|cdrtools}} package.<br />
Note that {{pkg|cdrkit}} also contains a cdrecord command but it's just a softlink to wodim.<br />
<br />
4. If anything worked you can remove the dummy flag to really burn the CD<br />
<br />
To test the new audio CD, use [[Mplayer]]:<br />
$ mplayer cdda://<br />
<br />
===Burning a bin/cue===<br />
To burn a bin/cue image run:<br />
$ cdrdao write --device /dev/cdrw image.cue<br />
<br />
===Making an ISO image from an existing CD===<br />
To copy an existing CD just type:<br />
$ dd if=/dev/cdrw of=/home/user/isoimage.iso<br />
or even simpler:<br />
$ cat /dev/cdrw > isoimage.iso<br />
<br />
Or use the {{Ic|readcd}} program, also in the {{Ic|cdrkit}} package<br />
$ readcd -v dev=/dev/cdrw -f isoimage.iso<br />
<br />
If the original CD was bootable it will be a bootable image.<br />
<br />
====TOC/CUE/BIN for mixed-mode disks====<br />
ISO images only store a single data track. If you want to create an image of a mixed-mode disk (data track with multiple audio tracks) then you need to make a TOC/BIN pair:<br />
$ cdrdao read-cd --read-raw --datafile IMAGE.bin --driver generic-mmc:0x20000 --device /dev/cdrom IMAGE.toc<br />
<br />
Some software only likes CUE/BIN pair, you can make a CUE sheet with {{Ic|toc2cue}} (part of {{Ic|cdrdao}}):<br />
$ toc2cue IMAGE.toc IMAGE.cue<br />
<br />
===Making an ISO image from existing files on hard disk===<br />
To make an iso image just copy the needed files to one folder, then do:<br />
$ mkisofs -V volume_name -J -r -o isoimage.iso ~/folder<br />
<br />
===Mounting an ISO image===<br />
To test if the ISO image is proper, you can mount it (as root):<br />
# mount -t iso9660 -o ro,loop=/dev/loop0 cd_image /cdrom<br />
<br />
You have to first load the loop module:<br />
# modprobe loop<br />
<br />
===Converting to an ISO image===<br />
To convert an {{ic|img}}/{{ic|ccd}} image, you can use {{Ic|ccd2iso}}: <br />
# pacman -S ccd2iso<br />
$ ccd2iso ~/image.img ~/image.iso<br />
<br />
== Burning CDs with a GUI ==<br />
There are several applications available to burn CDs in a graphical environment. The use of these programs are self-explanatory.<br />
<br />
===Nero Linux===<br />
NERO LINUX is a commercial burning suite from makers of Nero for windows - Nero AG. the biggest advantage of nero linux is its interface which similar to window version. Hence, users migrating from windows might find it easy to operate. The Linux version now includes Nero Express, a wizard which takes users through the process of burning CDs and DVDs step-by-step, which users will be familiar with from the Windows version. Also new in version 4 is Blu-ray Disc defect management, integration of Isolinux for creating bootable media and support for Musepack and AIFF audio formats...<br />
<br />
* [http://www.nero.com/enu/linux4.html Nero Linux 4]<br />
* {{AUR|nerolinux}} [[Arch User Repository|AUR]] package<br />
<br />
====Features====<br />
* Easy, wizard-style user interface for guided burning with Nero Linux Express 4<br />
* Full Blu-ray Burning Support<br />
* Supports Burning of Audio CD (CD-DA), ISO 9660 (Joliet support), CD-Text, ISOLINUX Bootable, Multi-session Discs, DVD-Video and miniDVD, DVD double layer support.<br />
* Advanced burning with Nero Burning ROM and command line client <br />
<br />
====License:====<br />
Nero Linux 4 retails at £17.99 with a free trial version also available.<br />
<br />
====Note:====<br />
For Nero Linux you need<br />
<br />
MODULES=( sg )<br />
<br />
in rc.conf. Some updates ago the sg module wasn't auto loaded any more and Nero needs it.<br />
<br />
===K3b===<br />
According to [http://k3b.plainblack.com/, k3b is "The CD/DVD Kreator for Linux - optimized for KDE". K3b uses the [[Wikipedia:Qt (toolkit)|Qt]] toolkit.<br />
<br />
The {{pkg|k3b}} package is available in [extra]:<br />
# pacman -S k3b<br />
<br />
Run {{Ic|k3bsetup}} to set up your preferences, permissions, etc.; run {{Ic|k3b}} to execute the main program.<br />
<br />
===Brasero===<br />
Brasero is another solution to CD burning if you are using [[GNOME]].<br />
<br />
* Install {{pkg|brasero}} with [[pacman]].<br />
<br />
* Run {{ic|brasero}} to run the main program.<br />
<br />
===Graveman===<br />
Graveman is a simple and almost dependency-free application for burning CDs.<br />
<br />
* {{AUR|graveman}} is available in the [[Arch User Repository|AUR]].<br />
<br />
* Run {{ic|graveman}} as a regular user to create the configuration file in {{ic|~/.config/graveman/graveman.conf}} (if you run graveman as root first, the permissions for this file will be wrong).<br />
* Now, in graveman, go to menu File > Preferences... > Devices and add your CD burners (If necessary, run graveman as root). Devices may already be set up correctly.<br />
* Note that you may have to manually add your own device in Graveman's preferences and point it at {{ic|/dev/cdrom}} instead of {{ic|/dev/hdc}}<br />
* If graveman's automatic detection points to '''1,0,0''' or something like that, and you get the "Currently: no media" error you may point it to {{ic|/dev/sr0}} or {{ic|/dev/cdrom}} as noted above<br />
<br />
===Bashburn===<br />
Alternatively theres also [http://bashburn.sourceforge.net/ Bashburn] in [[Official Repositories|official repositories]] as a semi-GUI solution. BashBurn is the new name for the CD burning shell script Magma. It is not the best looking CD-burning application out there, but it does what you want it to do.<br />
<br />
* Install {{pkg|bashburn}} with [[pacman]].<br />
<br />
===Xfburn===<br />
[http://www.xfce.org/projects/xfburn/ Xfburn] is a simple CD/DVD burning tool based on libburnia libraries. It can blank CD-RWs, burn and create ISO images, as well as burn personal compositions of data to either CD or DVD. <br />
<br />
It can be found in the [[Official Repositories|official repositories]].<br />
<br />
* Install {{pkg|Xfburn}} with [[pacman]].<br />
<br />
===Recorder===<br />
[http://code.google.com/p/recorder/ Recorder] is a graphical front-end of cdrkit/cdrtools, cdrdao, mkisofs and growisofs. It aims to be simple and easy to use, free of large configurations and useless options, following the KISS principle and offering a disc burning of quality, nothing more.<br />
<br />
* Install from the [[Official Repositories|official repositories]]: {{pkg|recorder}}<br />
<br />
* Discussion thread: [https://bbs.archlinux.org/viewtopic.php?id=47253 Recorder - A simple GTK+ disc burner]<br />
<br />
==Troubleshooting==<br />
<br />
====About Locale====<br />
When running K3B, if the following message appears<br />
<br />
System locale charset is ANSI_X3.4-1968<br />
Your system's locale charset (i.e. the charset used to encode file names) is <br />
set to ANSI_X3.4-1968. It is highly unlikely that this has been done intentionally.<br />
Most likely the locale is not set at all. An invalid setting will result in<br />
problems when creating data projects.Solution: To properly set the locale <br />
charset make sure the LC_* environment variables are set. Normally the distribution <br />
setup tools take care of this.<br />
<br />
It means that your locale is not set well.<br />
<br />
To fix it,<br />
* Remove {{ic|/etc/locale.gen}}<br />
# rm /etc/locale.gen<br />
* Re-install {{ic|glibc}}<br />
# pacman -S glibc<br />
* Edit {{ic|/etc/locale.gen}}, uncommenting all lines lines that corresponds to your language AND the {{ic|en_US}} options, for compatibility.<br />
en_US.UTF-8 UTF-8<br />
en_US ISO-8859-1<br />
<br />
* Re-generate the profiles with {{ic|locale-gen}}<br />
# locale-gen<br />
<br />
Generating locales...<br />
en_US.UTF-8... done<br />
en_US.ISO-8859-1... done<br />
pt_BR.UTF-8... done<br />
pt_BR.ISO-8859-1... done<br />
Generation complete.<br />
<br />
More info [https://bbs.archlinux.org/viewtopic.php?pid=251512%29; here]<br />
<br />
==== K3B says that there are no Burning Devices ====<br />
A common cause of this is the current user have no privileges for that.<br />
You can try to:<br />
* Add the user to the group {{ic|optical}} (remember to re-login after this)<br />
# gpasswd -a <user> optical<br />
* Set permissions to devices (can also be done with 'k3bsetup')<br />
# chmod 777 /dev/dvd*<br />
# chmod 777 /dev/cd*<br />
* Make sure dbus is running:<br />
# /etc/rc.d/dbus start<br />
You should add a dbus entry in your {{ic|/etc/rc.conf}} so that it automatically loads upon boot.<br />
<br />
====Brasero fails to find blank discs====<br />
Brasero uses gvfs to manage CD/DVD burning devices.<br />
<br />
* Install {{pkg|gvfs}} with [[pacman]].<br />
<br />
* Edit your {{ic|~/.xinitrc}} by adding {{ic|dbus-launch}} before your [[Window Manager|window manager]] name, e.g.:<br />
# exec dbus-launch openbox-session<br />
<br />
* You do not need to edit {{ic|~/.xinitrc}} if you are using a login manager like [[GDM]] or [[KDM]].</div>Buergihttps://wiki.archlinux.org/index.php?title=Archiso&diff=199899Archiso2012-05-01T11:14:14Z<p>Buergi: /* Adding a user */ Not 'passwd' contains password hash but 'shadow'</p>
<hr />
<div>[[Category:Live Arch systems]]<br />
[[fr:Archiso]]<br />
{{i18n|Archiso}}<br />
<br />
'''Archiso''' is a small set of bash scripts that is capable of building fully functional Arch Linux based live CD and USB images. It is a very generic tool, so it could potentially be used to generate anything from rescue systems, install disks, to special interest live CD/DVD/USB systems, and who knows what else. Simply put, if it involves Arch on a shiny coaster, it can do it.<br />
The heart and soul of Archiso is mkarchiso. All of its options are documented in its usage output, so its direct usage wont be covered here. Instead, this wiki article will act as a guide for rolling your own live mediums in no time!<br />
<br />
<br />
== Setup ==<br />
<br />
Before we begin, we need to grab the archiso scripts which carry out the beef of the work for us. You can get archiso from Git (recommended) or from [https://aur.archlinux.org/packages.php?ID=25996 aur]. We also need a few packages which archiso relies on; the following commands take care of this for us:<br />
<br />
# pacman -S make git libisoburn squashfs-tools dosfstools rsync --needed<br />
# git clone git://projects.archlinux.org/archiso.git<br />
# make -C archiso/archiso install<br />
<br />
Create a directory to work within, this is where all the modifications to the live image will take place: ~/archlive should do fine.<br />
$ mkdir ~/archlive<br />
<br />
The archiso scripts that were installed to the host system earlier now need to be copied over into the newly created directory you will be working within.<br />
Archiso comes with two "profiles": releng, and baseline.<br />
If you wish to create a fully customised live version of Arch Linux, pre-installed with all your favourite programs and configurations, use "releng".<br />
If you just want to create the most basic live media, with no pre-installed packages and minimalistic configurations, then use "baseline".<br />
<br />
So, depending on your needs, execute the following, replacing 'PROFILE' with either '''releng''' or '''baseline'''.<br />
# cp -r /usr/share/archiso/configs/'''PROFILE'''/ ~/archlive<br />
<br />
If you are using the 'releng' profile to make a fully customised image, then you can proceed onto [[Archiso#Configure_our_live_medium]].<br />
<br />
If you are using the 'baseline' profile to create a bare bones, installation image, then you won't be needing to do any customisations and can proceed onto [[Archiso#Build_the_ISO]]<br />
<br />
== Setup (manual way) ==<br />
<br />
If you have already completed the setup the 'automatic' way, using the steps above, then you do not need to read this section.<br />
Setup a base filesystem<br />
# mkarchiso init<br />
<br />
Install other packages (optional)<br />
# mkarchiso -p "pkg1 pkg2 pkg3 ... pkgN" install<br />
<br />
At this point, customize anything what you want in root-image, then exit when done.<br />
<br />
# mkarchiso-r "bash" run<br />
<br />
Setup initramfs image.<br />
Copy needed hooks to root-image<br />
<br />
# cp /lib/initcpio/hooks/archiso work/root-image/lib/initcpio/hooks<br />
# cp /lib/initcpio/install/archiso work/root-image/lib/initcpio/install<br />
<br />
Create a config for mkinitcpio '''work/root-image/etc/mkinitcpio-archiso.conf'''<br />
HOOKS="base udev archiso pata scsi sata usb fw filesystems usbinput"<br />
COMPRESSION="xz"<br />
<br />
Create a folder named as your PC's architecture, and generate the initramfs image:<br />
# mkdir work/root-image/boot/i686<br />
# mkarchiso -r "mkinitcpio -c /etc/mkinitcpio-archiso.conf -k /boot/vmlinuz-linux -g /boot/i686/archiso.img" run<br />
<br />
Move kernel/initramfs to boot/<br />
# mkdir -p work/iso/arch/boot/i686<br />
# mv work/root-image/boot/vmlinuz-linux work/iso/arch/boot/i686/vmlinuz<br />
# mv work/root-image/boot/i686/archiso.img work/iso/arch/boot/i686/archiso.img<br />
<br />
Setup syslinux<br />
<br />
Create a directory for it.<br />
# mkdir -p work/iso/arch/boot/syslinux<br />
<br />
Create a '''work/iso/arch/boot/syslinux/syslinux.cfg''' file.<br />
<br />
{{bc|1=<br />
DEFAULT menu.c32<br />
PROMPT 0<br />
MENU TITLE Arch Linux<br />
TIMEOUT 300<br />
<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX /arch/boot/i686/vmlinuz<br />
INITRD /arch/boot/i686/archiso.img<br />
APPEND archisolabel=MY_ARCH<br />
<br />
ONTIMEOUT arch<br />
}}<br />
<br />
Copy menu.c32 needed by previous config.<br />
# cp work/root-image/usr/lib/syslinux/menu.c32 work/iso/arch/boot/syslinux/<br />
<br />
Setup isolinux (optional, only needed for booteable iso)<br />
<br />
# mkdir work/iso/isolinux<br />
# cp work/root-image/usr/lib/syslinux/isolinux.bin work/iso/isolinux/<br />
# cp work/root-image/usr/lib/syslinux/isohdpfx.bin work/iso/isolinux/<br />
<br />
Create a '''work/iso/isolinux/isolinux.cfg'''<br />
{{bc|<br />
DEFAULT loadconfig<br />
<br />
LABEL loadconfig<br />
CONFIG /arch/boot/syslinux/syslinux.cfg<br />
APPEND /arch/boot/syslinux/<br />
}}<br />
<br />
Create an '''work/iso/arch/aitab''' file.<br />
# <img> <mnt> <arch> <sfs_comp> <fs_type> <fs_size><br />
root-image / i686 xz ext4 50%<br />
<br />
Build all filesystem images specified in aitab (.fs .fs.sfs .sfs)<br />
# mkarchiso prepare<br />
<br />
Generate an ISO 9660 with "El Torito" boot image (optional)<br />
# mkarchiso -L "MY_ARCH" iso "my-arch.iso"<br />
<br />
== Configure our live medium ==<br />
<br />
This section details configuring the image you will be creating, allowing you to define the packages and configurations you want your live image to contain.<br />
<br />
Change into the directory we created earlier (~/archlive/releng/ if you have been following this guide), you will see a number of files and directories; we are only concerned with a few of these, mainly: <br />
packages.* - this is where you list, line by line, the packages you want to have installed, and<br />
the root-image directory - this directory acts as an overlay and it is where you make all the customisations.<br />
<br />
=== Installing packages ===<br />
<br />
You will want to create a list of packages you want installed on your live CD system. A file full of package names, one-per-line, is the format for this. This is '''''great''''' for special interest live CDs, just specify packages you want and bake the image.<br />
Edit the packages.i686, or packages.x86_64 file depending on whether you are create a 32bit, or 64bit image, respectively.<br />
<br />
{{Tip|You can also create a '''[[custom local repository]]''' for the purpose of preparing custom packages or packages from [[AUR]]/[[ABS]]. Just add your local repository at the first position (for top priority) of your build machine's '''pacman.conf''' and you are good to go!}}<br />
<br />
=== Adding a user ===<br />
<br />
There are two methods to creating a user: either by adding the relevant useradd command to rc.local, or by copying over (and modifying) /etc/shadow, /etc/passwd, and /etc/group.<br />
The latter method shall be discussed here.<br />
<br />
Copy your /etc/shadow, /etc/passwd, and /etc/group from your '''host''' system to the /etc/ directory '''where you now working''' (which should be ~/archlive/releng/root-image/etc)<br />
e.g.<br />
# cp /etc/{shadow,passwd,group} ~/archlive/releng/root-image/etc/<br />
<br />
{{Warning|The shadow file will contain your encrypted password. I recommend before you copy the shadow file over to the, you change the password of your host user to that which you want your live user to have, copy the shadow file over, and then change back your password.}}<br />
<br />
=== Adding files to image ===<br />
<br />
{{Note|You must be root to do this, do not change the ownership of any of the files you copy over, '''everything''' within the root-image directory must be root owned. Proper ownerships will be sorted out shortly.}}<br />
<br />
The root-image directory acts as an overlay, think of it as root directory '/' on your current system, so any files you place within this directory will be copied over on boot-up.<br />
<br />
So if you have a set of iptables scripts on your current system you want to be used on you live image, copy them over as such:<br />
# cp -r /etc/iptables ~/archlive/releng/root-image/etc<br />
<br />
Placing files in the users home directory is a little different. Do not place them within root-image/home, but instead create a skel directory within root-image/ and place them there. We will then add the relevant commands to the rc.local we are going to create to copy them over on boot and sort out the permissions.<br />
<br />
First, create the skel directory; making sure you are within ~/archlive/releng/root-image/etc directory (if this is where you are working from):<br />
# cd ~/archlive/releng/root-image/etc && mkdir skel<br />
<br />
Now copy the 'home' files to the skel directory, again doing everything as root!<br />
e.g for .bashrc. <br />
# cp ~/.bashrc ~/archlive/releng/root-image/etc/skel/<br />
<br />
<br />
Inside the root-image/etc/ directory, create the rc.local file, and '''make sure''' you make it executable:<br />
<br />
# cd ~/archlive/releng/root-image/etc && touch rc.local && chmod +x rc.local<br />
<br />
Now add the all of following to rc.local, replacing 'youruser' with the user you specified earlier.<br />
# Create the user directory for live session<br />
if [ ! -d /home/'''youruser''' ]; then<br />
mkdir /home/'''youruser''' && chown '''youruser''' /home/'''youruser'''<br />
fi<br />
# Copy files over to home<br />
su -c "cp -r /etc/skel/.[a-zA-Z0-9]* /home/'''youruser'''/" '''youruser'''<br />
<br />
=== aitab ===<br />
<br />
The default file should work fine, so you should not need to touch it.<br />
<br />
The aitab file holds information about the filesystems images that must be created by mkarchiso and mounted at initramfs stage from the archiso hook.<br />
It consists of some fields which define the behaviour of images.<br />
<br />
# <img> <mnt> <arch> <sfs_comp> <fs_type> <fs_size><br />
<br />
; <img>: Image name without extension (.fs .fs.sfs .sfs).<br />
; <mnt>: Mount point.<br />
; <arch>: Architecture { i686 | x86_64 | any }.<br />
; <sfs_comp>: SquashFS compression type { gzip | lzo | xz }. A special value of "none" denotes no usage of SquashFS.<br />
; <fs_type>: Set the filesystem type of the image { ext4 | ext3 | ext2 | xfs }. A special value of "none" denotes no usage of a filesystem. In that case all files are pushed directly to SquashFS filesystem.<br />
; <fs_size>: An absolute value of file system image size in MiB (example: 100, 1000, 4096, etc) A relative value of file system free space [in percent] {1%..99%} (example 50%, 10%, 7%). This is an estimation, and calculated in a simple way. Space used + 10% (estimated for metadata overhead) + desired %<br />
<br />
{{Note|Some combinations are invalid. Example both sfs_comp and fs_type are set to none}}<br />
<br />
=== Boot Loader ===<br />
The default file should work fine, so you should not need to touch it.<br />
<br />
Due to the modular nature of isolinux, you are able to use lots of addons since all *.c32 files are copied and available to you. Take a look at the [http://syslinux.zytor.com/wiki/index.php/SYSLINUX official syslinux site] and the [http://projects.archlinux.org/archiso.git/tree/configs/syslinux-iso/boot-files archiso git repo]. Using said addons, it is possible to make visually attractive and complex menus. See [http://syslinux.zytor.com/wiki/index.php/Comboot/menu.c32 here].<br />
<br />
=== Finishing the root-image ===<br />
Some tips that will not be covered in this article because there are other articles on this wiki that already do, but please feel free to add them here.<br />
*Configure an ''inittab'' to start into X at boot time<br />
*Configure the ''hosts'' file<br />
*Configure ''rc.conf'' (no fancy modules required here)<br />
*Configure ''sudoers''<br />
*Configure ''rc.local''<br />
*Put additional artworks onto the medium <br />
*Put arbitrary binary stuff into opt/<br />
<br />
== Build the ISO ==<br />
<br />
Now you are ready to turn your files into the .iso which you can then burn to CD or USB:<br />
Inside the directory you are working with, either ~/archlive/releng, or ~/archlive/baseline, execute:<br />
<br />
# ./build.sh -v build single netinstall<br />
<br />
You can replace 'netinstall' with 'core' if you wish; however, doing so will cache all of the packages pacman downloads into the iso file, which will vastly inrease it's size.<br />
<br />
The script will now download and install the packages you specified to work/*/root-image, create the kernel and init images, apply your customizations and finally build the iso into out/.<br />
<br />
You can now dd the iso file onto a USB using dd, an example of which:<br />
# dd if=~/archlive/releng/out/*.iso of=/dev/sdx<br />
You will have to adjust accordingly, and make sure you choose the right output file! A simple mistake here will destory data on your harddisk.<br />
<br />
== See also ==<br />
*[http://projects.archlinux.org/?p=archiso.git;a=summary Archiso project page]<br />
*[[Archiso_as_pxe_server|Archiso as pxe server]]<br />
*[https://kroweer.wordpress.com/2011/09/07/creating-a-custom-arch-linux-live-usb Step-by-step tutorial on using ArchISO]<br />
*[http://didjix.blogspot.com/ A live DJ distribution powered by ArchLinux and built with Archiso]</div>Buergihttps://wiki.archlinux.org/index.php?title=QEMU&diff=152168QEMU2011-08-16T08:23:54Z<p>Buergi: /* Using any real partition as the single primary partition of a hard disk image */ corr wrong file path</p>
<hr />
<div>[[Category:Emulators (English)]]<br />
[[fr:Qemu]]<br />
{{i18n|QEMU}}<br />
From the [http://wiki.qemu.org/Main_Page QEMU about page],<br />
<blockquote><br />
<p>QEMU is a generic and open source machine emulator and virtualizer.</p><br />
<br />
<p>When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.</p><br />
<br />
<p>When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. QEMU supports virtualization when executing under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM, QEMU can virtualize x86, server and embedded PowerPC, and S390 guests.</p><br />
</blockquote><br />
<br />
== Difference between qemu and qemu-kvm ==<br />
Depending on your needs, you can choose either to install upstream {{Package Official|qemu}} or {{Package Official|qemu-kvm}} from the [extra] repository. Upstream qemu is a pure emulator, with no hardware acceleration (actually, it does have initial KVM support when qemu is started with -enable-kvm parameter, but this implementation is still buggy and nowhere as complete as in qemu-kvm, many functions still do not work). Upstream qemu is capable of emulating many different platforms (arm, i386, m68k, mips, ppc, sparc, x86_64, etc). On the other hand you have qemu-kvm, which is qemu (i386 and x86_64 architecture support only) with KVM (kernel virtual machine) additions, allowing you to run virtual machines at close to native speed. qemu-kvm is the version you want if you have a capable CPU and only need to run virtual machines for the i386 and x86_64 architecture (Linux, Windows, BSD, etc).<br />
<br />
Not all processors support KVM. You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also the [http://ark.intel.com/VTList.aspx Intel® Virtualization Technology List].<br />
<br />
== Installing QEMU ==<br />
To install the machine emulator version:<br />
<pre><br />
$ sudo pacman -S qemu<br />
</pre><br />
To install the KVM version (please see the page on [[Kvm]] for more details):<br />
<pre><br />
$ sudo pacman -S qemu-kvm<br />
</pre><br />
<br />
== Choosing Windows version==<br />
QEMU can run any version of Windows. However, 98, Me and XP will run at quite a low speed. You should choose either Windows 95 or Windows 2000. Surprisingly, 2000 seems to run faster than 98. The fastest one is 95, which can from time to time make you forget that you are running an emulator :)<br />
<br />
If you own both Win95 and Win98/WinME, then 98lite (from http://www.litepc.com) might be worth trying. It decouples Internet Explorer from operating system and replaces it with original Windows 95 Explorer. It also enables you to do a minimal Windows installation, without all the bloat you normally cannot disable. This might be the best option, because you get the smallest, fastest and most stable Windows this way.<br />
<br />
== Creating the hard disk image==<br />
To run QEMU you will probably need a hard disk image. This is a file which stores the contents of the emulated hard disk.<br />
<br />
Use the command:<br />
qemu-img create -f qcow2 win.qcow 4G<br />
to create the image file named "win.qcow". The "4G" parameter specifies the size of the disk - in this case 4 GB. You can use suffix M for megabytes (for example "256M"). You should not worry too much about the size of the disk - the qcow2 format compresses the image so that the empty space does not add up to the size of the file.<br />
<br />
== Preparing the installation media==<br />
The installation CD-ROM/floppy should not be mounted, because QEMU accesses the media directly. It is a good idea to dump CD-ROM and/or floppy to a file, because it both improves performance and does not require you to have direct access to the devices (that is, you can run QEMU as a regular user). For example, if the CD-ROM device node is named {{filename|/dev/cdrom}}, you can dump it to a file with the command:<br />
dd if=/dev/cdrom of=win98icd.iso<br />
<br />
Do the same for floppies:<br />
dd if=/dev/fd of=win95d1.img<br />
<br />
When you need to replace floppies within QEMU, just copy the contents of one floppy over another. For this reason, it is useful to create a special file that will hold the current floppy:<br />
touch floppy.img<br />
<br />
== Installing the operating system==<br />
This is the first time you will need to start the emulator.<br />
One thing to keep in mind: when you click inside qemu window, the mouse pointer is grabbed. To release it press Ctrl+Alt.<br />
<br />
If you need to use a bootable floppy, run QEMU with:<br />
<pre><br />
qemu -cdrom [[cdrom''image]] -fda [[floppy''image]] -boot a [[hd_image]]<br />
</pre><br />
or if you are on a x86_64 system (will avoid many problems afterwards):<br />
<pre><br />
qemu-system-x86_64 -cdrom [[cdrom''image]] -fda [[floppy''image]] -boot a [[hd_image]]<br />
</pre><br />
If your CD-ROM is bootable or you are using iso files, run QEMU with:<br />
<pre><br />
qemu -cdrom [[cdrom''image]] -boot d [[hd''image]]<br />
</pre><br />
or if you are on a x86_64 system (will avoid many problems afterwards):<br />
<pre><br />
qemu-system-x86_64 -cdrom [[cdrom''image]] -boot d [[hd''image]]<br />
</pre><br />
Now partition the virtual hard disk, format the partitions and install the OS.<br />
<br />
A few hints:<br />
# If you are using Windows 95 boot floppy, then choosing SAMSUNG as the type of CD-ROM seems to work<br />
# There are problems when installing Windows 2000. Windows setup will generate a lot of edb*.log files, one after the other containing nothing but blank spaces in C:\WINNT\SECURITY which quickly fill the virtual harddisk. A workaround is to open a Windows command prompt as early as possible during setup (by pressing Shift-F10) which will allow you to remove these log files as they appear by typing :<br />
del %windir%\security\*.log<br />
<br />
{{Note| According to the official QEMU website, "Windows 2000 has a bug which gives a disk full problem during its installation. When installing it, use the {{codeline|-win2k-hack}} QEMU option to enable a specific workaround. After Windows 2000 is installed, you no longer need this option (this option slows down the IDE transfers)."}}<br />
<br />
== Running the system==<br />
To run the system simply type:<br />
<pre><br />
qemu [hd_image]<br />
</pre><br />
<br />
A good idea is to use overlay images. This way you can create hard disk image once and tell QEMU to store changes in external file.<br />
You get rid of all the instability, because it is so easy to revert to previous system state :)<br />
<br />
To create an overlay image, type:<br />
<pre><br />
qemu-img create -b [[base''image]] -f qcow2 [[overlay''image]]<br />
</pre><br />
<br />
Substitute the hard disk image for base_image (in our case win.qcow). After that you can run qemu with:<br />
<pre><br />
qemu [overlay_image]<br />
</pre><br />
or if you are on a x86_64 system:<br />
<pre><br />
qemu-system-x86_64 [overlay_image]<br />
</pre><br />
and the original image will be left untouched. One hitch, the base image cannot be renamed or moved, the overlay remembers the base's full path.<br />
<br />
== Moving data between host and guest OS==<br />
If you have servers on your host OS they will be accessible with the ip-address 10.0.2.2 without any further configuration. So you could just FTP or SSH, etc to 10.0.2.2 from windows to share data, or if you would like to use Samba.<br />
<br />
=== Samba===<br />
QEMU supports [[Samba]] which allows you to mount host directories during the emulation. It seems that there is an incompatibility with Samba 3.x. and some versions of QEMU. But at least with a current snapshot of QEMU it should be working.<br />
<br />
First, you need to have a working Samba installation. Then add the following section to your {{filename|smb.conf}}:<br />
<pre><br />
[qemu]<br />
comment = Temporary file space<br />
path = /tmp<br />
read only = no<br />
public = yes<br />
</pre><br />
<br />
Now start qemu with:<br />
<pre><br />
qemu [hd_image] -smb qemu<br />
</pre><br />
<br />
Then you should be able to access your host's smb-server with the ip-address 10.0.2.2. If you are running Win9x as guest OS, you may need to add<br />
10.0.2.2 smbserver<br />
to {{filename|c:\windows\lmhosts}} (Win9x has Lmhosts.sam as a SAMple, rename it!).<br />
<br />
=== Mounting the hard disk image - raw image===<br />
Fortunately there is a way to mount the hard disk image with a loopback device. Login as root, make a temporary directory and mount the image with the command:<br />
<pre><br />
mount -o loop,offset=32256 [[hd''image]] [[tmp''dir]]<br />
</pre><br />
Now you can copy data in both directions. When you are done, umount with:<br />
<pre><br />
umount [hd_image]<br />
</pre><br />
<br />
The drawback of this solution is that you cannot use it with qcow images (including overlay images). So you need to create you images without \"-f qcow\" option. Tip: create a second, raw harddrive image. This way you will be able to transfer data easily and use qcow overlay images for the primary drive.<br />
<br />
REMEMBER: never run QEMU while the image is mounted!<br />
<br />
=== Mounting qcow2 image ===<br />
You may mount a qcow2 image using '''qemu-nbd'''. See [[Wikipedia:Qcow#Mounting_qcow2_images]].<br />
<br />
=== Using any real partition as the single primary partition of a hard disk image ===<br />
Sometimes, you may wish to use one of your system partition from within QEMU (for instance, if you wish booting both your real machine or QEMU using a given partition as root). You can do this using software RAID in linear mode (you need the linear.ko kernel driver) and a loopback device: the trick is to dynamically prepend a master boot record (MBR) to the real partition you wish to embed in a QEMU raw disk image.<br />
<br />
Suppose you have a plain, unmounted {{filename|/dev/hdaN}} partition with some filesystem on it you wish to make part of a QEMU disk image. First, you create some small file to hold the MBR:<br />
dd if=/dev/zero of=/path/to/mbr count=32<br />
<br />
Here, a 16 KB (32 * 512 bytes) file is created. It is important not to make it too small (even if the MBR only needs a single 512 bytes block), since the smaller it will be, the smaller the chunk size of the software RAID device will have to be, which could have an impact on performance. Then, you setup a loopback device to the MBR file:<br />
losetup -f /path/to/mbr<br />
<br />
Let's assume the resulting device is {{filename|/dev/loop0}}, because we would not already have been using other loopbacks. Next step is to create the "merged" MBR + /dev/hdaN disk image using software RAID:<br />
modprobe linear<br />
mdadm --build --verbose /dev/md0 --chunk=16 --level=linear --raid-devices=2 /dev/loop0 /dev/hdaN<br />
<br />
The resulting {{filename|/dev/md0}} is what you will use as a QEMU raw disk image (do not forget to set the permissions so that the emulator can access it). The last (and somewhat tricky) step is to set the disk configuration (disk geometry and partitions table) so that the primary partition start point in the MBR matches the one of {{filename|/dev/hdaN}} inside {{filename|/dev/md0}} (an offset of exactly 16 * 512 = 16384 bytes in this example). Do this using fdisk on the host machine, not in the emulator: the default raw disc detection routine from QEMU often results in non kilobyte-roundable offsets (such as 31.5 KB, as in the previous section) that cannot be managed by the software RAID code. Hence, from the the host:<br />
fdisk /dev/md0<br />
<br />
Press 'x' to enter the expert menu. Set number of 's'ectors per track so that the size of one cylinder matches the size of your mbr file. For two heads and a sector size of 512, the number of sectors per track should be 16, so we get cylinders of size 2x16x512=16k.<br />
<br />
Now, press 'r' to return to the main menu. <br />
<br />
Press 'p' and check that now the cylinder size is 16k.<br />
<br />
Now, create a single primary partition corresponding to {{filename|/dev/hdaN}}. It should start at cylinder 2 and end at the end of the disk (note that the number of cylinders now differs from what it was when you entered fdisk.<br />
<br />
Finally, 'w'rite the result to the file: you are done. You know have a partition you can mount directly from your host, as well as part of a QEMU disk image: <br />
<br />
qemu -hdc /dev/md0 [...]<br />
<br />
You can of course safely set any bootloader on this disk image using QEMU, provided the original {{filename|/dev/hdaN}} partition contains the necessary tools.<br />
<br />
== Optimizing Windows 9x CPU usage==<br />
Windows 9x does not use hlt instruction, so the emulator always eats up 100% CPU even if no computation is being done. Grab the file http://www.user.cityline.ru/~maxamn/amnhltm.zip, unpack it, copy it to the image and run the .bat file.<br />
<br />
== Using the Kernel-based Virtual Machine ==<br />
<br />
[[KVM]] is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. Using KVM, one can run multiple virtual machines running unmodified Linux or Windows images. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc.<br />
<br />
This technology requires an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions. It is included in the mainline Linux kernel since 2.6.20 and is enabled by default in the Arch Linux kernel.<br />
<br />
Even though QEMU in recent versions do have initial KVM support ({{codeline|qemu --enable-kvm}}), it is not recommended to use this, as many KVM-related functions still have not been implemented in upstream QEMU. Instead, you should go for the qemu-kvm package in [extra], which is released by the KVM development team and contain all of the latest features (and bugfixes) of KVM userspace. Please refer to the [[KVM]] page itself, for more information on using QEMU with KVM on Arch Linux.<br />
<br />
To take advantage of KVM, you simply need a compatible processor (the following command must return something on screen)<br />
<br />
egrep '^flags.*(vmx|svm)' /proc/cpuinfo<br />
<br />
And load the appropriate module from your [[rc.conf]]<br />
<br />
* For Intel® processors add {{codeline|kvm-intel}} to your {{codeline|MODULES}} array in {{filename|/etc/rc.conf}}<br />
* for AMD® processors add {{codeline|kvm-amd}} to your {{codeline|MODULES}} array in {{filename|/etc/rc.conf}}<br />
<br />
Also, you will need to add yourself to the group 'kvm'.<br />
<br />
==Networking==<br />
===Basic Networking===<br />
To add basic networking to your virtual machine, you may have to simply load QEMU with these options: {{codeline|<nowiki>-net nic,vlan=1 -net user,vlan=1</nowiki>}}. For example, to load a cdrom, you could use:<br />
qemu -kernel-kqemu -no-acpi -net nic,vlan=1 -net user,vlan=1 -cdrom dsl-4.3rc1.iso<br />
Note that this only supports the TCP and UDP protocols. In particular ICMP and thus ping will not work.<br />
<br />
=== Tap Networking with QEMU ===<br />
==== Basic Idea ====<br />
Tap networking in QEMU lets virtual machines register themselves as though with separate Ethernet adapters and have their traffic bridged directly onto your local area network. This is sometimes very desirable, if you want your virtual machines to be able to talk to each other, or for other machines on your LAN to talk to virtual machines.<br />
<br />
==== Security Warning ====<br />
You probably <b>should not</b> use this networking method if your host Arch machine is directly on the Internet. It can expose your virtual machines directly to attack!<br />
<br />
In general, Arch disclaims any responsibility for security implications (or implications of any kind, really) from following these instructions.<br />
<br />
==== Nitty Gritty ====<br />
To set all this up, you will need to install the following packages:<br />
*bridge-utils (for brctl, to manipulate bridges)<br />
*uml_utilities (for tunctl, to manipulate taps)<br />
*[[sudo]] (for manipulating bridges and tunnels as root)<br />
<br />
# pacman -S bridge-utils uml_utilities sudo<br />
<br />
We will replace the normal Ethernet adapter with a bridge adapter and bind the normal Ethernet adapter to it. See http://en.gentoo-wiki.com/wiki/KVM#Networking_2 .<br />
<br />
Make sure IPv4 forwarding is set. You should have the line {{codeline|<nowiki>systcl net.ipv4.ip_forward=1</nowiki>}} in your {{filename|/etc/sysctl.conf}}.<br />
<br />
Take the following steps:<br />
<br />
1. Add <code>bridge</code> and <code>tun</code> to your <code>MODULES</code> line in {{filename|/etc/rc.conf}}:<br />
<br />
MODULES=( ... bridge tun)<br />
<br />
2. Configure your bridge <code>br0</code> to have your real ethernet adapter (herein assumed <code>eth0</code>) in it, in {{filename|/etc/conf.d/bridges}}:<br />
bridge_br0="eth0"<br />
control_br0="setfd br0 0"<br />
BRIDGE_INTERFACES=(br0)<br />
<br />
{{Note|This is not described anywhere, but adding the control_br0 line is vital for the bridge to work! For more details look here: https://bugs.archlinux.org/task/16625}}<br />
<br />
3. Change your networking configuration so that you just bring up your real ethernet adapter without configuring it, allowing real configuration to happen on the bridge interface. In {{filename|/etc/rc.conf}}:<br />
eth0="eth0 up"<br />
br0="dhcp"<br />
INTERFACES=(eth0 br0)<br />
<br />
Remember, especially if you are doing DHCP, it is essential that the bridge comes up AFTER the real adapter, otherwise the bridge will not be able to talk to anything to get a DHCP address!<br />
<br />
If DHCP does not work, try with a static IP address in {{filename|/etc/rc.conf}}:<br />
eth0="eth0 0.0.0.0"<br />
br0="br0 192.168.0.3 netmask 255.255.255.0 broadcast 192.168.0.255"<br />
INTERFACES=(eth0 br0)<br />
gateway="default gw 192.168.0.1"<br />
ROUTES=(gateway)<br />
<br />
and then in {{filename|/etc/resolv.conf}}:<br />
domain lan<br />
nameserver 192.168.0.1<br />
<br />
4. Install the script that QEMU uses to bring up the tap adapter in {{filename|/etc/qemu-ifup}} with root:kvm 750 permissions:<br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifup"<br />
echo "Bringing up $1 for bridged mode..."<br />
sudo /sbin/ifconfig $1 0.0.0.0 promisc up<br />
echo "Adding $1 to br0..."<br />
sudo /usr/sbin/brctl addif br0 $1<br />
sleep 2<br />
<br />
5. Use <code>visudo</code> to add the following to your <code>sudoers</code> file:<br />
Cmnd_Alias QEMU=/sbin/ifconfig,/sbin/modprobe,/usr/sbin/brctl,/usr/bin/tunctl<br />
%kvm ALL=NOPASSWD: QEMU<br />
<br />
6. Make sure the user(s) wishing to use this new functionality are in the kvm group. Exit and log in again if necessary.<br />
<br />
7. You launch qemu using the following <code>run-qemu</code> script:<br />
#!/bin/bash<br />
USERID=`whoami`<br />
IFACE=$(sudo tunctl -b -u $USERID)<br />
<br />
qemu-kvm -net nic -net tap,ifname="$IFACE" $*<br />
<br />
sudo tunctl -d $IFACE &> /dev/null<br />
<br />
Then to launch a VM, do something like this<br />
$ run-qemu -hda myvm.img -m 512 -vga std<br />
<br />
8. If you cannot get a DHCP address in the host, it might be because the iptables are up by default in the bridge. In that case (from http://www.linux-kvm.org/page/Networking ):<br />
# cd /proc/sys/net/bridge<br />
# ls<br />
bridge-nf-call-arptables bridge-nf-call-iptables<br />
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged<br />
# for f in bridge-nf-*; do echo 0 > $f; done<br />
<br />
And when you still cannot get networking to work, see: [[Linux_Containers#Bridge_device_setup]]<br />
<br />
=== Networking with [[VDE2]] ===<br />
==== What is VDE? ====<br />
VDE stands for Virtual Distributed Ethernet. It started as an enhancement of [[User-mode Linux|uml]]_switch. It is a toolbox to manage virtual networks.<br />
<br />
The idea is to create virtual switches, which are basically sockets, and to "plug" both physical and virtual machines in them. The configuration I show here is quite simple; However, VDE is much more powerfull than this, it can plug virtual switches together, run them on different hosts and monitor the traffic in the switches. Your are invited to read [http://wiki.virtualsquare.org/wiki/index.php/Main_Page the documentation of the project].<br />
<br />
The advantage of this method is you do not have to add sudo privileges to your users. Regular users should not be allowed to run modprobe.<br />
<br />
==== Basics ====<br />
VDE is in extra, so...<br />
<br />
# pacman -S vde2<br />
<br />
In my config, i use tun/tap to create a virtual interface on my host. Load the tun module (or add it to your {{codeline|MODULES}} array in [[rc.conf]]):<br />
<br />
# modprobe tun<br />
<br />
Let's create the virtual switch:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group kvm<br />
<br />
This line creates the switch, create tap0, "plugs" it, and allows the users of the group kvm to use it.<br />
<br />
The interface is pluged, but not configured yet. Just do it:<br />
<br />
# ifconfig tap0 192.168.100.254 netmask 255.255.255.0<br />
<br />
That is all! Now, you just have to run kvm with this -net options as a normal user:<br />
<br />
$ qemu-kvm -net nic -net vde -hda ...<br />
<br />
Configure your guest as you would do in a physical network. I gave them static addresses and let them access the WAN using ip forwarding and masquerade on my host:<br />
<br />
# echo "1" > /proc/sys/net/ipv4/ip_forward<br />
# iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE<br />
<br />
==== Putting it together ====<br />
I added this init script to run all this at startup :<br />
<br />
#!/bin/bash <br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
case "$1" in<br />
start)<br />
stat_busy "Starting VDE Switch"<br />
vde_switch -tap tap0 -daemon -mod 660 -pidfile $PIDFILE -group kvm<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
echo "1" > /proc/sys/net/ipv4/ip_forward && \<br />
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE && \<br />
ifconfig tap0 192.168.100.254 netmask 255.255.255.0 && \<br />
stat_done || stat_fail<br />
fi<br />
;;<br />
stop)<br />
stat_busy "Stopping VDE Switch"<br />
# err.. well, i should remove the switch here...<br />
stat_done<br />
;;<br />
restart)<br />
$0 stop<br />
sleep 1<br />
# Aem.. As long as stop) is not implemented, this just fails<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}" <br />
esac<br />
exit 0<br />
<br />
Well, I know it is dirty and could be more configurable. Feel free to improve it. Vde has a rc srcipt too, but i had to make one anyway for the ip forwarding stuff.<br />
<br />
====Alternative method====<br />
If the above method does not work or you do not want to mess with kernel configs, TUN, dnsmasq and iptables you can do the following for the same result.<br />
<br />
vde_switch -daemon -mod 660 -group kvm<br />
<br />
slirpvde --dhcp --daemon<br />
<br />
Then to start the vm with a connection to the network of the host:<br />
<br />
kvm -net nic,macaddr=52:54:00:00:EE:03 -net vde whatever.qcow<br />
<br />
== Graphics ==<br />
QEMU can use different graphic outputs, std,cirrus,vmware,qxl,xenfs and vnc.<br />
With the vnc option you can run your guest standalone and connect to it via vnc. Other options are using std,vmware,cirrus:<br />
<br />
===std===<br />
With -vga std you can get a resolution up to 2560 x 1600 pixels.<br />
<br />
===vmware===<br />
Althought it is a bit buggy, it performances better than std and cirrus, on the guest install the vmware drivers<br />
pacman -S xf86-video-vmware xf86-input-vmmouse<br />
<br />
===windows guest===<br />
If you use a windows guest you might want to use rdp to connect to your guest vm. Use: (if you are using a vlan or are not in the same network as the guest)<br />
qemu -nographic -net user,hostfwd=tcp::5555-:3389<br />
The connect with either rdesktop or freerdp to the guest, for example:<br />
xfreerdp -g 2048x1152 localhost:5555 -z -x lan<br />
<br />
== Front-ends for QEMU ==<br />
There are a few GUI Front-ends for QEMU:<br />
* community/qemu-launcher<br />
* community/qemulator<br />
* community/qtemu<br />
<br />
==Keyboard seems broken / Arrow keys do not work==<br />
Should you find that some of your keys do not work or "press" the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in {{filename|/usr/share/qemu/keymaps}}.<br />
<pre><br />
qemu -k [keymap] [disk_image]<br />
</pre><br />
<br />
==Starting qemu virtual machines on boot==<br />
To run QEMU VM's on boot you can use following rc-script and config.<br />
<br />
{| border="1"<br />
|+ Config file options<br />
|-<br />
| QEMU_MACHINES || List of VMs to start<br />
|-<br />
| qemu_${vm}_type || QEMU binary to call. If specified will be prepended with '/usr/bin/qemu-' and that binary will be used to start VM. I.e. you can boot e.g. qemu-system-arm images with qemu_my_arm_vm_type="system-arm". If not specified, '/usr/bin/qemu' will be used.<br />
|-<br />
| qemu_${vm} || QEMU command line to start with. Will always be prepended with '-name ${vm} -pidfile /var/run/qemu/${vm}.pid -daemonize -nographic'.<br />
|-<br />
| qemu_${vm}_haltcmd || Command to shutdown VM safely. I am using '-monitor telnet:..' and poweroff my VMs via acpi by sending 'system_powerdown' to monitor. You can use ssh or some other ways.<br />
|-<br />
| qemu_${vm}_haltcmd_wait || How much time to wait for safe VM shutdown. Default is 30 seconds. rc-script will kill qemu process after this timeout.<br />
|}<br />
<br />
Config file example:<br />
{{File|name=/etc/conf.d/qemu.conf|content=<nowiki><br />
# VM's that should be started on boot<br />
# use the ! prefix to disable starting/stopping a VM<br />
QEMU_MACHINES=(vm1 vm2)<br />
<br />
# NOTE: following options will be prepended to qemu_${vm}<br />
# -name ${vm} -pidfile /var/run/qemu/${vm}.pid -daemonize -nographic<br />
<br />
qemu_vm1_type="system-x86_64"<br />
<br />
qemu_vm1="-enable-kvm -m 512 -hda /dev/mapper/vg0-vm1 -net nic,macaddr=DE:AD:BE:EF:E0:00 \<br />
-net tap,ifname=tap0 -serial telnet:localhost:7000,server,nowait,nodelay \<br />
-monitor telnet:localhost:7100,server,nowait,nodelay -vnc :0"<br />
<br />
qemu_vm1_haltcmd="echo 'system_powerdown' | nc.openbsd localhost 7100" # or netcat/ncat<br />
<br />
# You can use other ways to shutdown your VM correctly<br />
#qemu_vm1_haltcmd="ssh powermanager@vm1 sudo poweroff"<br />
<br />
# By default rc-script will wait 30 seconds before killing VM. Here you can change this timeout.<br />
#qemu_vm1_haltcmd_wait="30"<br />
<br />
qemu_vm2="-enable-kvm -m 512 -hda /srv/kvm/vm2.img -net nic,macaddr=DE:AD:BE:EF:E0:01 \<br />
-net tap,ifname=tap1 -serial telnet:localhost:7001,server,nowait,nodelay \<br />
-monitor telnet:localhost:7101,server,nowait,nodelay -vnc :1"<br />
<br />
qemu_vm2_haltcmd="echo 'system_powerdown' | nc.openbsd localhost 7101"<br />
</nowiki>}}<br />
<br />
rc-script:<br />
{{File|name=/etc/rc.d/qemu|content=<nowiki><br />
#!/bin/bash<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
[ -f /etc/conf.d/qemu.conf ] && source /etc/conf.d/qemu.conf<br />
<br />
PIDDIR=/var/run/qemu<br />
QEMU_DEFAULT_FLAGS='-name ${vm} -pidfile ${PIDDIR}/${vm}.pid -daemonize -nographic'<br />
QEMU_HALTCMD_WAIT=30<br />
<br />
case "$1" in<br />
start)<br />
[ -d "${PIDDIR}" ] || mkdir -p "${PIDDIR}"<br />
for vm in "${QEMU_MACHINES[@]}"; do<br />
if [ "${vm}" = "${vm#!}" ]; then<br />
stat_busy "Starting QEMU vm: ${vm}"<br />
eval vm_cmdline="\$qemu_${vm}"<br />
eval vm_type="\$qemu_${vm}_type"<br />
<br />
if [ -n "${vm_type}" ]; then<br />
vm_cmd="/usr/bin/qemu-${vm_type}"<br />
else<br />
vm_cmd='/usr/bin/qemu'<br />
fi<br />
<br />
eval "qemu_flags=\"${QEMU_DEFAULT_FLAGS}\""<br />
<br />
${vm_cmd} ${qemu_flags} ${vm_cmdline} >/dev/null<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
stat_done<br />
fi<br />
fi<br />
done<br />
add_daemon qemu<br />
;;<br />
<br />
stop)<br />
for vm in "${QEMU_MACHINES[@]}"; do<br />
if [ "${vm}" = "${vm#!}" ]; then<br />
# check pidfile presence and permissions<br />
if [ ! -r "${PIDDIR}/${vm}.pid" ]; then<br />
continue<br />
fi<br />
<br />
stat_busy "Stopping QEMU vm: ${vm}"<br />
<br />
eval vm_haltcmd="\$qemu_${vm}_haltcmd"<br />
eval vm_haltcmd_wait="\$qemu_${vm}_haltcmd_wait"<br />
vm_haltcmd_wait=${vm_haltcmd_wait:-${QEMU_HALTCMD_WAIT}}<br />
vm_pid=$(cat ${PIDDIR}/${vm}.pid)<br />
<br />
# check process existence<br />
if ! kill -0 ${vm_pid} 2>/dev/null; then<br />
stat_done<br />
rm -f "${PIDDIR}/${vm}.pid"<br />
continue<br />
fi<br />
<br />
# Try to shutdown VM safely<br />
_vm_running='yes'<br />
if [ -n "${vm_haltcmd}" ]; then<br />
eval ${vm_haltcmd} >/dev/null<br />
<br />
_w=0<br />
while [ "${_w}" -lt "${vm_haltcmd_wait}" ]; do<br />
sleep 1<br />
if ! kill -0 ${vm_pid} 2>/dev/null; then<br />
# no such process<br />
_vm_running=''<br />
break<br />
fi<br />
_w=$((_w + 1))<br />
done<br />
<br />
else<br />
# No haltcmd - kill VM unsafely<br />
_vm_running='yes'<br />
fi<br />
<br />
if [ -n "${_vm_running}" ]; then<br />
# kill VM unsafely<br />
kill ${vm_pid} 2>/dev/null<br />
sleep 1<br />
fi<br />
<br />
# report status<br />
if kill -0 ${vm_pid} 2>/dev/null; then<br />
# VM is still alive<br />
#kill -9 ${vm_pid}<br />
stat_fail<br />
else<br />
stat_done<br />
fi<br />
<br />
# remove pidfile<br />
rm -f "${PIDDIR}/${vm}.pid"<br />
fi<br />
done<br />
rm_daemon qemu<br />
;;<br />
<br />
restart)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
<br />
esac<br />
</nowiki>}}<br />
<br />
==External links==<br />
A very good QEMU guide by AlienBOB: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu</div>Buergihttps://wiki.archlinux.org/index.php?title=Sudo&diff=151775Sudo2011-08-13T13:22:56Z<p>Buergi: changed to neutral username "yourusername"</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[fr:Sudo]]<br />
{{i18n|Sudo}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the popular privilege escalation utility.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Access control overview}}}}<br />
{{Article summary end}}<br />
<br />
Sudo (su "do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.[http://www.gratisoft.us/sudo/]<br />
<br />
== Rationale ==<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
To install sudo:<br />
# pacman -Syu sudo<br />
<br />
Use of sudo will be unavailable to users until [[#Configuration|configured]].<br />
<br />
== Usage ==<br />
With sudo, users can prefix commands with {{Codeline|sudo}} to run them with superuser (or other) privileges. For example:<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
The configuration file for sudo is {{Filename|/etc/sudoers}}. '''This file should not be edited directly!'''<br />
<br />
=== Using visudo ===<br />
The {{Filename|/etc/sudoers}} file should always be edited with the {{Codeline|visudo}} command. {{Codeline|visudo}} locks the {{Filename|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{Filename|/etc/sudoers}}. It is imperative that {{Filename|sudoers}} be free of syntax errors since {{Codeline|sudo}} will not run otherwise.<br />
<br />
{{Warning|Errors in {{Filename|/etc/sudoers}} can render sudo unusable. '''Always''' edit it with {{Codeline|visudo}} to prevent errors.}}<br />
<br />
The default editor is {{Codeline|vi}}, which will be used if you do not preface the command with ''EDITOR=<editor>''. You can use other editors, for example, gedit:<br />
<br />
# EDITOR=gedit visudo<br />
<br />
You can permanently change the setting system-wide to e.g. {{Codeline|vim}} by appending<br />
export EDITOR=vim<br />
to your {{Filename|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
Or, change it permanently for just {{Codeline|visudo}} by adding the following line to {{Filename|/etc/sudoers}} where vim is your prefered editor:<br />
# Defaults specification<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to vim, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/vim, !env_editor<br />
<br />
Note you must still run the command {{Codeline|visudo}} as root even if using a different editor.<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with "sudo", add the following line:<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
and/or to allow a user sudo access from the local machine only:<br />
USER_NAME HOSTNAME=(ALL) ALL<br />
<br />
and/or to allow members of [[Groups|group]] wheel sudo access requiring no password:<br />
%wheel ALL=(ALL) NOPASSWD: ALL<br />
<br />
where USER_NAME is the user name of the individual.<br />
<br />
A detailed {{Filename|sudoers}} example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== sudoers default file permissions ===<br />
The owner and group for the sudoers file must both be 0. The file permissions should be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately.<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished by adding following to {{Filename|/etc/sudoers}} ({{Codeline|visudo}}) for example:<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
where the password expires for user USER_NAME if unused for over 20 minutes. Values between 0 and 1 are also allowed.<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to zero.}}<br />
<br />
== Tips and tricks ==<br />
<br />
===Enabling tab-completion in bash===<br />
<br />
Tab-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
fire<TAB><br />
<br />
and the shell will complete the command for him as:<br />
firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
sudo fire<TAB><br />
<br />
the shell will do nothing.<br />
<br />
To enable tab-completion with sudo, add the following to your {{Filename|~/.bashrc}}:<br />
complete -cf sudo<br />
<br />
Alternatively, you could also install and enable bash-completion to get smarter tab-completion for commands like sudo, see [[bash#Auto-completion]] for more information.<br />
<br />
===Run X11 apps using sudo===<br />
<br />
To allow sudo to start graphical application in X11, you need to add<br />
Defaults env_keep += "HOME"<br />
to visudo.<br />
<br />
===Disable per-terminal sudo===<br />
{{Warning|This will let any process use your sudo session}}<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables (Outdated?) ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via <tt>export http_proxy="..."</tt>, when using sudo these variables do not get passed to the root account unless you run sudo with the {{Codeline|-E}} option.<br />
$ sudo -E pacman -Syu<br />
<br />
Because of this you may wish to add an alias in {{Filename|~/.bashrc}}:<br />
alias sudo="sudo -E"<br />
<br />
Another way of fixing this would be to add in {{Filename|/etc/sudoers}}:<br />
Defaults !env_reset<br />
<br />
If you want to just pass <tt>*_proxy</tt> variables, add the following:<br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
<br />
=== Add /sbin and /usr/sbin to root's PATH ===<br />
<br />
If you want to run administrative commands (those in /sbin or /usr/sbin) with sudo without using their full path, add:<br />
Defaults secure_path="/bin:/sbin:/usr/bin:/usr/sbin" <br />
in {{Filename|/etc/sudoers}}.<br />
<br />
This allows you to do: <br />
$ sudo command<br />
instead of:<br />
$ sudo /sbin/command<br />
or:<br />
$ sudo /usr/sbin/command<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{Filename|~/.bashrc}} or {{Filename|/etc/bash.bashrc}}:<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{Filename|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{Codeline|sudo -K}} to end the current session a let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{Filename|/etc/sudoers}}:<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{Codeline|passwd}}:<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{Filename|/etc/shadow}} and replace the root's encrypted password with "!":<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{Filename|/usr/share/config/kdesurc}}:<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== Policykit ==== <br />
<br />
When disabling the root account, it is nessecary to change the policykit configuration for local authorification to reflect that. The default is to ask for root password, so that must be changed. With polkit-1, this can be achieved by editing /etc/polkit-1/localauthority.conf.d/50-localauthority.conf so that<br />
<br />
AdminIdentities=unix-user:0<br />
<br />
is replaced by something else, depending on the system configuration. It can be a list of users and groups, for example<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see man pklocalauthority<br />
<br />
== Debugging Sudo ==<br />
<br />
=== SSH TTY Issues ===<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's "-tt" option to force it to allocate a tty. (use -tt twice).<br />
<br />
The Defaults option requiretty only allows the user to run sudo if they have a tty<br />
<br />
<pre><br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
</pre><br />
<br />
=== Display User Privileges ===<br />
You can find out what privileges a particular user has with the following command:<br />
sudo -lU yourusename<br />
<br />
Or view your own with <br />
sudo -l<br />
<pre><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=sqpt.webmaster@gmail.com, mail_badpass, mail_no_user, mail_no_perms, env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
(ALL) ALL, <br />
(ALL) NOPASSWD: /usr/sbin/lsof, /bin/nice, /bin/netstat, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace, <br />
(ALL) /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill, <br />
(ALL) /usr/sbin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys, <br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc<br />
</pre><br />
<br />
== Example Sudoers ==<br />
This is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs.<br />
<pre><br />
<br />
Cmnd_Alias WHEELER = /usr/sbin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /bin/netstat, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/sbin/gparted, /usr/bin/pacman, /usr/bin/pacman-color<br />
<br />
root ALL = (ALL) ALL<br />
yourusename ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</pre></div>Buergihttps://wiki.archlinux.org/index.php?title=CUPS/Printer_sharing&diff=151663CUPS/Printer sharing2011-08-12T15:09:09Z<p>Buergi: /* Between GNU/Linux and Windows */ rework of whole section, added and reordered some subsections</p>
<hr />
<div>[[Category:Printers (English)]]<br />
{{i18n|CUPS printer sharing}}<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Setting up printer sharing using CUPS}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Samba}}<br />
{{Article summary wiki|CUPS}}<br />
{{Article summary end}}<br />
<br />
[[CUPS]] provides capabilities to set up printer sharing between different systems. Below you'll find instructions for common scenarios.<br />
<br />
==Between GNU/Linux systems==<br />
Once CUPS has been setup on the GNU/Linux print server, the recommended method of sharing the printer with another GNU/Linux system is through the relatively easy to use web interface, yet manual configuration is also a way.<br />
<br />
===Using the web interface===<br />
<br />
Access http://localhost:631 with a browser and the CUPS administration home page will be displayed. <br />
<br />
Click on the ''Administration'' tab near the top, select the add printer option and it should automatically detect the connected printer. If not, try turning off the printer and then back on before another attempt. <br />
<br />
Once the printer has been set up, look under the ''Server'' heading and click the checkbox for "Share printers connected to this system". Now, conclude by clicking ''change settings'' and the server will automatically restart. <br />
<br />
Selecting "Edit Configuration File" allows making direct edits to the {{Filename|cups.conf}} file. This is useful for allowing server access only to certain users or IP addresses, as the example shown below.<br />
<br />
===Manual setup===<br />
<br />
On the server computer (the one directly connected to the printer) simply open up {{Filename|/etc/cups/cupsd.conf}} and allow access to the server by modifying the location lines. For instance:<br />
<Location /><br />
Order allow,deny<br />
Allow localhost<br />
Allow 192.168.0.*<br />
</Location><br />
<br />
Also make sure the server is listening on the IP address the client will be addressing. Add the following line after "# Listen <serverip>:631" (using the server's IP address instead of client's 192.168.0.100):<br />
Listen 192.168.0.101:631<br />
<br />
To "Show shared printers on the local network", add the line "BrowseAllow all":<br />
Browsing On<br />
BrowseOrder allow,deny<br />
BrowseAllow @LOCAL<br />
BrowseAllow all<br />
<br />
After making modifications, restart CUPS by:<br />
# /etc/rc.d/cupsd restart<br />
<br />
On the client system, open up (create if not present) {{Filename|/etc/cups/client.conf}} and add the ServerName to match the IP address or the name of the server. Add this line:<br />
ServerName 192.168.0.101<br />
<br />
To "Show shared printers on the local network", add the line "BrowseAllow all":<br />
Browsing On<br />
BrowseOrder allow,deny<br />
BrowseAllow @LOCAL<br />
BrowseAllow all<br />
<br />
There are more configuration possibilities, including automatic methods, which are described in detail in http://localhost:631/help/network.html <!-- Someone with CUPS installed could rename the link to the page title --><br />
<br />
After making modifications, restart CUPS.<br />
<br />
{{Note|When adding the printer from the client, if using the Internet Printing Protocol (IPP), put the URI as ipp://192.168.0.101:631/printers/<name-of-printer>}}<br />
<br />
==Between GNU/Linux and Windows==<br />
<br />
===Linux server - Windows client===<br />
<br />
====Sharing via IPP====<br />
<br />
The '''preferred way''' to connect a Windows client to a Linux print server is using [http://de.wikipedia.org/wiki/Internet_Printing_Protocol IPP]. It's a standard printer protocol based on HTTP, allowing you all ways to profit from port forwarding, tunneling etc.<br />
The configuration is '''very easy''' and this way is less error-prone than using Samba.<br />
IPP is natively supported by Windows '''since Windows 2000'''.<br />
<br />
To configure the server side proceed as described in the section above to enable browsing.<br />
<br />
On the Windows computer, go to the printer control panel and choose to 'Add a New Printer'. Next, choose to give a URL. For the URL, type in the location of the printer: http://host_ip_address:631/printers/printer_name (where host_ip_address is the GNU/Linux server's IP address and printer_name is the name of the printer being connected to).<br />
<br />
After this, install the native printer drivers for your printer on the Windows computer. If the CUPS server is set up to use its own printer drivers, then you can just select a generic postscript printer for the Windows client(e.g. 'HP Color LaserJet 8500 PS' or 'Xerox DocuTech 135 PS2'). Then test the print setup by printing a test page.<br />
<br />
====Sharing via Samba====<br />
<br />
If your client's Windows version is below Windows 2000 or if you experienced troubles with IPP you can also use Samba for sharing.<br />
Note of course that with Samba this involves another complex piece of software. This makes this way '''more difficult to configure''' and thus sometimes also '''more error-prone''', mostly due do authentication problems.<br />
<br />
To configure Samba on the Linux server, edit {{Filename|/etc/samba/smb.conf}} file to allow access to printers. File {{Filename|smb.conf}} can look something like this:<br />
{{File|name=/etc/samba/smb.conf|content=<pre><br />
[global]<br />
workgroup=Heroes<br />
server string=Arch Linux Print Server<br />
security=user<br />
<br />
[printers]<br />
comment=All Printers<br />
path=/var/spool/samba<br />
browseable=yes<br />
# to allow user 'guest account' to print.<br />
guest ok=no<br />
writable=no<br />
printable=yes<br />
create mode=0700<br />
write list=@adm root yourusername<br />
</pre>}}<br />
<br />
That should be enough to share the printer, yet adding an individual printer entry may be desirable:<br />
{{File|name=/etc/samba/smb.conf|content=<pre><br />
[ML1250]<br />
comment=Samsung ML-1250 Laser Printer<br />
printer=ml1250<br />
path=/var/spool/samba<br />
printing=cups<br />
printable=yes<br />
printer admin=@admin root yourusername<br />
user client driver=yes<br />
# to allow user 'guest account' to print.<br />
guest ok=no<br />
writable=no<br />
write list=@adm root yourusername<br />
valid users=@adm root yourusername<br />
</pre>}}<br />
<br />
Please note that this assumes configuration was made so that users must have a valid account to access the printer. To have a public printer, set ''guest ok'' to ''yes'', and remove the ''valid users'' line. To add accounts, set up a regular GNU/Linux account and then set up a Samba password on the server. For instance:<br />
# useradd yourusername<br />
# smbpasswd -a yourusername<br />
<br />
<!--<br />
After setting up all the needed user accounts, the samba spool directory also needs configuration:<br />
<pre><br />
# mkdir /var/spool/samba<br />
# chmod 777 /var/spool/samba<br />
</pre><br />
<br />
The next items that need changing are {{Filename|/etc/cups/mime.convs}} and {{Filename|/etc/cups/mime.types}}:<br />
<br />
{{Filename|mime.convs}}:<br />
<pre><br />
# The following line is found at near the end of the file. Uncomment it.<br />
application/octet-stream application/vnd.cups-raw 0 -<br />
</pre><br />
<br />
{{Filename|mime.types}}:<br />
<pre><br />
# Again near the end of the file.<br />
application/octet-stream<br />
</pre><br />
<br />
The changes to {{Filename|mime.convs}} and {{Filename|mime.types}} are needed to make CUPS print Microsoft Office document files. Many users seem to need that.<br />
--><br />
<br />
After this, restart Samba daemon:<br />
# /etc/rc.d/samba restart<br />
<br />
Obviously, there are a lot of tweaks and customizations that can be done with setting up a Samba print server, so it is advised to look at the Samba and CUPS documentation for more help. The {{Filename|smb.conf.example}} file also has some good samples that might warrant imitating.<br />
<br />
<br />
===Windows server - Linux client===<br />
<br />
====Sharing via IPP====<br />
<br />
As above IPP is also the '''preferred''' protocol for printer sharing. However this way might be a bit '''more difficult''' than the native Samba approach below, since you need a greater effort to set up an IPP-Server on Windows.<br />
The commonly chosen server software is Microsoft's Internet Information Services (IIS).<br />
<br />
{{Note|This section is incomplete. Here is a description how to set up ISS, unfortunately in German [http://www.heise.de/netze/artikel/Ueberall-drucken-221652.html]}}<br />
<br />
====Sharing via Samba====<br />
<br />
A '''much simpler way''' is using Window's native printer sharing via Samba. There is almost no configuration needed, and all of it can be done from the CUPS Backend. As above noted, if there are any problems the reason is mostly related to authentication trouble and Windows access restrictions.<br />
<br />
On the server side enable sharing for your desired printer and ensure that the user on the client machine has the right to access the printer.<br />
<br />
The following section describes how to set up the client, assuming that both daemons (cupsd and smbd) are running.<br />
<br />
=====Configuration using the web interface=====<br />
<br />
The Samba CUPS back-end is enabled by default, if for any reason it is not activate it by entering the following command and restarting CUPS.<br />
# ln -s $(which smbspool) /usr/lib/cups/backend/smb<br />
<br />
Next, simply log in on the CUPS web interface and choose to add a new printer. As a device choose "Windows Printer via SAMBA".<br />
<br />
For the device location, enter:<br />
smb://username:password@hostname/printer_name<br />
<br />
Or without a password:<br />
smb://username@hostname/printer_name<br />
<br />
Make sure that the user actually has access to the printer on the Windows computer and select the appropriate drivers. If the computer is located on a domain, make sure the user-name includes the domain: <br />
smb://username:password@domain/hostname/printer_name<br />
<br />
If the network contains many printers you might want to set a preferred printer. To do so use the web interface, go into the printer tab, choose the desired printer and select 'Set as default' from the drop-down list.<br />
<br />
=====Manual configuration=====<br />
<br />
For manual configuration stop the CUPS daemon and add your printer to {{Filename|/etc/cups/printers.conf}}, which might for example look like this<br />
{{File|name=/etc/cups/printers.conf|content=<pre><br />
<DefaultPrinter MyPrinter><br />
AuthInfoRequired username,password<br />
Info My printer via SAMBA<br />
Location In my Office<br />
MakeModel Samsung ML-1250 - CUPS+Gutenprint v5.2.7 # <= use 'lpinfo -m' to list available models<br />
DeviceURI smb://username:password@hostname/printer_name # <= server URI as described in previous section<br />
State Idle<br />
Type 4<br />
Accepting Yes<br />
Shared No<br />
JobSheets none none<br />
QuotaPeriod 0<br />
PageLimit 0<br />
KLimit 0<br />
AllowUser yourusername # <= don't forget to change this<br />
OpPolicy default<br />
ErrorPolicy stop-printer<br />
</Printer><br />
</pre>}}<br />
<br />
Then restart the CUPS daemon an try to print a test page.<br />
<br />
To set the preferred printer use the following command <br />
# lpoptions -d desired_default_printer_name<br />
<br />
===Troubleshooting===<br />
<br />
If there are any problems, the first thing to do is enable debug information by setting<br />
<pre>LogLevel debug</pre> in {{Filename|/etc/cups/cupsd.conf}}.<br />
<br />
Then restart the CUPS daemon and check for error messages in {{Filename|/var/log/cups/error_log}}. A convenient way to do so is<br />
# tail -f /var/log/cups/error_log<br />
which keeps printing new error messages as the occur.<br />
<br />
Note: You can also use the web interface to browse this error file.<br />
<br />
==Other operating systems==<br />
More information on interfacing CUPS with other printing systems can be found in the CUPS manual, e.g. on http://localhost:631/sam.html#PRINTING_OTHER</div>Buergihttps://wiki.archlinux.org/index.php?title=SSH_keys&diff=151193SSH keys2011-08-10T13:20:25Z<p>Buergi: /* Simple method */ some notes added</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Security (English)]]<br />
{{i18n|Using SSH Keys}}<br />
<br />
==What are SSH Keys?==<br />
By using SSH Keys (a public and private key to be precise), you can easily connect to a server, or multiple servers, without having to enter your password for each system.<br />
<br />
It is possible to setup your keys without a passphrase, however that is unwise as if anyone gets hold of your key they can use it. This guide describes how to setup your system so that passphrases are remembered securely.<br />
<br />
===Generating SSH Keys===<br />
If you don't already have OpenSSH installed, install it now as it is not installed by default on Arch.<br />
<br />
# pacman -S openssh<br />
<br />
The keys can then be generated by running the ssh-keygen command as a user:<br />
<br />
$ ssh-keygen -b 521 -t ecdsa -C"$(id -un)@$(hostname)-$(date --rfc-3339=date)"<br />
Generating public/private ecdsa key pair.<br />
Enter file in which to save the key (/home/mith/.ssh/id_ecdsa):<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /home/mith/.ssh/id_ecdsa.<br />
Your public key has been saved in /home/mith/.ssh/id_ecdsa.pub.<br />
The key fingerprint is:<br />
3a:43:37:6d:e2:5b:97:e2:6f:e2:80:f9:23:97:70:0c mith@middleearth<br />
<br />
It will prompt you for a location (which you should leave as the default), however the passphrase is the important bit! You should already be aware of the criteria that make a good passphrase.<br />
<br />
So what did we just do? We generated a 521 bit long ({{Codeline|-b 521}}) public/private ECDSA ({{Codeline|-t ecdsa}}) key pair with an extended comment including the data ({{Codeline|-C"$(id -un)"@$(hostname)-$(date --rfc-3339&#61;date)}}) via the {{Codeline|ssh-keygen}} command.<br />
<br />
Note: These keys are used only to authenticate you, choosing stronger keys here will not reduce system performance when transfering data via ssh. <br />
<br />
Elliptic curve cryptography provides smaller key sizes and faster operations for equivalent estimated security. It was introduced as the preferred method for authentication in OpenSSH 5.7, see [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]. ECDSA keys might not be compatible with systems that ship old versions of OpenSSH.<br />
<br />
If you want to create a RSA (2048-4096 bit) or DSA (1024 bit) key pair instead of ECDSA just use {{Codeline|-t rsa}} or {{Codeline|-t dsa}} and don't forget to increase the key size, running {{Codeline|ssh-keygen}} without ({{Codeline|-b}}) will provide reasonable defaults.<br />
<br />
===Copying the keys to the remote server===<br />
Now you have generated the keys you need to copy them to the remote server.<br />
====Simple method====<br />
If your key file is named {{Filename|id_rsa.pub}} you can simply do<br />
$ ssh-copy-id your-server.org<br />
or if you need to use different user name<br />
$ ssh-copy-id your-login@your-server.org<br />
If your key filename is different you'll get an error saying "/usr/bin/ssh-copy-id: ERROR: No identities found". In this case you have to provide the location of the identity:<br />
$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub your-login@your-server.org<br />
<br />
====Traditional method====<br />
By default, for OpenSSH, the public key needs to be concatenated into {{Filename|~/.ssh/authorized_keys}}.<br />
<br />
$ scp ~/.ssh/id_ecdsa.pub mith@metawire.org:<br />
<br />
This copies the public key ({{Filename|id_dsa.pub}}) to your remote server via {{Codeline|scp}} (note the {{Codeline|:}} at the end of the server address). The file ends up in the home directory, but you can specify another path if you like.<br />
<br />
Next up, on the remote server, you need to create the {{Filename|~/.ssh}} directory if it doesn't exist and concatenate the key {{Filename|authorized_keys}} file:<br />
<br />
$ ssh mith@metawire.org<br />
mith@metawire.org's password:<br />
$ mkdir ~/.ssh<br />
$ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys<br />
$ rm ~/id_ecdsa.pub<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
The last two commands remove the public key from the server (which isn't needed now), and sets the correct permissions on the authorized_keys file.<br />
<br />
If you now disconnect from the server, and attempt to reconnect, you should be asked for the passphrase of the key:<br />
<br />
$ ssh mith@metawire.org<br />
Enter passphrase for key '/home/mith/.ssh/id_ecdsa':<br />
<br />
If you are unable to login with the key, double check the permissions on the {{Filename|authorized_keys}} file.<br />
<br />
Also check the permissions on the {{Filename|~/.ssh}} directory, which should have write permissions off for 'group' and 'other'. Run the following command to disable 'group' and 'other' write permissions for the {{Filename|~/.ssh}} directory:<br />
$ chmod go-w ~/.ssh<br />
<br />
==Remember key passphrases==<br />
Now you can login to your servers by using a key instead of a password, but how is this any easier, as you still need to enter the key passphrase? The answer is to use a SSH agent, a program which remembers the passphrases of your keys! There a number of different tools available, so have a read through and choose the one which seems best for you.<br />
<br />
===ssh-agent===<br />
ssh-agent is the default agent included with OpenSSH.<br />
<br />
$ ssh-agent<br />
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;<br />
SSH_AGENT_PID=2148; export SSH_AGENT_PID;<br />
echo Agent pid 2148;<br />
<br />
When you run {{Codeline|ssh-agent}}, it will print out what environment variables it would use. To make use of these variables, run the command through the {{Codeline|eval}} command.<br />
<br />
$ eval `ssh-agent`<br />
Agent pid 2157<br />
<br />
You can add this to {{Filename|/etc/profile}} so that it will be run whenever you open a session:<br />
<br />
# echo 'eval `ssh-agent`' >> /etc/profile<br />
<br />
Note the correct quotes, the outer ones are single quotes, where as the inner ones are backticks!<br />
<br />
Now that the {{Codeline|ssh-agent}} is running, we need to tell it that we have a private key and where that is.<br />
<br />
$ ssh-add ~/.ssh/id_ecdsa<br />
Enter passphrase for /home/user/.ssh/id_ecdsa:<br />
Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)<br />
<br />
We were asked for our passphrase, entered it, that's all. Now you can login to your remote server without having to enter your password while your private key is password-protected. Sweet isn't it?<br />
<br />
The only downside is that a new instance of {{Codeline|ssh-agent}} needs to be created for every new console (shell) you open, that means you have to run {{Codeline|ssh-add}} every time again on each console. There is a workaround to that with a program or rather a script called [http://www.gentoo.org/proj/en/keychain/index.xml keychain] which is covered in the next section.<br />
<br />
====Using GnuPG Agent====<br />
<br />
The [[GnuPG]] agent, distributed with the {{Package Official|gnupg2}} package, has OpenSSH agent emulation. If you use GPG you might consider using its agent to take care of all of your keys. Otherwise you might like the PIN entry dialog it provides and its passphrase management, which is different from keychain.<br />
<br />
To start using GPG agent for your SSH keys you should first start the gpg-agent with the {{Codeline|--enable-ssh-support}} option. Example (don't forget to make the file executable):<br />
{{File|name=/etc/profile.d/gpg-agent.sh|content=<nowiki><br />
#!/bin/sh<br />
<br />
# Start the GnuPG agent and enable OpenSSH agent emulation<br />
gnupginf="${HOME}/.gnupg/gpg-agent.info"<br />
<br />
if pgrep -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
eval `cat $gnupginf`<br />
eval `cut -d= -f1 $gnupginf | xargs echo export`<br />
else<br />
eval `gpg-agent --enable-ssh-support --daemon`<br />
fi<br />
</nowiki>}}<br />
<br />
Once gpg-agent is running you can use ssh-add to approve keys, just like you did with plain ssh-agent. The list of approved keys is stored in the {{Filename|~/.gnupg/sshcontrol}} file. Once your key is approved you will get a PIN entry dialog every time your passphrase is needed. You can control passphrase caching in the {{Filename|~/.gnupg/gpg-agent.conf}} file. The following example would have gpg-agent cache your keys for 3 hours: <br />
<br />
# Cache settings<br />
default-cache-ttl 10800<br />
default-cache-ttl-ssh 10800<br />
<br />
Other useful settings for this file include the PIN entry program (GTK, QT or ncurses version), keyboard grabbing and so on...:<br />
<br />
# Environment file<br />
write-env-file /home/username/.gnupg/gpg-agent.info<br />
<br />
# Keyboard control<br />
#no-grab<br />
<br />
# PIN entry program<br />
#pinentry-program /usr/bin/pinentry-curses<br />
#pinentry-program /usr/bin/pinentry-qt4<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
<br />
====Using keychain====<br />
<br />
[http://www.funtoo.org/en/security/keychain/intro/ Keychain] manages one or more specified private keys. When initialized it will ask for the passphrase for the private key(s) and store it. That way your private key is password protected but you won't have to enter your password over and over again.<br />
<br />
Install keychain from the extra repo:<br />
<br />
# pacman -S keychain<br />
<br />
Create the following file and make it executable:<br />
{{File|name=/etc/profile.d/keychain.sh|content=<nowiki><br />
eval `keychain --eval --nogui -Q -q id_ecdsa`<br />
</nowiki>}}<br />
<br />
Or<br />
<br />
{{File|name=/etc/profile.d/keychain.sh|content=<nowiki><br />
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_dsa<br />
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh<br />
</nowiki>}}<br />
<br />
Or<br />
<br />
Append <br />
eval `keychain --eval --agents ssh id_dsa`<br />
to your {{Filename|.bashrc}} or {{Filename|.bash_profile}}.<br />
<br />
{{Tip| If you want greater security replace -Q with --clear but will be less convenient.}}<br />
<br />
If necessary, replace {{Filename|~/.ssh/id_dsa}} with the path to your private key. For those using a non-Bash compatible shell, see {{Codeline|keychain --help}} or {{Codeline|man keychain}} for details on other shells.<br />
<br />
Close your shell and open it again. Keychain should come up and if it's your first run it will ask your for the passphrase of the specified private key.<br />
<br />
See also the next section to learn how to go about Xsessions and keychain. Of course, you do still not need to use ssh-agent manually. Just install on of the x11-ask-keypass variants and you are good to go.<br />
<br />
====Using ssh-agent and x11-ssh-askpass====<br />
<br />
You need to start the ssh-agent everytime you start a new Xsession. The ssh-agent will be closed when the X session ends.<br />
<br />
Install a variant of x11-ssh-askpass which will ask your passphrase everytime you open a new Xsession. Either use the original x11-ssh-askpass from [[AUR]] or go with either ksshaskpass (uses kdelibs):<br />
# pacman -S ksshaskpass<br />
or openssh-askpass (uses qt):<br />
# pacman -S openssh-askpass<br />
<br />
After installing these, closing your Xsession and relogging you will henceforth be asked your passphrase on Xsession init without any further work.<br />
<br />
===GNOME Keyring===<br />
If you use the [[GNOME]] desktop, the [[GNOME Keyring]] tool can be used as an SSH agent. Visit the [[GNOME Keyring]] article.<br />
<br />
==Troubleshooting==<br />
If it appears that the SSH server is ignoring your keys, ensure that you have the proper permissions set on all relevant files.<br />
<br />
For the local machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/id_ecdsa<br />
<br />
For the remote machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
Failing this, run the sshd in debug mode and monitor the output while connecting:<br />
<br />
# /usr/sbin/sshd -d<br />
<br />
==Useful Links / Information==<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc.html OpenSSH key management, Part 1]<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ OpenSSH key management, Part 2]<br />
* [http://www-106.ibm.com/developerworks/library/l-keyc3/ OpenSSH key management, Part 3]<br />
* [http://kimmo.suominen.com/docs/ssh/ Getting started with SSH]<br />
* [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]</div>Buergihttps://wiki.archlinux.org/index.php?title=SSH_keys&diff=151173SSH keys2011-08-10T07:22:11Z<p>Buergi: /* Generating SSH Keys */ tiny typo in command</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Security (English)]]<br />
{{i18n|Using SSH Keys}}<br />
<br />
==What are SSH Keys?==<br />
By using SSH Keys (a public and private key to be precise), you can easily connect to a server, or multiple servers, without having to enter your password for each system.<br />
<br />
It is possible to setup your keys without a passphrase, however that is unwise as if anyone gets hold of your key they can use it. This guide describes how to setup your system so that passphrases are remembered securely.<br />
<br />
===Generating SSH Keys===<br />
If you don't already have OpenSSH installed, install it now as it is not installed by default on Arch.<br />
<br />
# pacman -S openssh<br />
<br />
The keys can then be generated by running the ssh-keygen command as a user:<br />
<br />
$ ssh-keygen -b 521 -t ecdsa -C"$(id -un)@$(hostname)-$(date --rfc-3339=date)"<br />
Generating public/private ecdsa key pair.<br />
Enter file in which to save the key (/home/mith/.ssh/id_ecdsa):<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /home/mith/.ssh/id_ecdsa.<br />
Your public key has been saved in /home/mith/.ssh/id_ecdsa.pub.<br />
The key fingerprint is:<br />
3a:43:37:6d:e2:5b:97:e2:6f:e2:80:f9:23:97:70:0c mith@middleearth<br />
<br />
It will prompt you for a location (which you should leave as the default), however the passphrase is the important bit! You should already be aware of the criteria that make a good passphrase.<br />
<br />
So what did we just do? We generated a 521 bit long ({{Codeline|-b 521}}) public/private ECDSA ({{Codeline|-t ecdsa}}) key pair with an extended comment including the data ({{Codeline|-C"$(id -un)"@$(hostname)-$(date --rfc-3339&#61;date)}}) via the {{Codeline|ssh-keygen}} command.<br />
<br />
Note: These keys are used only to authenticate you, choosing stronger keys here will not reduce system performance when transfering data via ssh. <br />
<br />
Elliptic curve cryptography provides smaller key sizes and faster operations for equivalent estimated security. It was introduced as the preferred method for authentication in OpenSSH 5.7, see [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]. ECDSA keys might not be compatible with systems that ship old versions of OpenSSH.<br />
<br />
If you want to create a RSA (2048-4096 bit) or DSA (1024 bit) key pair instead of ECDSA just use {{Codeline|-t rsa}} or {{Codeline|-t dsa}} and don't forget to increase the key size, running {{Codeline|ssh-keygen}} without ({{Codeline|-b}}) will provide reasonable defaults.<br />
<br />
===Copying the keys to the remote server===<br />
Now you have generated the keys you need to copy them to the remote server.<br />
====Simple method====<br />
$ ssh-copy-id your-server.org<br />
or if you need to use different user name<br />
$ ssh-copy-id your-login@your-server.org<br />
If you get an error saying "/usr/bin/ssh-copy-id: ERROR: No identities found" you must provide the location of the identity:<br />
$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub your-login@your-server.org<br />
<br />
====Traditional method====<br />
By default, for OpenSSH, the public key needs to be concatenated into {{Filename|~/.ssh/authorized_keys}}.<br />
<br />
$ scp ~/.ssh/id_ecdsa.pub mith@metawire.org:<br />
<br />
This copies the public key ({{Filename|id_dsa.pub}}) to your remote server via {{Codeline|scp}} (note the {{Codeline|:}} at the end of the server address). The file ends up in the home directory, but you can specify another path if you like.<br />
<br />
Next up, on the remote server, you need to create the {{Filename|~/.ssh}} directory if it doesn't exist and concatenate the key {{Filename|authorized_keys}} file:<br />
<br />
$ ssh mith@metawire.org<br />
mith@metawire.org's password:<br />
$ mkdir ~/.ssh<br />
$ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys<br />
$ rm ~/id_ecdsa.pub<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
The last two commands remove the public key from the server (which isn't needed now), and sets the correct permissions on the authorized_keys file.<br />
<br />
If you now disconnect from the server, and attempt to reconnect, you should be asked for the passphrase of the key:<br />
<br />
$ ssh mith@metawire.org<br />
Enter passphrase for key '/home/mith/.ssh/id_ecdsa':<br />
<br />
If you are unable to login with the key, double check the permissions on the {{Filename|authorized_keys}} file.<br />
<br />
Also check the permissions on the {{Filename|~/.ssh}} directory, which should have write permissions off for 'group' and 'other'. Run the following command to disable 'group' and 'other' write permissions for the {{Filename|~/.ssh}} directory:<br />
$ chmod go-w ~/.ssh<br />
<br />
==Remember key passphrases==<br />
Now you can login to your servers by using a key instead of a password, but how is this any easier, as you still need to enter the key passphrase? The answer is to use a SSH agent, a program which remembers the passphrases of your keys! There a number of different tools available, so have a read through and choose the one which seems best for you.<br />
<br />
===ssh-agent===<br />
ssh-agent is the default agent included with OpenSSH.<br />
<br />
$ ssh-agent<br />
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;<br />
SSH_AGENT_PID=2148; export SSH_AGENT_PID;<br />
echo Agent pid 2148;<br />
<br />
When you run {{Codeline|ssh-agent}}, it will print out what environment variables it would use. To make use of these variables, run the command through the {{Codeline|eval}} command.<br />
<br />
$ eval `ssh-agent`<br />
Agent pid 2157<br />
<br />
You can add this to {{Filename|/etc/profile}} so that it will be run whenever you open a session:<br />
<br />
# echo 'eval `ssh-agent`' >> /etc/profile<br />
<br />
Note the correct quotes, the outer ones are single quotes, where as the inner ones are backticks!<br />
<br />
Now that the {{Codeline|ssh-agent}} is running, we need to tell it that we have a private key and where that is.<br />
<br />
$ ssh-add ~/.ssh/id_ecdsa<br />
Enter passphrase for /home/user/.ssh/id_ecdsa:<br />
Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)<br />
<br />
We were asked for our passphrase, entered it, that's all. Now you can login to your remote server without having to enter your password while your private key is password-protected. Sweet isn't it?<br />
<br />
The only downside is that a new instance of {{Codeline|ssh-agent}} needs to be created for every new console (shell) you open, that means you have to run {{Codeline|ssh-add}} every time again on each console. There is a workaround to that with a program or rather a script called [http://www.gentoo.org/proj/en/keychain/index.xml keychain] which is covered in the next section.<br />
<br />
====Using GnuPG Agent====<br />
<br />
The [[GnuPG]] agent, distributed with the {{Package Official|gnupg2}} package, has OpenSSH agent emulation. If you use GPG you might consider using its agent to take care of all of your keys. Otherwise you might like the PIN entry dialog it provides and its passphrase management, which is different from keychain.<br />
<br />
To start using GPG agent for your SSH keys you should first start the gpg-agent with the {{Codeline|--enable-ssh-support}} option. Example (don't forget to make the file executable):<br />
{{File|name=/etc/profile.d/gpg-agent.sh|content=<nowiki><br />
#!/bin/sh<br />
<br />
# Start the GnuPG agent and enable OpenSSH agent emulation<br />
gnupginf="${HOME}/.gnupg/gpg-agent.info"<br />
<br />
if pgrep -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
eval `cat $gnupginf`<br />
eval `cut -d= -f1 $gnupginf | xargs echo export`<br />
else<br />
eval `gpg-agent --enable-ssh-support --daemon`<br />
fi<br />
</nowiki>}}<br />
<br />
Once gpg-agent is running you can use ssh-add to approve keys, just like you did with plain ssh-agent. The list of approved keys is stored in the {{Filename|~/.gnupg/sshcontrol}} file. Once your key is approved you will get a PIN entry dialog every time your passphrase is needed. You can control passphrase caching in the {{Filename|~/.gnupg/gpg-agent.conf}} file. The following example would have gpg-agent cache your keys for 3 hours: <br />
<br />
# Cache settings<br />
default-cache-ttl 10800<br />
default-cache-ttl-ssh 10800<br />
<br />
Other useful settings for this file include the PIN entry program (GTK, QT or ncurses version), keyboard grabbing and so on...:<br />
<br />
# Environment file<br />
write-env-file /home/username/.gnupg/gpg-agent.info<br />
<br />
# Keyboard control<br />
#no-grab<br />
<br />
# PIN entry program<br />
#pinentry-program /usr/bin/pinentry-curses<br />
#pinentry-program /usr/bin/pinentry-qt4<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
<br />
====Using keychain====<br />
<br />
[http://www.funtoo.org/en/security/keychain/intro/ Keychain] manages one or more specified private keys. When initialized it will ask for the passphrase for the private key(s) and store it. That way your private key is password protected but you won't have to enter your password over and over again.<br />
<br />
Install keychain from the extra repo:<br />
<br />
# pacman -S keychain<br />
<br />
Create the following file and make it executable:<br />
{{File|name=/etc/profile.d/keychain.sh|content=<nowiki><br />
eval `keychain --eval --nogui -Q -q id_ecdsa`<br />
</nowiki>}}<br />
<br />
Or<br />
<br />
{{File|name=/etc/profile.d/keychain.sh|content=<nowiki><br />
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_dsa<br />
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh<br />
</nowiki>}}<br />
<br />
Or<br />
<br />
Append <br />
eval `keychain --eval --agents ssh id_dsa`<br />
to your {{Filename|.bashrc}} or {{Filename|.bash_profile}}.<br />
<br />
{{Tip| If you want greater security replace -Q with --clear but will be less convenient.}}<br />
<br />
If necessary, replace {{Filename|~/.ssh/id_dsa}} with the path to your private key. For those using a non-Bash compatible shell, see {{Codeline|keychain --help}} or {{Codeline|man keychain}} for details on other shells.<br />
<br />
Close your shell and open it again. Keychain should come up and if it's your first run it will ask your for the passphrase of the specified private key.<br />
<br />
See also the next section to learn how to go about Xsessions and keychain. Of course, you do still not need to use ssh-agent manually. Just install on of the x11-ask-keypass variants and you are good to go.<br />
<br />
====Using ssh-agent and x11-ssh-askpass====<br />
<br />
You need to start the ssh-agent everytime you start a new Xsession. The ssh-agent will be closed when the X session ends.<br />
<br />
Install a variant of x11-ssh-askpass which will ask your passphrase everytime you open a new Xsession. Either use the original x11-ssh-askpass from [[AUR]] or go with either ksshaskpass (uses kdelibs):<br />
# pacman -S ksshaskpass<br />
or openssh-askpass (uses qt):<br />
# pacman -S openssh-askpass<br />
<br />
After installing these, closing your Xsession and relogging you will henceforth be asked your passphrase on Xsession init without any further work.<br />
<br />
===GNOME Keyring===<br />
If you use the [[GNOME]] desktop, the [[GNOME Keyring]] tool can be used as an SSH agent. Visit the [[GNOME Keyring]] article.<br />
<br />
==Troubleshooting==<br />
If it appears that the SSH server is ignoring your keys, ensure that you have the proper permissions set on all relevant files.<br />
<br />
For the local machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/id_ecdsa<br />
<br />
For the remote machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
Failing this, run the sshd in debug mode and monitor the output while connecting:<br />
<br />
# /usr/sbin/sshd -d<br />
<br />
==Useful Links / Information==<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc.html OpenSSH key management, Part 1]<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ OpenSSH key management, Part 2]<br />
* [http://www-106.ibm.com/developerworks/library/l-keyc3/ OpenSSH key management, Part 3]<br />
* [http://kimmo.suominen.com/docs/ssh/ Getting started with SSH]<br />
* [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]</div>Buergihttps://wiki.archlinux.org/index.php?title=3D_Mouse&diff=1464093D Mouse2011-06-16T15:19:35Z<p>Buergi: added some info, dropped some useless parts, rework of wiki code (templates,removed <br> etc.)</p>
<hr />
<div>[[Category:Hardware Compatibility List (English)]]<br />
== What is a 3D Mouse? ==<br />
<br />
''"Also known as bats, flying mice, or wands, these devices generally function through ultrasound and provide at least three degrees of freedom. Probably the best known example would be 3DConnexion/Logitech's SpaceMouse from the early 1990s."'' - Wikipedia<br />
<br />
For more information: http://www.3dconnexion.com/products/what-is-a-3d-mouse.html<br />
<br />
== 3DConnexions 3D Mouse ==<br />
'''NOTE: The following instructions have been tested and proven to work on the most basic model (Space Navigator).'''<br />
<br />
=== Installation ===<br />
<br />
1. Plug your 3D mouse into your USB port. Use {{Codeline|lsusb}} to check if it was recognised <br />
{{cli|1=$> lsusb<br />
Bus 003 Device 002: ID 046d:c626 Logitech, Inc. 3Dconnexion Space Navigator 3D Mouse}}<br />
<br />
2. Install {{Package Official|openmotif}} or if you need {{Package Official|lesstif}} (e.g. for {{Package Official|xpdf}}) you can just get the {{Filename|libXm.so.4}} library from it:<br />
{{cli|1=$> sudo pacman -Sw openmotif # download openmotif to cache, don't install<br />
$> tar xJOf /var/cache/pacman/pkg/openmotif-* usr/lib/libXm.so.4.0.3 > libXm.so.4<br />
$> sudo mv libXm.so.4 /usr/lib/libXm.so.4}}<br />
<br />
3. Symlink {{Filename|libXm.so.4}} to {{Filename|libXm.so.3}}<br />
{{cli|1=$> sudo ln -s /usr/lib/libXm.so.4 /usr/lib/libXm.so.3}}<br />
<br />
4. The driver has some problems to get the username from {{Filename|/var/run/utmp}} and will output a "failed to get user" error.<br />
<br />
To fix this problem compile the following program. It appends the given username to {{Filename|/var/run/utmp}} in such a way that the driver can read it.<br />
{{File|3dmouse.c|<nowiki><br />
/* source: http://forums.gentoo.org/viewtopic-t-609224.html<br />
* http://www.3dconnexion.com/forum/viewtopic.php?t=1039<br />
*/<br />
#include <stdio.h><br />
#include <string.h><br />
#include <stdlib.h><br />
#include <utmpx.h><br />
<br />
int main(int argc, char ** argv) {<br />
if (argc != 2) {<br />
fprintf(stderr, "Need a name to put in the structure\n");<br />
exit(1);<br />
}<br />
struct utmpx u;<br />
memset(&u, 0, sizeof(u));<br />
u.ut_type = USER_PROCESS;<br />
u.ut_pid = getpid();<br />
strcpy(u.ut_id, ":0");<br />
strcpy(u.ut_line, ":0");<br />
strcpy(u.ut_user, argv[1]);<br />
setutxent();<br />
pututxline(&u);<br />
endutxent();<br />
} <br />
</nowiki>}}<br />
{{cli|1=$> gcc 3dmouse.c -o 3dmouse<br />
$> sudo ./3dmouse root}}<br />
<br />
5. Download the linux drivers to {{Filename|/tmp}} from here: http://www.3dconnexion.com/service/drivers.html<br />
<br />
6. Unpack the install script and run it<br />
{{cli|1=$> tar xfz 3dxware-linux-v1-5-2.i386.tar.gz install-3dxunix.sh<br />
$> sudo ./install-3dxunix.sh<br />
Password:<br />
<br />
<nowiki><br />
This installs 3DxWareUnix V1.5.2 on this machine. Continue? (y/n) [y]<br />
y<br />
<br />
Choose one of the following platforms:<br />
<br />
1. HP-UX<br />
2. Solaris<br />
3. AIX 5<br />
4. Linux<br />
5. Exit<br />
<br />
Please enter your choice (1-5)[4]:<br />
4<br />
<br />
<br />
Installing files for 3DxWare for Unix / linux......<br />
<br />
Uninstalling a running driver. Please wait ...<br />
Done.<br />
<br />
Converting default configs V5.x to V5.3.<br />
(User configs will be converted when used)<br />
Please wait a moment...<br />
Converting configs... found 27 configurations<br />
Configuration file Configuration name Version Status<br />
/etc/3DxWare/UGSNX2_01.scg ("UGS NX 2 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/4DNav.scg ("4D Navigator ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX5_02.scg ("UGS NX 5 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/CatiaV5_02.scg ("CATIA V5 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/Maya2011.scg ("Maya 2011 ") 5.3 Ok.<br />
/etc/3DxWare/CatiaV4_01.scg ("CATIA V4 ") 5.3 Ok.<br />
/etc/3DxWare/Patran_01.scg ("Patran ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX4_01.scg ("UGS NX 4 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/Pr(...)ire_02.scg ("ProE Wildfire config 02 ") 5.3 Ok.<br />
/etc/3DxWare/Pr(...)ire_01.scg ("ProE Wildfire config 01 ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX2_02.scg ("UGS NX 2 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/CatiaV5_03.scg ("CATIA V5 config 03 ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX3_02.scg ("UGS NX 3 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/default_10.scg ("Driver Protocol 1.0 ") 5.3 Ok.<br />
/etc/3DxWare/CADDS_R14.scg ("CADDS5 R14 + ") 5.3 Ok.<br />
/etc/3DxWare/CatiaV5_01.scg ("CATIA V5 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/DMUNav.scg ("DMU Navigator ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX4_02.scg ("UGS NX 4 config 02 ") 5.3 Ok.<br />
/etc/3DxWare/Enovia_VPM.scg ("Enovia VPM ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX5_01.scg ("UGS NX 5 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/ICEM_MED.scg ("ICEM MED ") 5.3 Ok.<br />
/etc/3DxWare/CADDS_R13.scg ("CADDS5 -R13 ") 5.3 Ok.<br />
/etc/3DxWare/DVise.scg ("DVise ") 5.3 Ok.<br />
/etc/3DxWare/Op(...)alizer.scg ("Optegra Visualizer ") 5.3 Ok.<br />
/etc/3DxWare/UGSNX3_01.scg ("UGS NX 3 config 01 ") 5.3 Ok.<br />
/etc/3DxWare/IDEAS_01.scg ("IDEAS ") 5.3 Ok.<br />
/etc/3DxWare/default.scg ("Any Application ") 5.3 Ok.<br />
<br />
Done.<br />
<br />
Do you want 3DxWareUnix being started with every login (from the /etc/inittab)? (y/n) [y]<br />
n<br />
<br />
Please start the driver manually. [/etc/3DxWare/daemon/3dxsrv -d <port>]<br />
<br />
****************************************************************<br />
For testing purposes you can find the demos<br />
xcube and xvalues at /tmp<br />
****************************************************************<br />
</nowiki>}}<br />
NOTE: I chose not to run the driver everytime I login.<br />
<br />
7. You can run the driver manually by calling it like this (for USB version):<br />
{{cli|1=$> sudo /etc/3DxWare/daemon/3dxsrv -d USB}}<br />
<br />
8. You should now have a working 3D mouse in Arch Linux!<br />
You can test it by extracting the demos from the driver archive.<br />
{{cli|1=$> tar xfz 3dxware-linux-v1-5-2.i386.tar.gz xcube<br />
$> ./xcube}}<br />
<br />
== More Information ==<br />
* [http://www.3dconnexion.com/forum/viewforum.php?f=22 3dconnexion linux forum]<br />
* [http://www.3dconnexion.com/forum/viewtopic.php?t=1039 Source of C program used]<br />
* [http://www.3dconnexion.com/forum/viewtopic.php?t=1757 Information about libXm.so.4 and libXm.so.3]</div>Buergihttps://wiki.archlinux.org/index.php?title=Powerpill&diff=142978Powerpill2011-05-28T18:04:00Z<p>Buergi: Added note with link to Improve_Pacman_Performance#Using_aria2</p>
<hr />
<div>[[Category:Package management (English)]]<br />
{{i18n|Powerpill}}<br />
{{Warning|''Powerpill'' development has been officially discontinued: its latest version does not work with ''pacman>&#61;3.5''. See [https://bbs.archlinux.org/viewtopic.php?id&#61;115660].}}<br />
{{Note|There exist other ways to use aria2 for package retrieval. See [[Improve_Pacman_Performance#Using_aria2]]}}<br />
<br />
==Introduction==<br />
Powerpill is a wrapper script written by Xyne for [[pacman]] that speeds up package retrieval by using aria2c for concurrent/segmented downloads. It determines the target packages of requested synchronization operation and then uses the mirrorlist to create a comprehensive metalink. This metalink is then piped to the download manager aria2 for package retrieval. Significant reductions in download times are often possible due to the combined effects of simultaneous and segmented downloads.<br />
<br />
Example: One wants to update and issues a ''pacman -Syu'' which returns a list of 20 packages that are available for update totally 200 megs. If the user downloads them via pacman, they will come down one-at-a-time. If the user downloads them via powerpill, they will come down simultaneously in many cases several times faster (depending on one's connection speed, the availability of packages on servers, and speed from server/load, etc.)<br />
<br />
A test of pacman vs. powerpill on one system revealed a 4x speed up in the above scenario where the pacman downloads averages 300 kB/sec and the powerpill downloads averaged 1.2 MB/sec.<br />
<br />
==Installation==<br />
You can get it from http://xyne.archlinux.ca/old_projects/powerpill/<br />
<br />
Make sure you have the package ''perl-crypt-ssleay'' installed, or you won't be able to use the '''Reflector option''' (read below)<br />
<br />
# pacman -S perl-crypt-ssleay<br />
<br />
==Configuration==<br />
Powerpill has a single configure file {{Filename|/etc/powerpill.conf}} you can edit to your liking. Most of it is well commented and obvious to the user.<br />
== Using Reflector ==<br />
By default, Powerpill is configured to use [[Reflector]] to append a list of the 45 most recently updated servers to its internal server list. This is to make sure that there are enough servers in the list for significant speed improvements. As this does not take server speed into account, the user may wish to set a aria2's lowest-speed-limit option in the aria2_options section of /etc/powerpill.conf:<br />
<br />
#lowest-speed-limit=10K<br />
<br />
It is also possible to change the {{Codeline|1=Reflect = -l 45}} to get the fastest mirrors instead of the most recent but this is not recommended as the time it takes to rank the mirrors will be greater than the time it takes to download the packages in most cases.<br />
<br />
The user may also simply comment out the "Reflect" line but in that case the user should have as many mirrors in their {{Filename|/etc/pacman.d/mirrorlist}} as the maximum number of connections in /etc/powerpill.conf. Powerpill relies on access to multiple mirrors to speed up downloads.<br />
<br />
==Basic Usage==<br />
For most operations, powerpill works just like pacman since it is a wrapper script for pacman.<br />
<br />
===System Updating===<br />
To update your system (sync and update installed packages) using powerpill, simply pass the -Syu options to it as you would with pacman:<br />
<br />
# powerpill -Syu<br />
<br />
===Installation of packages===<br />
To install a package and its deps, simply use powerpill with the -S option as you would with pacman:<br />
<br />
# powerpill -S package<br />
<br />
You may also install multiple packages with it the same way you would with pacman:<br />
<br />
# powerpill -S package1 package2 package3</div>Buergihttps://wiki.archlinux.org/index.php?title=OfflineIMAP&diff=114504OfflineIMAP2010-08-20T21:00:32Z<p>Buergi: /* netrc authentication */ fixed wrong template</p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://software.complete.org/software/projects/show/offlineimap OfflineIMAP] is an utility to sync mail from IMAP servers. It does not work with the POP3 protocol or mbox, and is usually paired with a MUA such as [[Mutt]].<br />
<br />
As of 06/26/2010, offlineimap is [http://article.gmane.org/gmane.mail.imap.offlineimap.general/1759 unmaintained].<br />
<br />
==Installing==<br />
Install the {{package Official|offlineimap}} package with [[pacman]]:<br />
# pacman -S offlineimap<br />
<br />
==Configuring==<br />
The example configuration that is distributed with offlineimap contains every setting and is thorougly documented.<br />
<br />
Copy it to {{filename|~/.offlinimaprc}} and edit it:<br />
$ cp /usr/share/offlineimap/offlineimap.conf ~/.offlineimaprc<br />
$ vi ~/.offlineimaprc<br />
<br />
Take care that comments are placed on their own separate line, since writing a comment after an option/value on the same line is invalid syntax.<br />
<br />
===Quick-start===<br />
Following is a commented version of {{filename|/usr/share/offlineimap.conf.minimal}}. The setup only contains settings that are absolutely necessary.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This should contain a space delimited list of all identifiers of the accounts<br />
# that are to be synced<br />
accounts = main<br />
# If there are two accounts; `main' and `alternative'...<br />
#accounts = main alternative<br />
<br />
[Account main]<br />
# The identifier for the local repository; i.e., the maildir that offlineimap<br />
# will sync with an IMAP server<br />
localrepository = main-local<br />
# The identifier for the remote repository. This is the actual IMAP, which is<br />
# usually foreign to the system<br />
remoterepository = main-remote<br />
<br />
[Repository main-local]<br />
# Currently, offlineimap only supports maildir and IMAP for local repositories<br />
type = Maildir<br />
# Where should the mail be placed?<br />
localfolders = ~/.mail/main<br />
<br />
[Repository mail-remote]<br />
# Remote repos can be IMAP or Gmail, the latter being a preconfigured IMAP<br />
type = IMAP<br />
remoteuser = username<br />
remotepass = password<br />
</nowiki><br />
}}<br />
<br />
==Usage==<br />
Before running offlineimap, create any parent directories that were allocated to local repositories:<br />
$ mkdir ~/.mail<br />
<br />
Now, run the program:<br />
$ offlineimap<br />
<br />
Mail accounts will now be synced. If anything goes wrong, take a closer look at the error messages. OfflineIMAP is usually very verbose about problems; partly because the developers didn't bother with taking away tracebacks from the final product.<br />
<br />
==Miscellaneous==<br />
''Various settings and improvements''<br />
<br />
===Running offlineimap in the background===<br />
Most other mail transfer agents assume that the user will be using the tool as a [[daemon]] by making the program sync periodically by default. In offlineimap, there are a few settings that control backgrounded tasks.<br />
<br />
Confusingly, they are spread thin all-over the configuration file:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
# In the general section<br />
[general]<br />
# Controls how many accounts may be synced simultaneously<br />
maxsyncaccounts = 1<br />
<br />
# In the account identifier<br />
[Account main]<br />
# Minutes between syncs<br />
autorefresh = 5<br />
# Number of quick-syncs between autorefreshes. Quick-syncs do not update if the<br />
# only changes were to IMAP flags<br />
quick = 10<br />
<br />
# In the remote repository identifier<br />
[Repository main-remote]<br />
# Instead of closing the connection once a sync is complete, offlineimap will<br />
# send empty data to the server to hold the connection open. A value of 60<br />
# attempts to hold the connection for a minute between syncs (both quick and<br />
# autorefresh)<br />
keepalive = 60<br />
</nowiki><br />
}}<br />
<br />
====cron job====<br />
1. Configure background jobs as shown in [[#Running offlineimap in the background]].<br />
<br />
2. Use a log-friendly user interface:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This will suppress anything but errors<br />
ui = Noninteractive.Quiet<br />
</nowiki><br />
}}<br />
<br />
3. Write a wrapper script for [[daemon]]izing programs, or use the one shown below:<br />
{{file|name=~/bin/start_daemon|content=<br />
<nowiki><br />
#!/bin/sh<br />
set -e -f -u<br />
<br />
while getopts n:c:p: f; do<br />
case $f in<br />
n) NICE=$OPTARG;;<br />
c) IONICE_CLASS=$OPTARG;;<br />
p) IONICE_PRIORITY=$OPTARG;;<br />
*) exit 2;;<br />
esac<br />
done<br />
shift $((OPTIND - 1))<br />
cmd=$*<br />
<br />
if ! pgrep -u "$UID" -xf -- "$cmd" >/dev/null 2>&1; then<br />
nice_args=<br />
ionice_args=<br />
<br />
var2arg() {<br />
if [ -n "$3" ]; then<br />
eval "$1=$2\ $3\ \$$1"<br />
fi<br />
}<br />
<br />
arg2cmd() {<br />
if [ -n "$2" ] && type "$1" >/dev/null 2>&1; then<br />
cmd="$* -- $cmd"<br />
fi<br />
}<br />
<br />
var2arg nice_args -n "$NICE"<br />
var2arg ionice_args -c "$IONICE_CLASS"<br />
var2arg ionice_args -n "$IONICE_PRIORITY"<br />
<br />
arg2cmd nice "$nice_args"<br />
arg2cmd ionice "$ionice_args"<br />
<br />
exec $cmd<br />
fi<br />
</nowiki><br />
}}<br />
<br />
4. Finally, add a crontab entry:<br />
$ crontab -e<br />
The line should specify the interpreter for correct {{codeline|pgrep -xf}} results:<br />
*/5 * * * * exec ~/bin/start_daemon -n19 -c2 -p7 python /usr/bin/offlineimap <br />
<br />
The wrapper script is needed because offlineimap has the tendency to sporadically crash, even more so when facing connection problems.<br />
<br />
===Automatic mutt mailbox generation===<br />
[[Mutt]] cannot be simply pointed to an IMAP or maildir directory and be expected to guess which subdirectories happen to be the mailboxes, yet offlineimap can generate a muttrc fragment containing the mailboxes that it syncs.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[mbnames]<br />
enabled = yes<br />
filename = ~/.mutt/mailboxes<br />
header = "mailboxes "<br />
peritem = "+%(accountname)s/%(foldername)s"<br />
sep = " "<br />
footer = "\n"<br />
</nowiki><br />
}}<br />
<br />
Then add {{codeline|source ~/.mutt/mailboxes}} to {{filename|~/.mutt/muttrc}}.<br />
<br />
===Gmail configuration===<br />
This remote repository is configured specifically for Gmail support, substituting folder names in uppercase for lowercase, among other small additions. Keep in mind that this configuration does not sync the ''All Mail'' folder, since it is usually unnecessary and skipping it prevents bandwidth costs:<br />
<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[Repository gmail-remote]<br />
type = Gmail<br />
remoteuser = user@gmail.com<br />
remotepass = password<br />
nametrans = lambda foldername: re.sub ('^\[gmail\]', 'bak',<br />
re.sub ('sent_mail', 'sent',<br />
re.sub ('starred', 'flagged',<br />
re.sub (' ', '_', foldername.lower()))))<br />
folderfilter = lambda foldername: foldername not in '[Gmail]/All Mail'<br />
</nowiki><br />
}}<br />
<br />
==Troubleshooting==<br />
<br />
===Overriding UI and autorefresh settings===<br />
For the sake of troubleshooting, it is sometimes convenient to launch offlineimap with a more verbose UI, no background syncs and perhaps even a debug level:<br />
$ offlineimap [ -o ] [ -d <debug_type> ] [ -u <ui> ]<br />
;-o<br />
:Disable autorefresh, keepalive, etc.<br />
<br />
;-d <debug_type><br />
:Where ''<debug_type>'' is one of {{codeline|imap}}, {{codeline|maildir}} or {{codeline|thread}}. Debugging imap and maildir are, by far, the most useful.<br />
<br />
;-u <ui><br />
:Where ''<ui>'' is one of {{codeline|CURSES.BLINKENLIGHTS}}, {{codeline|TTY.TTYUI}}, {{codeline|NONINTERACTIVE.BASIC}}, {{codeline|NONINTERACTIVE.QUIET}} or {{codeline|MACHINE.MACHINEUI}}. TTY.TTYUI is sufficient for debugging purposes.<br />
<br />
===Curses interface (Curses.Blinkenlights) locks terminal===<br />
Because of a bug in Python's ncurses package (http://bugs.python.org/issue7567) the Curses interface of OfflineIMAP breaks the terminal on exit.<br />
While it appears to irreparably lock the terminal, in reality it only prevents commands from being displayed.<br />
The bug has been fixed in Python's SVN for all versions 2.6 up to 3.2 but the current package in the repositories (Python 2.6.5) is still buggy.<br />
<br />
In order to solve the issue:<br />
*either append {{codeline|reset}} to OfflineIMAP's launch command:<br />
$ offlineimap; reset<br />
*or change the {{codeline|ui}} field in {{filename|~/.offlineimaprc}} to select a fully functional one:<br />
ui = TTY.TTYUI<br />
*or as quick workaround you can just use the following command to skip the reset() function in Curses.py which causes the problem<br />
sudo sed -i '125i\ \ \ \ \ \ \ \ return' /usr/lib/python2.6/site-packages/offlineimap/ui/Curses.py<br />
<br />
<br />
===netrc authentication===<br />
There are some bugs in the current {{Package Official|offlineimap}} which makes it impossible to read the authentication data from {{Filename|~/.netrc}}. But they are fixed in the GIT package {{Package AUR|offlineimap-git}}.<br />
Using the package you can collect all passwords in {{Filename|~/.netrc}}. And don't forget to set it's access rights:<br />
chmod 600 ~/.netrc<br />
An example netrc file would be<br />
{{file|name=~/.netrc|content=<br />
machine mail.myhost.de<br />
login mr_smith<br />
password secret<br />
}}<br />
<br />
===socket.ssl deprecation warnings===<br />
Depending on the currently installed python version, running offlineimap throws this warning:<br />
DeprecationWarning: socket.ssl() is deprecated. Use ssl.wrap_socket() instead.<br />
<br />
This can be particularly annoying when offlineimap's output is being logged or mailed through [[cron]].<br />
<br />
To fix the problem, apply this [http://github.com/jgoerzen/offlineimap/commit/a7810166335bb0e6f5c7dab26adf707c38adf6ff upstream] patch or install {{Package AUR|offlineimap-git}}:<br />
<pre><br />
--- offlineimap/imaplibutil.py.orig 2009-08-12 01:24:23.000000000 -0430<br />
+++ offlineimap/imaplibutil.py 2010-06-07 11:17:37.849038683 -0430<br />
@@ -23,9 +23,11 @@<br />
# Import the symbols we need that aren't exported by default<br />
from imaplib import IMAP4_PORT, IMAP4_SSL_PORT, InternalDate, Mon2num<br />
<br />
-# ssl is new in python 2.6<br />
-if (sys.version_info[0] == 2 and sys.version_info[1] >= 6) or sys.version_info[0] >= 3:<br />
+try:<br />
import ssl<br />
+ ssl_wrap = ssl.wrap_socket<br />
+except ImportError:<br />
+ ssl_wrap = socket.ssl<br />
<br />
class IMAP4_Tunnel(IMAP4):<br />
"""IMAP4 client class over a tunnel<br />
@@ -169,7 +171,7 @@<br />
if last_error != 0:<br />
# FIXME<br />
raise socket.error(last_error)<br />
- self.sslobj = socket.ssl(self.sock, self.keyfile, self.certfile)<br />
+ self.sslobj = ssl_wrap(self.sock, self.keyfile, self.certfile)<br />
self.sslobj = sslwrapper(self.sslobj)<br />
<br />
mustquote = re.compile(r"[^\w!#$%&'+,.:;<=>?^`|~-]")<br />
</pre><br />
<br />
The diff is relative to the root buildir and it can be applied by using [[ABS]].</div>Buergihttps://wiki.archlinux.org/index.php?title=OfflineIMAP&diff=114503OfflineIMAP2010-08-20T20:59:14Z<p>Buergi: /* netrc authentication */ removed netrc patch, it's now in the official git tree</p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://software.complete.org/software/projects/show/offlineimap OfflineIMAP] is an utility to sync mail from IMAP servers. It does not work with the POP3 protocol or mbox, and is usually paired with a MUA such as [[Mutt]].<br />
<br />
As of 06/26/2010, offlineimap is [http://article.gmane.org/gmane.mail.imap.offlineimap.general/1759 unmaintained].<br />
<br />
==Installing==<br />
Install the {{package Official|offlineimap}} package with [[pacman]]:<br />
# pacman -S offlineimap<br />
<br />
==Configuring==<br />
The example configuration that is distributed with offlineimap contains every setting and is thorougly documented.<br />
<br />
Copy it to {{filename|~/.offlinimaprc}} and edit it:<br />
$ cp /usr/share/offlineimap/offlineimap.conf ~/.offlineimaprc<br />
$ vi ~/.offlineimaprc<br />
<br />
Take care that comments are placed on their own separate line, since writing a comment after an option/value on the same line is invalid syntax.<br />
<br />
===Quick-start===<br />
Following is a commented version of {{filename|/usr/share/offlineimap.conf.minimal}}. The setup only contains settings that are absolutely necessary.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This should contain a space delimited list of all identifiers of the accounts<br />
# that are to be synced<br />
accounts = main<br />
# If there are two accounts; `main' and `alternative'...<br />
#accounts = main alternative<br />
<br />
[Account main]<br />
# The identifier for the local repository; i.e., the maildir that offlineimap<br />
# will sync with an IMAP server<br />
localrepository = main-local<br />
# The identifier for the remote repository. This is the actual IMAP, which is<br />
# usually foreign to the system<br />
remoterepository = main-remote<br />
<br />
[Repository main-local]<br />
# Currently, offlineimap only supports maildir and IMAP for local repositories<br />
type = Maildir<br />
# Where should the mail be placed?<br />
localfolders = ~/.mail/main<br />
<br />
[Repository mail-remote]<br />
# Remote repos can be IMAP or Gmail, the latter being a preconfigured IMAP<br />
type = IMAP<br />
remoteuser = username<br />
remotepass = password<br />
</nowiki><br />
}}<br />
<br />
==Usage==<br />
Before running offlineimap, create any parent directories that were allocated to local repositories:<br />
$ mkdir ~/.mail<br />
<br />
Now, run the program:<br />
$ offlineimap<br />
<br />
Mail accounts will now be synced. If anything goes wrong, take a closer look at the error messages. OfflineIMAP is usually very verbose about problems; partly because the developers didn't bother with taking away tracebacks from the final product.<br />
<br />
==Miscellaneous==<br />
''Various settings and improvements''<br />
<br />
===Running offlineimap in the background===<br />
Most other mail transfer agents assume that the user will be using the tool as a [[daemon]] by making the program sync periodically by default. In offlineimap, there are a few settings that control backgrounded tasks.<br />
<br />
Confusingly, they are spread thin all-over the configuration file:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
# In the general section<br />
[general]<br />
# Controls how many accounts may be synced simultaneously<br />
maxsyncaccounts = 1<br />
<br />
# In the account identifier<br />
[Account main]<br />
# Minutes between syncs<br />
autorefresh = 5<br />
# Number of quick-syncs between autorefreshes. Quick-syncs do not update if the<br />
# only changes were to IMAP flags<br />
quick = 10<br />
<br />
# In the remote repository identifier<br />
[Repository main-remote]<br />
# Instead of closing the connection once a sync is complete, offlineimap will<br />
# send empty data to the server to hold the connection open. A value of 60<br />
# attempts to hold the connection for a minute between syncs (both quick and<br />
# autorefresh)<br />
keepalive = 60<br />
</nowiki><br />
}}<br />
<br />
====cron job====<br />
1. Configure background jobs as shown in [[#Running offlineimap in the background]].<br />
<br />
2. Use a log-friendly user interface:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This will suppress anything but errors<br />
ui = Noninteractive.Quiet<br />
</nowiki><br />
}}<br />
<br />
3. Write a wrapper script for [[daemon]]izing programs, or use the one shown below:<br />
{{file|name=~/bin/start_daemon|content=<br />
<nowiki><br />
#!/bin/sh<br />
set -e -f -u<br />
<br />
while getopts n:c:p: f; do<br />
case $f in<br />
n) NICE=$OPTARG;;<br />
c) IONICE_CLASS=$OPTARG;;<br />
p) IONICE_PRIORITY=$OPTARG;;<br />
*) exit 2;;<br />
esac<br />
done<br />
shift $((OPTIND - 1))<br />
cmd=$*<br />
<br />
if ! pgrep -u "$UID" -xf -- "$cmd" >/dev/null 2>&1; then<br />
nice_args=<br />
ionice_args=<br />
<br />
var2arg() {<br />
if [ -n "$3" ]; then<br />
eval "$1=$2\ $3\ \$$1"<br />
fi<br />
}<br />
<br />
arg2cmd() {<br />
if [ -n "$2" ] && type "$1" >/dev/null 2>&1; then<br />
cmd="$* -- $cmd"<br />
fi<br />
}<br />
<br />
var2arg nice_args -n "$NICE"<br />
var2arg ionice_args -c "$IONICE_CLASS"<br />
var2arg ionice_args -n "$IONICE_PRIORITY"<br />
<br />
arg2cmd nice "$nice_args"<br />
arg2cmd ionice "$ionice_args"<br />
<br />
exec $cmd<br />
fi<br />
</nowiki><br />
}}<br />
<br />
4. Finally, add a crontab entry:<br />
$ crontab -e<br />
The line should specify the interpreter for correct {{codeline|pgrep -xf}} results:<br />
*/5 * * * * exec ~/bin/start_daemon -n19 -c2 -p7 python /usr/bin/offlineimap <br />
<br />
The wrapper script is needed because offlineimap has the tendency to sporadically crash, even more so when facing connection problems.<br />
<br />
===Automatic mutt mailbox generation===<br />
[[Mutt]] cannot be simply pointed to an IMAP or maildir directory and be expected to guess which subdirectories happen to be the mailboxes, yet offlineimap can generate a muttrc fragment containing the mailboxes that it syncs.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[mbnames]<br />
enabled = yes<br />
filename = ~/.mutt/mailboxes<br />
header = "mailboxes "<br />
peritem = "+%(accountname)s/%(foldername)s"<br />
sep = " "<br />
footer = "\n"<br />
</nowiki><br />
}}<br />
<br />
Then add {{codeline|source ~/.mutt/mailboxes}} to {{filename|~/.mutt/muttrc}}.<br />
<br />
===Gmail configuration===<br />
This remote repository is configured specifically for Gmail support, substituting folder names in uppercase for lowercase, among other small additions. Keep in mind that this configuration does not sync the ''All Mail'' folder, since it is usually unnecessary and skipping it prevents bandwidth costs:<br />
<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[Repository gmail-remote]<br />
type = Gmail<br />
remoteuser = user@gmail.com<br />
remotepass = password<br />
nametrans = lambda foldername: re.sub ('^\[gmail\]', 'bak',<br />
re.sub ('sent_mail', 'sent',<br />
re.sub ('starred', 'flagged',<br />
re.sub (' ', '_', foldername.lower()))))<br />
folderfilter = lambda foldername: foldername not in '[Gmail]/All Mail'<br />
</nowiki><br />
}}<br />
<br />
==Troubleshooting==<br />
<br />
===Overriding UI and autorefresh settings===<br />
For the sake of troubleshooting, it is sometimes convenient to launch offlineimap with a more verbose UI, no background syncs and perhaps even a debug level:<br />
$ offlineimap [ -o ] [ -d <debug_type> ] [ -u <ui> ]<br />
;-o<br />
:Disable autorefresh, keepalive, etc.<br />
<br />
;-d <debug_type><br />
:Where ''<debug_type>'' is one of {{codeline|imap}}, {{codeline|maildir}} or {{codeline|thread}}. Debugging imap and maildir are, by far, the most useful.<br />
<br />
;-u <ui><br />
:Where ''<ui>'' is one of {{codeline|CURSES.BLINKENLIGHTS}}, {{codeline|TTY.TTYUI}}, {{codeline|NONINTERACTIVE.BASIC}}, {{codeline|NONINTERACTIVE.QUIET}} or {{codeline|MACHINE.MACHINEUI}}. TTY.TTYUI is sufficient for debugging purposes.<br />
<br />
===Curses interface (Curses.Blinkenlights) locks terminal===<br />
Because of a bug in Python's ncurses package (http://bugs.python.org/issue7567) the Curses interface of OfflineIMAP breaks the terminal on exit.<br />
While it appears to irreparably lock the terminal, in reality it only prevents commands from being displayed.<br />
The bug has been fixed in Python's SVN for all versions 2.6 up to 3.2 but the current package in the repositories (Python 2.6.5) is still buggy.<br />
<br />
In order to solve the issue:<br />
*either append {{codeline|reset}} to OfflineIMAP's launch command:<br />
$ offlineimap; reset<br />
*or change the {{codeline|ui}} field in {{filename|~/.offlineimaprc}} to select a fully functional one:<br />
ui = TTY.TTYUI<br />
*or as quick workaround you can just use the following command to skip the reset() function in Curses.py which causes the problem<br />
sudo sed -i '125i\ \ \ \ \ \ \ \ return' /usr/lib/python2.6/site-packages/offlineimap/ui/Curses.py<br />
<br />
<br />
===netrc authentication===<br />
There are some bugs in the current {{Package|offlineimap}} which makes it impossible to read the authentication data from {{Filename|~/.netrc}}. But they are fixed in the GIT package {{Package AUR|offlineimap-git}}.<br />
Using the package you can collect all passwords in {{Filename|~/.netrc}}. And don't forget to set it's access rights:<br />
chmod 600 ~/.netrc<br />
An example netrc file would be<br />
{{file|name=~/.netrc|content=<br />
machine mail.myhost.de<br />
login mr_smith<br />
password secret<br />
}}<br />
<br />
===socket.ssl deprecation warnings===<br />
Depending on the currently installed python version, running offlineimap throws this warning:<br />
DeprecationWarning: socket.ssl() is deprecated. Use ssl.wrap_socket() instead.<br />
<br />
This can be particularly annoying when offlineimap's output is being logged or mailed through [[cron]].<br />
<br />
To fix the problem, apply this [http://github.com/jgoerzen/offlineimap/commit/a7810166335bb0e6f5c7dab26adf707c38adf6ff upstream] patch or install {{Package AUR|offlineimap-git}}:<br />
<pre><br />
--- offlineimap/imaplibutil.py.orig 2009-08-12 01:24:23.000000000 -0430<br />
+++ offlineimap/imaplibutil.py 2010-06-07 11:17:37.849038683 -0430<br />
@@ -23,9 +23,11 @@<br />
# Import the symbols we need that aren't exported by default<br />
from imaplib import IMAP4_PORT, IMAP4_SSL_PORT, InternalDate, Mon2num<br />
<br />
-# ssl is new in python 2.6<br />
-if (sys.version_info[0] == 2 and sys.version_info[1] >= 6) or sys.version_info[0] >= 3:<br />
+try:<br />
import ssl<br />
+ ssl_wrap = ssl.wrap_socket<br />
+except ImportError:<br />
+ ssl_wrap = socket.ssl<br />
<br />
class IMAP4_Tunnel(IMAP4):<br />
"""IMAP4 client class over a tunnel<br />
@@ -169,7 +171,7 @@<br />
if last_error != 0:<br />
# FIXME<br />
raise socket.error(last_error)<br />
- self.sslobj = socket.ssl(self.sock, self.keyfile, self.certfile)<br />
+ self.sslobj = ssl_wrap(self.sock, self.keyfile, self.certfile)<br />
self.sslobj = sslwrapper(self.sslobj)<br />
<br />
mustquote = re.compile(r"[^\w!#$%&'+,.:;<=>?^`|~-]")<br />
</pre><br />
<br />
The diff is relative to the root buildir and it can be applied by using [[ABS]].</div>Buergihttps://wiki.archlinux.org/index.php?title=OfflineIMAP&diff=114428OfflineIMAP2010-08-19T21:45:41Z<p>Buergi: added fix for curses interface problem and patch for netrc authentication</p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://software.complete.org/software/projects/show/offlineimap OfflineIMAP] is an utility to sync mail from IMAP servers. It does not work with the POP3 protocol or mbox, and is usually paired with a MUA such as [[Mutt]].<br />
<br />
As of 06/26/2010, offlineimap is [http://article.gmane.org/gmane.mail.imap.offlineimap.general/1759 unmaintained].<br />
<br />
==Installing==<br />
Install the {{package Official|offlineimap}} package with [[pacman]]:<br />
# pacman -S offlineimap<br />
<br />
==Configuring==<br />
The example configuration that is distributed with offlineimap contains every setting and is thorougly documented.<br />
<br />
Copy it to {{filename|~/.offlinimaprc}} and edit it:<br />
$ cp /usr/share/offlineimap/offlineimap.conf ~/.offlineimaprc<br />
$ vi ~/.offlineimaprc<br />
<br />
Take care that comments are placed on their own separate line, since writing a comment after an option/value on the same line is invalid syntax.<br />
<br />
===Quick-start===<br />
Following is a commented version of {{filename|/usr/share/offlineimap.conf.minimal}}. The setup only contains settings that are absolutely necessary.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This should contain a space delimited list of all identifiers of the accounts<br />
# that are to be synced<br />
accounts = main<br />
# If there are two accounts; `main' and `alternative'...<br />
#accounts = main alternative<br />
<br />
[Account main]<br />
# The identifier for the local repository; i.e., the maildir that offlineimap<br />
# will sync with an IMAP server<br />
localrepository = main-local<br />
# The identifier for the remote repository. This is the actual IMAP, which is<br />
# usually foreign to the system<br />
remoterepository = main-remote<br />
<br />
[Repository main-local]<br />
# Currently, offlineimap only supports maildir and IMAP for local repositories<br />
type = Maildir<br />
# Where should the mail be placed?<br />
localfolders = ~/.mail/main<br />
<br />
[Repository mail-remote]<br />
# Remote repos can be IMAP or Gmail, the latter being a preconfigured IMAP<br />
type = IMAP<br />
remoteuser = username<br />
remotepass = password<br />
</nowiki><br />
}}<br />
<br />
==Usage==<br />
Before running offlineimap, create any parent directories that were allocated to local repositories:<br />
$ mkdir ~/.mail<br />
<br />
Now, run the program:<br />
$ offlineimap<br />
<br />
Mail accounts will now be synced. If anything goes wrong, take a closer look at the error messages. OfflineIMAP is usually very verbose about problems; partly because the developers didn't bother with taking away tracebacks from the final product.<br />
<br />
==Miscellaneous==<br />
''Various settings and improvements''<br />
<br />
===Running offlineimap in the background===<br />
Most other mail transfer agents assume that the user will be using the tool as a [[daemon]] by making the program sync periodically by default. In offlineimap, there are a few settings that control backgrounded tasks.<br />
<br />
Confusingly, they are spread thin all-over the configuration file:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
# In the general section<br />
[general]<br />
# Controls how many accounts may be synced simultaneously<br />
maxsyncaccounts = 1<br />
<br />
# In the account identifier<br />
[Account main]<br />
# Minutes between syncs<br />
autorefresh = 5<br />
# Number of quick-syncs between autorefreshes. Quick-syncs do not update if the<br />
# only changes were to IMAP flags<br />
quick = 10<br />
<br />
# In the remote repository identifier<br />
[Repository main-remote]<br />
# Instead of closing the connection once a sync is complete, offlineimap will<br />
# send empty data to the server to hold the connection open. A value of 60<br />
# attempts to hold the connection for a minute between syncs (both quick and<br />
# autorefresh)<br />
keepalive = 60<br />
</nowiki><br />
}}<br />
<br />
====cron job====<br />
1. Configure background jobs as shown in [[#Running offlineimap in the background]].<br />
<br />
2. Use a log-friendly user interface:<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[general]<br />
# This will suppress anything but errors<br />
ui = Noninteractive.Quiet<br />
</nowiki><br />
}}<br />
<br />
3. Write a wrapper script for [[daemon]]izing programs, or use the one shown below:<br />
{{file|name=~/bin/start_daemon|content=<br />
<nowiki><br />
#!/bin/sh<br />
set -e -f -u<br />
<br />
while getopts n:c:p: f; do<br />
case $f in<br />
n) NICE=$OPTARG;;<br />
c) IONICE_CLASS=$OPTARG;;<br />
p) IONICE_PRIORITY=$OPTARG;;<br />
*) exit 2;;<br />
esac<br />
done<br />
shift $((OPTIND - 1))<br />
cmd=$*<br />
<br />
if ! pgrep -u "$UID" -xf -- "$cmd" >/dev/null 2>&1; then<br />
nice_args=<br />
ionice_args=<br />
<br />
var2arg() {<br />
if [ -n "$3" ]; then<br />
eval "$1=$2\ $3\ \$$1"<br />
fi<br />
}<br />
<br />
arg2cmd() {<br />
if [ -n "$2" ] && type "$1" >/dev/null 2>&1; then<br />
cmd="$* -- $cmd"<br />
fi<br />
}<br />
<br />
var2arg nice_args -n "$NICE"<br />
var2arg ionice_args -c "$IONICE_CLASS"<br />
var2arg ionice_args -n "$IONICE_PRIORITY"<br />
<br />
arg2cmd nice "$nice_args"<br />
arg2cmd ionice "$ionice_args"<br />
<br />
exec $cmd<br />
fi<br />
</nowiki><br />
}}<br />
<br />
4. Finally, add a crontab entry:<br />
$ crontab -e<br />
The line should specify the interpreter for correct {{codeline|pgrep -xf}} results:<br />
*/5 * * * * exec ~/bin/start_daemon -n19 -c2 -p7 python /usr/bin/offlineimap <br />
<br />
The wrapper script is needed because offlineimap has the tendency to sporadically crash, even more so when facing connection problems.<br />
<br />
===Automatic mutt mailbox generation===<br />
[[Mutt]] cannot be simply pointed to an IMAP or maildir directory and be expected to guess which subdirectories happen to be the mailboxes, yet offlineimap can generate a muttrc fragment containing the mailboxes that it syncs.<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[mbnames]<br />
enabled = yes<br />
filename = ~/.mutt/mailboxes<br />
header = "mailboxes "<br />
peritem = "+%(accountname)s/%(foldername)s"<br />
sep = " "<br />
footer = "\n"<br />
</nowiki><br />
}}<br />
<br />
Then add {{codeline|source ~/.mutt/mailboxes}} to {{filename|~/.mutt/muttrc}}.<br />
<br />
===Gmail configuration===<br />
This remote repository is configured specifically for Gmail support, substituting folder names in uppercase for lowercase, among other small additions. Keep in mind that this configuration does not sync the ''All Mail'' folder, since it is usually unnecessary and skipping it prevents bandwidth costs:<br />
<br />
{{file|name=~/.offlineimaprc|content=<br />
<nowiki><br />
[Repository gmail-remote]<br />
type = Gmail<br />
remoteuser = user@gmail.com<br />
remotepass = password<br />
nametrans = lambda foldername: re.sub ('^\[gmail\]', 'bak',<br />
re.sub ('sent_mail', 'sent',<br />
re.sub ('starred', 'flagged',<br />
re.sub (' ', '_', foldername.lower()))))<br />
folderfilter = lambda foldername: foldername not in '[Gmail]/All Mail'<br />
</nowiki><br />
}}<br />
<br />
==Troubleshooting==<br />
<br />
===Overriding UI and autorefresh settings===<br />
For the sake of troubleshooting, it is sometimes convenient to launch offlineimap with a more verbose UI, no background syncs and perhaps even a debug level:<br />
$ offlineimap [ -o ] [ -d <debug_type> ] [ -u <ui> ]<br />
;-o<br />
:Disable autorefresh, keepalive, etc.<br />
<br />
;-d <debug_type><br />
:Where ''<debug_type>'' is one of {{codeline|imap}}, {{codeline|maildir}} or {{codeline|thread}}. Debugging imap and maildir are, by far, the most useful.<br />
<br />
;-u <ui><br />
:Where ''<ui>'' is one of {{codeline|CURSES.BLINKENLIGHTS}}, {{codeline|TTY.TTYUI}}, {{codeline|NONINTERACTIVE.BASIC}}, {{codeline|NONINTERACTIVE.QUIET}} or {{codeline|MACHINE.MACHINEUI}}. TTY.TTYUI is sufficient for debugging purposes.<br />
<br />
===Curses interface (Curses.Blinkenlights) locks terminal===<br />
Because of a bug in Python's ncurses package (http://bugs.python.org/issue7567) the Curses interface of OfflineIMAP breaks the terminal on exit.<br />
While it appears to irreparably lock the terminal, in reality it only prevents commands from being displayed.<br />
The bug has been fixed in Python's SVN for all versions 2.6 up to 3.2 but the current package in the repositories (Python 2.6.5) is still buggy.<br />
<br />
In order to solve the issue:<br />
*either append {{codeline|reset}} to OfflineIMAP's launch command:<br />
$ offlineimap; reset<br />
*or change the {{codeline|ui}} field in {{filename|~/.offlineimaprc}} to select a fully functional one:<br />
ui = TTY.TTYUI<br />
*or as quick workaround you can just use the following command to skip the reset() function in Curses.py which causes the problem<br />
sudo sed -i '125i\ \ \ \ \ \ \ \ return' /usr/lib/python2.6/site-packages/offlineimap/ui/Curses.py<br />
<br />
<br />
===netrc authentication===<br />
There are some bugs in the current {{Package AUR|offlineimap-git}} which makes it impossible to read the authentication data from {{Filename|~/.netrc}}. Apply the following patch to fix them.<br />
<br />
cd /usr/lib/python2.6/site-packages/<br />
patch -p1 < ~/offlineimap.patch<br />
{{file|name=~/offlineimap.patch|content=<br />
<nowiki><br />
--- a/offlineimap/imapserver.py 2010-08-19 19:31:14.472067682 +0200<br />
+++ b/offlineimap/imapserver.py 2010-08-19 14:53:19.530402432 +0200<br />
@@ -176,7 +176,7 @@<br />
challenge = response.strip()<br />
ui.debug('imap', 'md5handler: got challenge %s' % challenge)<br />
<br />
- passwd = self.getpassword()<br />
+ passwd = self.repos.getpassword()<br />
retval = self.username + ' ' + hmac.new(passwd, challenge).hexdigest()<br />
ui.debug('imap', 'md5handler: returning %s' % retval)<br />
return retval<br />
@@ -184,7 +184,7 @@<br />
def plainauth(self, imapobj):<br />
UIBase.getglobalui().debug('imap',<br />
'Attempting plain authentication')<br />
- imapobj.login(self.username, self.getpassword())<br />
+ imapobj.login(self.username, self.repos.getpassword())<br />
<br />
def gssauth(self, response):<br />
data = base64.b64encode(response)<br />
--- a/offlineimap/repository/IMAP.py 2010-08-19 19:29:49.702076618 +0200<br />
+++ b/offlineimap/repository/IMAP.py 2010-08-19 16:20:43.943211542 +0200<br />
@@ -109,7 +109,7 @@<br />
return user<br />
<br />
try:<br />
- netrcentry = netrc.netrc().authentificator(self.gethost())<br />
+ netrcentry = netrc.netrc().authenticators(self.gethost())<br />
except IOError, inst:<br />
if inst.errno != errno.ENOENT:<br />
raise<br />
@@ -118,7 +118,7 @@<br />
return netrcentry[0]<br />
<br />
try:<br />
- netrcentry = netrc.netrc('/etc/netrc').authentificator(self.gethost())<br />
+ netrcentry = netrc.netrc('/etc/netrc').authenticators(self.gethost())<br />
except IOError, inst:<br />
if inst.errno != errno.ENOENT:<br />
raise<br />
</nowiki>}}<br />
<br />
Now you can collect all passwords in {{Filename|~/.netrc}}. And don't forget to set it's access rights:<br />
chmod 600 ~/.netrc<br />
An example netrc file would be<br />
{{file|name=~/.netrc|content=<br />
machine mail.myhost.de<br />
login mr_smith<br />
password secret<br />
}}<br />
<br />
===socket.ssl deprecation warnings===<br />
Depending on the currently installed python version, running offlineimap throws this warning:<br />
DeprecationWarning: socket.ssl() is deprecated. Use ssl.wrap_socket() instead.<br />
<br />
This can be particularly annoying when offlineimap's output is being logged or mailed through [[cron]].<br />
<br />
To fix the problem, apply this [http://github.com/jgoerzen/offlineimap/commit/a7810166335bb0e6f5c7dab26adf707c38adf6ff upstream] patch or install {{Package AUR|offlineimap-git}}:<br />
<pre><br />
--- offlineimap/imaplibutil.py.orig 2009-08-12 01:24:23.000000000 -0430<br />
+++ offlineimap/imaplibutil.py 2010-06-07 11:17:37.849038683 -0430<br />
@@ -23,9 +23,11 @@<br />
# Import the symbols we need that aren't exported by default<br />
from imaplib import IMAP4_PORT, IMAP4_SSL_PORT, InternalDate, Mon2num<br />
<br />
-# ssl is new in python 2.6<br />
-if (sys.version_info[0] == 2 and sys.version_info[1] >= 6) or sys.version_info[0] >= 3:<br />
+try:<br />
import ssl<br />
+ ssl_wrap = ssl.wrap_socket<br />
+except ImportError:<br />
+ ssl_wrap = socket.ssl<br />
<br />
class IMAP4_Tunnel(IMAP4):<br />
"""IMAP4 client class over a tunnel<br />
@@ -169,7 +171,7 @@<br />
if last_error != 0:<br />
# FIXME<br />
raise socket.error(last_error)<br />
- self.sslobj = socket.ssl(self.sock, self.keyfile, self.certfile)<br />
+ self.sslobj = ssl_wrap(self.sock, self.keyfile, self.certfile)<br />
self.sslobj = sslwrapper(self.sslobj)<br />
<br />
mustquote = re.compile(r"[^\w!#$%&'+,.:;<=>?^`|~-]")<br />
</pre><br />
<br />
The diff is relative to the root buildir and it can be applied by using [[ABS]].</div>Buergihttps://wiki.archlinux.org/index.php?title=Screen_capture&diff=99966Screen capture2010-03-13T08:16:42Z<p>Buergi: /* import */ added info about xwininfo</p>
<hr />
<div>[[Category:Graphics and DTP (English)]]<br />
[[Category:Utilities (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Taking a Screenshot}}<br />
<br />
== import ==<br />
<br />
An easy way to take a screenshot of your curent system is using the import command:<br />
import -window root screenshot.jpg<br />
<br />
import is part of the imagemagick package.<br />
<br />
In case you only want to grab a single window you can use the xwininfo tool to find out it's id. Just run the following command and click into the window you want to take a screenshot of.<br />
import -window `xwininfo |grep 'Window id:' |cut -d" " -f4` screenshot.jpg<br />
<br />
If you run twinview or dualhead, simply take the screenshot twice and use imagemagick to paste them together:<br />
import -window root -display :0.0 -screen /tmp/0.png<br />
import -window root -display :0.1 -screen /tmp/1.png<br />
convert +append /tmp/0.png /tmp/1.png screenshot.png<br />
rm /tmp/{0,1}.png<br />
<br />
== gimp ==<br />
<br />
You also can take screenshots with gimp (File -> Acquire -> Screenshot ...).<br />
<br />
== xwd ==<br />
<br />
xwd is part of the xorg-apps package.<br />
<br />
Take a screenshot of the root window:<br />
xwd -root -out screenshot.xwd<br />
<br />
== scrot ==<br />
<br />
Scrot, available in the "extra" repository, provides for taking screenshots from the CLI, and offers features such as a user-definable time delay. Unless instructed otherwise, it saves the file in the directory bash was at when the command was launched.<br />
<br />
scrot -t 20 -d 5<br />
<br />
saves a dated .PNG file, along with a thumbnail (20% of original) for Web posting. It provides a five second delay before capturing, in this instance. <br />
<br />
== KDE ==<br />
<br />
If you use KDE, you might want to use ksnapshot, which can also be activated using <Prt Scr>.<br />
<br />
== GNOME ==<br />
<br />
You can press <Prt Scr> or Apps->Accessories->Take Screenshot.<br />
<br />
{{Note|If <Prt Scr> complains about not finding gnome-screenshot or there is no "Take Screenshot" entry in your menu, you will need to install the [http://www.archlinux.org/packages/3154 gnome-utils] package.}}<br />
<br />
== Virtual console ==<br />
<br />
Install a [[framebuffer]] and use {{Package Official|fbgrab}} to take a screen shot. Another option is to use {{Package Official|fbshot}}, but that tends to corrupt the image by inverting colors.</div>Buergihttps://wiki.archlinux.org/index.php?title=Touchscreen&diff=98712Touchscreen2010-03-02T21:58:39Z<p>Buergi: new article, currently mostly about evtouch drivers</p>
<hr />
<div>[[Category:Input devices (English)]][[Category:HOWTOs (English)]]<br />
If you ever tried to set up a touchscreen device in linux, you might have noticed that it's either working out of the box (besides some calibration) or is very tedious, especially when it isn't supported by the kernel.<br />
<br />
== Introduction ==<br />
This article assumes that your touchscreen device is supported by the kernel (e.g. by the usbtouchscreen module).<br />
That means there exists a /dev/input/event* node for your device. Check out<br />
less /proc/bus/input/devices<br />
to see if your device is listed or try<br />
cat /dev/input/event? # replace ? with the event numbers<br />
for every of your event nodes while touching the display.<br />
<br />
If you found the corresponding node, it's not very unlikely to get the device working.<br />
<br />
== Available X11 drivers ==<br />
There are a lot of touchscreen input drivers for X11 out there. The most common ones are in the ''extra'' repository:<br />
* {{Package AUR|xf86-input-evtouch}} (in AUR)<br />
* {{Package Official|xf86-input-elographics}}<br />
* {{Package Official|xf86-input-penmount}}<br />
* {{Package Official|xf86-input-mutouch}}<br />
<br />
Further not so common drivers, and thus not in the repos are<br />
* xf86-input-magictouch<br />
* xf86-input-plpevtch<br />
* xf86-input-palmax,<br />
* xf86-input-elo2300 (*)<br />
* xf86-input-microtouch (*)<br />
(Note: (*) are deprecated and thus were removed from the repos [http://www.archlinux.org/news/333/])<br />
<br />
Some for some devices proprietary drivers exists as well, as e.g. {{Package AUR|xf86-input-egalax}} but it's recommended to try the open source drivers first.<br />
<br />
Depending on your touchscreen device choose an appropriated driver.<br />
<br />
The evtouch input drivers support a wide variety of touchscreens from different vendors like Fujitsu, eGalax, IDEACO, ITM, Touchkit.<br />
{{Box YELLOW||Since I've only got one touchscreen device (USB 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen) which works with the evtouch driver I confine myself to this driver. Perhaps someone can add details about how to set up other drivers.}}<br />
<br />
== evtouch drivers ==<br />
<br />
At first get the drivers from AUR<br />
yaourt -S xf86-input-evtouch<br />
<br />
This package already includes a set of udev rules to create a permanent node for your input device in {{Filename|/etc/udev/rules.d/69-touchscreen.rules}}.<br />
Restart HAL and udev<br />
/etc/rc.d/hal restart; /etc/rc.d/udev restart<br />
If everything worked fine so far, you should have a symlink {{Filename|/dev/input/evtouch_event}} to your input device. If not, your touch device might not work with evtouch, but you can add a custom udev rule for your device and try it anyway.<br />
<br />
In case you configured X server to use HAL hot-plugging, the touchscreen should work now after restarting the X server.<br />
Else you have to add the corresponding "InputDevice" section to xorg.conf as described on [http://www.conan.de/touchscreen/evtouch.html evtouch's webside].<br />
<br />
<br />
=== Calibration ===<br />
It's assumed that you have the touchscreen working now in X11 and that you're using HAL hot-plugging for configuration. If you manually set up your input devices and thus switched off hot-plugging, you have to add the X11 options of this section to the xorg.conf file instead (see [http://www.conan.de/touchscreen/evtouch.html evtouch's webside] for details again).<br />
<br />
==== Rough calibration ====<br />
For touchscreen calibration the {{Package AUR|xf86-input-evtouch}} package includes a calibration program.<br />
sudo /usr/lib/xf86-input-evtouch/calibrate.sh<br />
No matter whether you started it from TTY or X11, this will start a new X server and bring up a white screen. Move the pen around the display border, along all edges a view times to get the minimum and maximum coordinates. Press {{Keypress|Return}}. Then tab exactly on the red cross. The next cross will turn red, touch it again and repeat this procedure for all crosses.<br />
When your done you should return to command line. The calibration data was written to {{Filename|/etc/evtouch/config}}.<br />
<br />
To restore the calibration data after booting add evtouch_config to the DAEMONS variable in {{Filename|/etc/rc.conf}}<br />
DAEMONS=( ... evtouch_config ... )<br />
This will read the calibration data from {{Filename|/etc/evtouch/config}} and set the corresponding X options using HAL.<br />
<br />
You can now (re)start your X server and enjoy your calibrated touchscreen.<br />
<br />
==== Fine calibration (optional) ====<br />
If your not satisfied with the calibration you can do further tweaking by changing the values in {{Filename|/etc/evtouch/config}} manually.<br />
MINX, MINY, MAXX, MAXY are the minimal and maximal coordinates and the nine X?,Y? pairs are the coordinates of the calibration points in the order you touched them.<br />
<br />
==== Correct orientation of the coordinate system ====<br />
The 9 point calibration assures that the coordinate axis are orientated in a way that your cursor moves to the right when your pen does (due to the signs of the X,Y pairs). In case you nevertheless notice your cursor is moving in the wrong direction you can add<br />
hal_set swapx 1<br />
hal_set swapy 1<br />
to /etc/rc.d/evtouch_config (of course this will get overwritten when you upgrade the package)<br />
<br />
When X and Y axis are swaped and your touchscreen uses the usbtouchscreen kernel module you can add the following line to {{Filename|/etc/modprobe.d/modprobe.conf}}<br />
options usbtouchscreen swap_xy=1<br />
<br />
==== Make the calibration persistent to unplugging or suspending ====<br />
You may notice that after unplugging the touch device and replugging it while the X server is running, your calibration is messed up. The same happens when you resume from hibernation or suspend.<br />
<br />
The reason is, that your calibration setting get set only once, at boot time by evtouch_config. When you unplug it the settings are removed when evtouch is unloaded.<br />
On plugging it in HAL sets the default settings as specified in {{Filename|/usr/share/hal/fdi/policy/20thirdparty/50-....fdi}} and loads the evtouch driver, which reads the calibration settings into its memory. Therefore it doesn't work to simply call evtouch_config while the X window system is running.<br />
<br />
The only way I found to make the calibration settings survive a replug-in or a hibernation is to set them directly in the HAL policy file.<br />
The following command converts the calibration settings to HAL policy format and prints the result on stdout.<br />
awk -F= '{print " <merge key=\"input.x11_options."tolower($1)"\" type=\"string\">"$2"</merge>"}' /etc/evtouch/config<br />
Replace the corresponding merge commands in the policy file ({{Filename|/usr/share/hal/fdi/policy/20thirdparty/50-....fdi}}) corresponding to your device.<br />
<br />
Of course you don't need the evtouch_config daemon any more when you use this method, so you can remove it from {{Filename|/etc/rc.conf}}.<br />
<br />
'''Note:''' when you have problems with right clicking or drag and drop you can try tweaking the settings ([http://www.conan.de/touchscreen/evtouch.html] [http://www.conan.de/touchscreen/libtouch.html]) in the fdi file. You can also set the swapx, swapy options here in case you need them.<br />
<br />
'''WARNING:''' The fdi files will be overwritten when you upgrade {{Package AUR|xf86-input-evtouch}}, so '''all your changes will be lost'''.</div>Buergihttps://wiki.archlinux.org/index.php?title=Improve_GTK_Application_Looks&diff=98676Improve GTK Application Looks2010-03-02T11:26:55Z<p>Buergi: /* GTK2 Apps */ removed note about unexisting gtk2-themes-collection package</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Improve GTK Application Looks}}<br />
<br />
= GTK1 Apps =<br />
If you sometimes use old GTK1 apps (like xmms), you probably know they don't look nice. This is because they use ugly default theme.<br />
To change it, you need to:<br />
# download and install some nice theme<br />
# change the theme<br />
<br />
Some nice themes are in [extra]. To install it:<br />
# pacman -S gtk-smooth-engine<br />
<br />
To change the theme you can use gtk-theme-switch:<br />
# pacman -S gtk-theme-switch<br />
<br />
then run it with 'switch' command. That's all. Isn't it better looking now? :)<br />
<br />
= GTK2 Apps =<br />
For GTK2 apps (e.g. Pidgin), methods to change theme include: <code>gtk-theme-switch2</code>, <code>gtk-chtheme</code> or <code>gtk2_prefs</code>. There is also <code>lxappearance</code>, a DE independent configuration tool from the LXDE project. It doesn't require any other parts of LXDE. So once you have made your mind do one of the following:<br />
<br />
# pacman -S gtk-theme-switch2<br />
<br />
# pacman -S gtk-chtheme<br />
<br />
# pacman -S gtk2_prefs<br />
<br />
# pacman -S lxappearance<br />
<br />
You probably would like to install some themes too. The popular ''Clearlooks'' theme is included within the <code>gtk-engines</code> package:<br />
# pacman -S gtk-engines<br />
<br />
Further themes can be found in AUR e.g. by<br />
# yaourt -Ss gtk-theme gtk2-theme<br />
<br />
Now run either <code>switch2</code> or <code>gtk-chtheme</code> or <code>gtk2_prefs</code>, depending on what you chose before and change the theme to your liking.<br />
<br />
If you want to change the icon theme of GTK2 Applications, then you have to modify or add in the file <code>~/.gtkrc-2.0</code> the following line (here the icon theme is set to Tango):<br />
<br />
gtk-icon-theme-name = "Tango"<br />
...more gtk2 settings...<br />
<br />
= GTK with QT =<br />
If you have GTK and QT(KDE) applications on you desktop then you know their looks don't blend well. If you wish to make your GTK styles match your QT styles please read [[Uniform Look for QT and GTK Applications]].</div>Buergihttps://wiki.archlinux.org/index.php?title=E17&diff=97708E172010-02-21T03:27:27Z<p>Buergi: /* Configuring Entrance */ removed note, wrong information</p>
<hr />
<div>[[Category:Desktop environments (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|E17}}<br />
<br />
E17 is the Development Release 17 (DR17) of the Enlightenment Desktop Environment.<br />
<br />
E17 is currently under heavy development, and is in the pre-alpha stages. Even though it is only young, E17 is still quite stable. Many people use it as a day-to-day Environment. <br />
<br />
New versions are available daily via SVN, but snapshots are also taken for easy installation. Below are instructions on how to install a SVN snapshot from the Arch community repositories.<br />
<br />
== Installing E17 from the community repository ==<br />
<br />
* First, edit your /etc/pacman.conf file and uncomment the community repositories by removing the hash at the start of that line; you should end up with something like the following:<br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
* Next, sync, update, and upgrade using the new community repository:<br />
pacman -Syu<br />
* Install e17 group:<br />
pacman -S e-svn<br />
* Install additional e17 modules and applications:<br />
pacman -S desktop-file-utils e17-extra-svn<br />
*Install additional fonts in order to avoid any trouble at the first start of e17<br />
pacman -S artwiz-fonts ttf-ms-fonts<br />
* If you need an e17 package which is not (yet) available in the [community] repo, see if it is available in the [http://aur.archlinux.org/ AUR].<br />
<br />
You are now ready. You can allow '''~/.xinitrc''' to start ''enlightenment'' for you:<br />
<br />
...<br />
# exec gnome-session<br />
# exec startkde<br />
# exec startxfce4<br />
# ...or the Window Manager of your choice<br />
exec enlightenment_start<br />
<br />
If you want the ''entrance'' login manager (to replace [[KDM]]/[[GDM]]), you can either do this via:<br />
<br />
* '''/etc/rc.conf''' - You only get the login manager on startup; it will not be there if you CTRL+ALT+BACKSPACE<br />
<br />
...<br />
DAEMONS=(... entranced)<br />
...<br />
<br />
OR<br />
<br />
* '''/etc/inittab''' - The recommended way<br />
<br />
...<br />
## Only one of the following two lines can be uncommented!<br />
# Boot to console <br />
#id:3:initdefault: <br />
# Boot to X11 <br />
id:5:initdefault:<br />
<br />
...<br />
<br />
# Example lines for starting a login manager<br />
#x:5:respawn:/usr/bin/xdm -nodaemon<br />
#x:5:respawn:/usr/sbin/gdm -nodaemon<br />
#x:5:respawn:/usr/bin/kdm -nodaemon<br />
#x:5:respawn:/usr/bin/slim >& /dev/null<br />
#x:5:once:/bin/su johndoe -l -c "/bin/bash --login -c startx >/dev/null 2>&1"<br />
x:5:respawn:/usr/sbin/entranced --nodaemon >& /dev/null<br />
<br />
Enjoy!<br />
<br />
<br />
Note : e17 is still alpha software. At some point in the future things may not work as expected anymore. Although all packages are tested before added to the [community] repo, things may stop working for you. You are therefore encouraged to keep packages for the previous version on your computer, allowing you to downgrade if needed.<br />
<br />
If you find some unexpected behavior, there is a few things you can do. First try if the same behavior exists with the default theme. Second remove ~/.e (you may want to make a backup first). If you are sure you found a bug please report it directly upstream. If you are not sure if it is a bug in the software or in the package, report it on the [community] bug tracker.<br />
<br />
==== I want my e17 packages updated more often ====<br />
You can build your own Arch Linux e17 packages with a small python script called ArchE17. For more information and to download the latest version of the script, see [http://dev.archlinux.org/~ronald/e17.html http://dev.archlinux.org/~ronald/e17.html]<br />
<br />
== Installing E17 using easy_e17.sh ==<br />
<br />
The reason to use this method over the one mentioned before is mostly based on what you want to do, but I find it easier because the script (along with an extra tool) can give those who want more control over when E17 is updated than the aforementioned python script. It allows you to install components from E17's repository without having to go through and make a new PKGBUILD for it. With this script, when you uninstall this package, everything that was installed with the script is uninstalled. If you want to learn more about this script, see [http://ubuntuforums.org/showthread.php?t=916690 the thread for it on ubuntuforums.org].<br />
<br />
To install E17 using this script, [http://aur.archlinux.org/packages.php?ID=22793 download the tarball from AUR], extract it to a new directory, and run makepkg. Then run as root: <br />
pacman -U *.pkg.tar.gz.<br />
<br />
It will ask you a few questions and then install. You will need to put this in your .xinitrc in order to start E17:<br />
<br />
exec /opt/e17/bin/enlightenment_start<br />
<br />
It may be helpful to put /opt/e17/bin in your PATH, as then you won't have to add /opt/e17/bin in front of each program in order to run it. To do that, modify this line in /etc/profile:<br />
<br />
PATH="/bin:/usr/bin:/sbin:/usr/sbin"<br />
<br />
So that it reads instead:<br />
<br />
PATH="/bin:/usr/bin:/sbin:/usr/sbin:/opt/e17/bin"<br />
<br />
If you encounter any errors while trying to install E17, first check to make sure it isn't a dependency problem. If it is, install the dependency and continue installing e17 by running this command as root:<br />
<br />
easy_e17.sh -i<br />
<br />
To install one of the many applications from E17's svn repository, simply remove that program's name from /etc/easy_e17.conf, and then run this command as root (replacing name and name2 by the name of the program(s) you removed from easy_e17.conf):<br />
<br />
easy_e17.sh -i --only=''name'',''name2''<br />
<br />
To update E17 without using the program mentioned below, run this command as root:<br />
<br />
easy_e17.sh -u<br />
<br />
=== Update_e17.sh ===<br />
Another package, for OzOs's update_e17.sh script, is helpful when used in conjunction with this script, as it can backup and restore your E17 svn tree (in case there is breakage), as well as roll it back to a specific revision (again, in case of breakage) or even let you know when a new revision has come around on E17's svn tree. See [http://cafelinux.org/OzOs/content/how-administer-your-ozos-e17-desktop this page] for more information on this optional component. To install this, use either of the above methods. The AUR page is located [http://aur.archlinux.org/packages.php?ID=23227 here].<br />
<br />
=== Configuring Entrance ===<br />
If you installed e17 through easy_e17.sh you have to do some further configurations to get entrance working.<br />
<br />
To '''set up entrance as your login manager''' proceed as above.<br />
The correct path of entranced to be put into {{Filename|/etc/inittab}} is of course<br />
x:5:respawn:/opt/e17/sbin/entranced --nodaemon >& /dev/null<br />
If you want to start entrance as daemon put [http://repos.archlinux.org/wsvn/community/entrance-svn/trunk/entranced entranced] from {{Package Official|entrance-svn}} into {{Filename|/etc/rc.d/}} and add it to your DAEMONS array in {{Filename|/etc/rc.conf}}.<br />
<br />
At first you have to '''allow authentication via PAM'''. Therefore get [http://repos.archlinux.org/wsvn/community/entrance-svn/trunk/entrance.pam entrance.pam] from the {{Package Official|entrance-svn}} package and store it as {{Filename|/etc/pam.d/entrance}}.<br />
<br />
The following two paragraphs are '''just background information''', skip them if you're in a hurry.<br />
<br />
Now the launching and the user authentication should work correctly. But as you'll notice after authentication entrance will fade out and come right back. The reason is that we didn't tell entrance what to launch after authentication.<br />
This is done through the file {{Filename|/etc/X11/Xsession}} (can be set at compile time by ENTRANCE_XSESSION) and the .desktop files in your xsessions directories.<br />
The following xsessions directories are scanned by entrance:<br />
{{Filename|/opt/e17/etc/xsessions/}} (set at compile time by ENTRANCE_SESSIONS_DIR), {{Filename|$XDG_DATA_HOME/xsessions/}} and all <tt>xsessions</tt> directories in your $XDG_DATA_DIRS.<br />
<br />
Entrance allows you to choose between multiple sessions which are can be configured via the .desktop files in the xsessions directories. After entrance authenticated the user correctly it executes this file and passes it a string as command line argument.<br />
If you chose ''Default'' as session it is just an empty string or "default" whereas the ''Failsafe'' session passes "failsafe".<br />
For any other session it's the ''exec'' line of the .desktop file of your session.<br />
<br />
So we have to '''configure your X11 sessions'''.<br />
At first create {{Filename|/etc/X11/Xsession}} and make it executable<br />
touch /etc/X11/Xsession<br />
chmod +x /etc/X11/Xsession # this is important!<br />
<br />
I use a modified version of KDM's Xsession script (got the base version from [http://bugs.gentoo.org/show_bug.cgi?id=301051 gentoo bug tracker]):<br />
{{File|name=/etc/X11/Xsession|content=<nowiki><br />
#! /bin/sh<br />
# Xsession - run as user<br />
<br />
session=${1:-default}<br />
<br />
# Note that the respective logout scripts are not sourced.<br />
case $SHELL in<br />
*/bash)<br />
[ -z "$BASH" ] && exec $SHELL $0 "$@"<br />
set +o posix<br />
[ -f /etc/profile ] && . /etc/profile<br />
if [ -f $HOME/.bash_profile ]; then<br />
. $HOME/.bash_profile<br />
elif [ -f $HOME/.bash_login ]; then<br />
. $HOME/.bash_login<br />
elif [ -f $HOME/.profile ]; then<br />
. $HOME/.profile<br />
fi<br />
;;<br />
*/zsh)<br />
[ -z "$ZSH_NAME" ] && exec $SHELL $0 "$@"<br />
emulate -R zsh<br />
[ -d /etc/zsh ] && zdir=/etc/zsh || zdir=/etc<br />
zhome=${ZDOTDIR:-$HOME}<br />
# zshenv is always sourced automatically.<br />
[ -f $zdir/zprofile ] && . $zdir/zprofile<br />
[ -f $zhome/.zprofile ] && . $zhome/.zprofile<br />
[ -f $zdir/zlogin ] && . $zdir/zlogin<br />
[ -f $zhome/.zlogin ] && . $zhome/.zlogin<br />
;;<br />
*/csh|*/tcsh)<br />
# [t]cshrc is always sourced automatically.<br />
# Note that sourcing csh.login after .cshrc is non-standard.<br />
xsess_tmp=`mktemp /tmp/xsess-env-XXXXXX`<br />
$SHELL -c "if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c export -p >! $xsess_tmp"<br />
. $xsess_tmp<br />
rm -f $xsess_tmp<br />
;;<br />
*) # Plain sh, ksh, and anything we do not know.<br />
[ -f /etc/profile ] && . /etc/profile<br />
[ -f $HOME/.profile ] && . $HOME/.profile<br />
;;<br />
esac<br />
<br />
[ -f /etc/xprofile ] && . /etc/xprofile<br />
[ -f $HOME/.xprofile ] && . $HOME/.xprofile<br />
<br />
# run all system xinitrc shell scripts.<br />
if [ -d /etc/X11/xinit/xinitrc.d ]; then<br />
for i in /etc/X11/xinit/xinitrc.d/* ; do<br />
if [ -x "$i" ]; then<br />
. "$i"<br />
fi<br />
done<br />
fi<br />
<br />
case $session in<br />
"")<br />
exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session."<br />
;;<br />
failsafe)<br />
exec xterm -geometry 80x24-0-0<br />
;;<br />
custom)<br />
exec $HOME/.xsession<br />
;;<br />
default)<br />
exec /opt/e17/bin/enlightenment_start<br />
;;<br />
*)<br />
eval exec "$session"<br />
;;<br />
esac<br />
exec xmessage -center -buttons OK:0 -default OK "Sorry, cannot execute $session. Check $DESKTOP_SESSION.desktop."<br />
</nowiki>}}<br />
<br />
That's it the next reboot should bring entrance up and after authentication the ''Default'' session should bring you into E.<br />
<br />
== Installing Themes ==<br />
More themes to customize the look of e17 are available from [http://exchange.enlightenment.org/ exchange.enlightenment.org].<br />
Make sure you also check out [http://www.e17-stuff.org e17-stuff.org].<br />
<br />
You can install the themes (coming in .edj format) from the configuration dialog.<br />
<br />
You can also change the theme for the etk toolkit (the one which is used by exhibit). You can start the dialog to change the etk toolkit by starting /usr/bin/etk_prefs<br />
<br />
[http://aur.archlinux.org/packages.php?ID=7896 e17-themes] (aur package), can automate the download and install of lots of themes from exchange.enlightenment.org<br />
<br />
== Troubleshooting ==<br />
* If X complains about X cursors not being available, get the package 'libxcursor'.<br />
* If screenlock does not accept your password add the following to /etc/pam.d/enlightenment:<br />
auth required pam_unix_auth.so<br />
<br />
== External Links ==<br />
* [http://exchange.enlightenment.org/ Exchange.enlightenment.org, a new, integrated site that replaces the former get-e.org. get-e.org closed August, 2008.]<br />
* [http://e17-stuff.org/ e17-stuff.org, Themes, backgrounds, etc. are available here]<br />
* [http://trac.enlightenment.org/e/wiki/Entrance, Entrance Article in official E17 wiki]</div>Buergihttps://wiki.archlinux.org/index.php?title=E17&diff=97691E172010-02-21T01:44:47Z<p>Buergi: /* Configuring Entrance */ corrected contentual mistake</p>
<hr />
<div>[[Category:Desktop environments (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|E17}}<br />
<br />
E17 is the Development Release 17 (DR17) of the Enlightenment Desktop Environment.<br />
<br />
E17 is currently under heavy development, and is in the pre-alpha stages. Even though it is only young, E17 is still quite stable. Many people use it as a day-to-day Environment. <br />
<br />
New versions are available daily via SVN, but snapshots are also taken for easy installation. Below are instructions on how to install a SVN snapshot from the Arch community repositories.<br />
<br />
== Installing E17 from the community repository ==<br />
<br />
* First, edit your /etc/pacman.conf file and uncomment the community repositories by removing the hash at the start of that line; you should end up with something like the following:<br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
* Next, sync, update, and upgrade using the new community repository:<br />
pacman -Syu<br />
* Install e17 group:<br />
pacman -S e-svn<br />
* Install additional e17 modules and applications:<br />
pacman -S desktop-file-utils e17-extra-svn<br />
*Install additional fonts in order to avoid any trouble at the first start of e17<br />
pacman -S artwiz-fonts ttf-ms-fonts<br />
* If you need an e17 package which is not (yet) available in the [community] repo, see if it is available in the [http://aur.archlinux.org/ AUR].<br />
<br />
You are now ready. You can allow '''~/.xinitrc''' to start ''enlightenment'' for you:<br />
<br />
...<br />
# exec gnome-session<br />
# exec startkde<br />
# exec startxfce4<br />
# ...or the Window Manager of your choice<br />
exec enlightenment_start<br />
<br />
If you want the ''entrance'' login manager (to replace [[KDM]]/[[GDM]]), you can either do this via:<br />
<br />
* '''/etc/rc.conf''' - You only get the login manager on startup; it will not be there if you CTRL+ALT+BACKSPACE<br />
<br />
...<br />
DAEMONS=(... entranced)<br />
...<br />
<br />
OR<br />
<br />
* '''/etc/inittab''' - The recommended way<br />
<br />
...<br />
## Only one of the following two lines can be uncommented!<br />
# Boot to console <br />
#id:3:initdefault: <br />
# Boot to X11 <br />
id:5:initdefault:<br />
<br />
...<br />
<br />
# Example lines for starting a login manager<br />
#x:5:respawn:/usr/bin/xdm -nodaemon<br />
#x:5:respawn:/usr/sbin/gdm -nodaemon<br />
#x:5:respawn:/usr/bin/kdm -nodaemon<br />
#x:5:respawn:/usr/bin/slim >& /dev/null<br />
#x:5:once:/bin/su johndoe -l -c "/bin/bash --login -c startx >/dev/null 2>&1"<br />
x:5:respawn:/usr/sbin/entranced --nodaemon >& /dev/null<br />
<br />
Enjoy!<br />
<br />
<br />
Note : e17 is still alpha software. At some point in the future things may not work as expected anymore. Although all packages are tested before added to the [community] repo, things may stop working for you. You are therefore encouraged to keep packages for the previous version on your computer, allowing you to downgrade if needed.<br />
<br />
If you find some unexpected behavior, there is a few things you can do. First try if the same behavior exists with the default theme. Second remove ~/.e (you may want to make a backup first). If you are sure you found a bug please report it directly upstream. If you are not sure if it is a bug in the software or in the package, report it on the [community] bug tracker.<br />
<br />
==== I want my e17 packages updated more often ====<br />
You can build your own Arch Linux e17 packages with a small python script called ArchE17. For more information and to download the latest version of the script, see [http://dev.archlinux.org/~ronald/e17.html http://dev.archlinux.org/~ronald/e17.html]<br />
<br />
== Installing E17 using easy_e17.sh ==<br />
<br />
The reason to use this method over the one mentioned before is mostly based on what you want to do, but I find it easier because the script (along with an extra tool) can give those who want more control over when E17 is updated than the aforementioned python script. It allows you to install components from E17's repository without having to go through and make a new PKGBUILD for it. With this script, when you uninstall this package, everything that was installed with the script is uninstalled. If you want to learn more about this script, see [http://ubuntuforums.org/showthread.php?t=916690 the thread for it on ubuntuforums.org].<br />
<br />
To install E17 using this script, [http://aur.archlinux.org/packages.php?ID=22793 download the tarball from AUR], extract it to a new directory, and run makepkg. Then run as root: <br />
pacman -U *.pkg.tar.gz.<br />
<br />
It will ask you a few questions and then install. You will need to put this in your .xinitrc in order to start E17:<br />
<br />
exec /opt/e17/bin/enlightenment_start<br />
<br />
It may be helpful to put /opt/e17/bin in your PATH, as then you won't have to add /opt/e17/bin in front of each program in order to run it. To do that, modify this line in /etc/profile:<br />
<br />
PATH="/bin:/usr/bin:/sbin:/usr/sbin"<br />
<br />
So that it reads instead:<br />
<br />
PATH="/bin:/usr/bin:/sbin:/usr/sbin:/opt/e17/bin"<br />
<br />
If you encounter any errors while trying to install E17, first check to make sure it isn't a dependency problem. If it is, install the dependency and continue installing e17 by running this command as root:<br />
<br />
easy_e17.sh -i<br />
<br />
To install one of the many applications from E17's svn repository, simply remove that program's name from /etc/easy_e17.conf, and then run this command as root (replacing name and name2 by the name of the program(s) you removed from easy_e17.conf):<br />
<br />
easy_e17.sh -i --only=''name'',''name2''<br />
<br />
To update E17 without using the program mentioned below, run this command as root:<br />
<br />
easy_e17.sh -u<br />
<br />
=== Update_e17.sh ===<br />
Another package, for OzOs's update_e17.sh script, is helpful when used in conjunction with this script, as it can backup and restore your E17 svn tree (in case there is breakage), as well as roll it back to a specific revision (again, in case of breakage) or even let you know when a new revision has come around on E17's svn tree. See [http://cafelinux.org/OzOs/content/how-administer-your-ozos-e17-desktop this page] for more information on this optional component. To install this, use either of the above methods. The AUR page is located [http://aur.archlinux.org/packages.php?ID=23227 here].<br />
<br />
=== Configuring Entrance ===<br />
If you installed e17 through easy_e17.sh you have to do some further configurations to get entrance working.<br />
<br />
To '''set up entrance as your login manager''' proceed as above.<br />
The correct path of entranced to be put into {{Filename|/etc/inittab}} is of course<br />
x:5:respawn:/opt/e17/sbin/entranced --nodaemon >& /dev/null<br />
If you want to start entrance as daemon put [http://repos.archlinux.org/wsvn/community/entrance-svn/trunk/entranced entranced] from {{Package Official|entrance-svn}} into {{Filename|/etc/rc.d/}} and add it to your DAEMONS array in {{Filename|/etc/rc.conf}}.<br />
<br />
At first you have to '''allow authentication via PAM'''. Therefore get [http://repos.archlinux.org/wsvn/community/entrance-svn/trunk/entrance.pam entrance.pam] from the {{Package Official|entrance-svn}} package and store it as {{Filename|/etc/pam.d/entrance}}.<br />
<br />
The following two paragraphs are '''just background information''', skip them if you're in a hurry.<br />
<br />
Now the launching and the user authentication should work correctly. But as you'll notice after authentication entrance will fade out and come right back. The reason is that we didn't tell entrance what to launch after authentication.<br />
This is done through the file {{Filename|/etc/X11/Xsession}} (can be set at compile time by ENTRANCE_XSESSION) and the .desktop files in your xsessions directories.<br />
The following xsessions directories are scanned by entrance:<br />
{{Filename|/opt/e17/etc/xsessions/}} (set at compile time by ENTRANCE_SESSIONS_DIR), {{Filename|$XDG_DATA_HOME/xsessions/}} and all <tt>xsessions</tt> directories in your $XDG_DATA_DIRS.<br />
<br />
Entrance allows you to choose between multiple sessions which are can be configured via the .desktop files in the xsessions directories. After entrance authenticated the user correctly it executes this file and passes it a string as command line argument.<br />
If you chose ''Default'' as session it is just an empty string or "default" whereas the ''Failsafe'' session passes "failsafe".<br />
For any other session it's the ''exec'' line of the .desktop file of your session.<br />
<br />
So we have to '''configure your X11 sessions'''.<br />
At first create {{Filename|/etc/X11/Xsession}} and make it executable<br />
touch /etc/X11/Xsession<br />
chmod +x /etc/X11/Xsession # this is important!<br />
<br />
I use a modified version of KDM's Xsession script (got the base version from [http://bugs.gentoo.org/show_bug.cgi?id=301051 gentoo bug tracker]):<br />
{{File|name=/etc/X11/Xsession|content=<nowiki><br />
#! /bin/sh<br />
# Xsession - run as user<br />
<br />
session=${1:-default}<br />
<br />
# Note that the respective logout scripts are not sourced.<br />
case $SHELL in<br />
*/bash)<br />
[ -z "$BASH" ] && exec $SHELL $0 "$@"<br />
set +o posix<br />
[ -f /etc/profile ] && . /etc/profile<br />
if [ -f $HOME/.bash_profile ]; then<br />
. $HOME/.bash_profile<br />
elif [ -f $HOME/.bash_login ]; then<br />
. $HOME/.bash_login<br />
elif [ -f $HOME/.profile ]; then<br />
. $HOME/.profile<br />
fi<br />
;;<br />
*/zsh)<br />
[ -z "$ZSH_NAME" ] && exec $SHELL $0 "$@"<br />
emulate -R zsh<br />
[ -d /etc/zsh ] && zdir=/etc/zsh || zdir=/etc<br />
zhome=${ZDOTDIR:-$HOME}<br />
# zshenv is always sourced automatically.<br />
[ -f $zdir/zprofile ] && . $zdir/zprofile<br />
[ -f $zhome/.zprofile ] && . $zhome/.zprofile<br />
[ -f $zdir/zlogin ] && . $zdir/zlogin<br />
[ -f $zhome/.zlogin ] && . $zhome/.zlogin<br />
;;<br />
*/csh|*/tcsh)<br />
# [t]cshrc is always sourced automatically.<br />
# Note that sourcing csh.login after .cshrc is non-standard.<br />
xsess_tmp=`mktemp /tmp/xsess-env-XXXXXX`<br />
$SHELL -c "if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c export -p >! $xsess_tmp"<br />
. $xsess_tmp<br />
rm -f $xsess_tmp<br />
;;<br />
*) # Plain sh, ksh, and anything we do not know.<br />
[ -f /etc/profile ] && . /etc/profile<br />
[ -f $HOME/.profile ] && . $HOME/.profile<br />
;;<br />
esac<br />
<br />
[ -f /etc/xprofile ] && . /etc/xprofile<br />
[ -f $HOME/.xprofile ] && . $HOME/.xprofile<br />
<br />
# run all system xinitrc shell scripts.<br />
if [ -d /etc/X11/xinit/xinitrc.d ]; then<br />
for i in /etc/X11/xinit/xinitrc.d/* ; do<br />
if [ -x "$i" ]; then<br />
. "$i"<br />
fi<br />
done<br />
fi<br />
<br />
case $session in<br />
"")<br />
exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session."<br />
;;<br />
failsafe)<br />
exec xterm -geometry 80x24-0-0<br />
;;<br />
custom)<br />
exec $HOME/.xsession<br />
;;<br />
default)<br />
exec /opt/e17/bin/enlightenment_start<br />
;;<br />
*)<br />
eval exec "$session"<br />
;;<br />
esac<br />
exec xmessage -center -buttons OK:0 -default OK "Sorry, cannot execute $session. Check $DESKTOP_SESSION.desktop."<br />
</nowiki>}}<br />
<br />
That's it the next reboot should bring entrance up and after authentication the ''Default'' session should bring you into E.<br />
<br />
'''Note:'''<br />
Entrance has one major configuration file which is in our case {{Filename|/opt/e17/etc/entrance_config.cfg}}. This file can easily be edited by using the shell script ''entrance_edit''. Since it assumes the file to be in /etc it's convenient to create a softlink.<br />
ln -s /opt/e17/etc/entrance_config.cfg /etc/entrance_config.cfg<br />
<br />
== Installing Themes ==<br />
More themes to customize the look of e17 are available from [http://exchange.enlightenment.org/ exchange.enlightenment.org].<br />
Make sure you also check out [http://www.e17-stuff.org e17-stuff.org].<br />
<br />
You can install the themes (coming in .edj format) from the configuration dialog.<br />
<br />
You can also change the theme for the etk toolkit (the one which is used by exhibit). You can start the dialog to change the etk toolkit by starting /usr/bin/etk_prefs<br />
<br />
[http://aur.archlinux.org/packages.php?ID=7896 e17-themes] (aur package), can automate the download and install of lots of themes from exchange.enlightenment.org<br />
<br />
== Troubleshooting ==<br />
* If X complains about X cursors not being available, get the package 'libxcursor'.<br />
* If screenlock does not accept your password add the following to /etc/pam.d/enlightenment:<br />
auth required pam_unix_auth.so<br />
<br />
== External Links ==<br />
* [http://exchange.enlightenment.org/ Exchange.enlightenment.org, a new, integrated site that replaces the former get-e.org. get-e.org closed August, 2008.]<br />
* [http://e17-stuff.org/ e17-stuff.org, Themes, backgrounds, etc. are available here]<br />
* [http://trac.enlightenment.org/e/wiki/Entrance, Entrance Article in official E17 wiki]</div>Buergihttps://wiki.archlinux.org/index.php?title=Entrance&diff=97689Entrance2010-02-21T00:24:58Z<p>Buergi: Redirected page to E17#Configuring Entrance</p>
<hr />
<div>#REDIRECT [[E17#Configuring_Entrance]]</div>Buergihttps://wiki.archlinux.org/index.php?title=E17&diff=97688E172010-02-21T00:23:27Z<p>Buergi: added new section /* Configuring Entrance */</p>
<hr />
<div>[[Category:Desktop environments (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|E17}}<br />
<br />
E17 is the Development Release 17 (DR17) of the Enlightenment Desktop Environment.<br />
<br />
E17 is currently under heavy development, and is in the pre-alpha stages. Even though it is only young, E17 is still quite stable. Many people use it as a day-to-day Environment. <br />
<br />
New versions are available daily via SVN, but snapshots are also taken for easy installation. Below are instructions on how to install a SVN snapshot from the Arch community repositories.<br />
<br />
== Installing E17 from the community repository ==<br />
<br />
* First, edit your /etc/pacman.conf file and uncomment the community repositories by removing the hash at the start of that line; you should end up with something like the following:<br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
* Next, sync, update, and upgrade using the new community repository:<br />
pacman -Syu<br />
* Install e17 group:<br />
pacman -S e-svn<br />
* Install additional e17 modules and applications:<br />
pacman -S desktop-file-utils e17-extra-svn<br />
*Install additional fonts in order to avoid any trouble at the first start of e17<br />
pacman -S artwiz-fonts ttf-ms-fonts<br />
* If you need an e17 package which is not (yet) available in the [community] repo, see if it is available in the [http://aur.archlinux.org/ AUR].<br />
<br />
You are now ready. You can allow '''~/.xinitrc''' to start ''enlightenment'' for you:<br />
<br />
...<br />
# exec gnome-session<br />
# exec startkde<br />
# exec startxfce4<br />
# ...or the Window Manager of your choice<br />
exec enlightenment_start<br />
<br />
If you want the ''entrance'' login manager (to replace [[KDM]]/[[GDM]]), you can either do this via:<br />
<br />
* '''/etc/rc.conf''' - You only get the login manager on startup; it will not be there if you CTRL+ALT+BACKSPACE<br />
<br />
...<br />
DAEMONS=(... entranced)<br />
...<br />
<br />
OR<br />
<br />
* '''/etc/inittab''' - The recommended way<br />
<br />
...<br />
## Only one of the following two lines can be uncommented!<br />
# Boot to console <br />
#id:3:initdefault: <br />
# Boot to X11 <br />
id:5:initdefault:<br />
<br />
...<br />
<br />
# Example lines for starting a login manager<br />
#x:5:respawn:/usr/bin/xdm -nodaemon<br />
#x:5:respawn:/usr/sbin/gdm -nodaemon<br />
#x:5:respawn:/usr/bin/kdm -nodaemon<br />
#x:5:respawn:/usr/bin/slim >& /dev/null<br />
#x:5:once:/bin/su johndoe -l -c "/bin/bash --login -c startx >/dev/null 2>&1"<br />
x:5:respawn:/usr/sbin/entranced --nodaemon >& /dev/null<br />
<br />
Enjoy!<br />
<br />
<br />
Note : e17 is still alpha software. At some point in the future things may not work as expected anymore. Although all packages are tested before added to the [community] repo, things may stop working for you. You are therefore encouraged to keep packages for the previous version on your computer, allowing you to downgrade if needed.<br />
<br />
If you find some unexpected behavior, there is a few things you can do. First try if the same behavior exists with the default theme. Second remove ~/.e (you may want to make a backup first). If you are sure you found a bug please report it directly upstream. If you are not sure if it is a bug in the software or in the package, report it on the [community] bug tracker.<br />
<br />
==== I want my e17 packages updated more often ====<br />
You can build your own Arch Linux e17 packages with a small python script called ArchE17. For more information and to download the latest version of the script, see [http://dev.archlinux.org/~ronald/e17.html http://dev.archlinux.org/~ronald/e17.html]<br />
<br />
== Installing E17 using easy_e17.sh ==<br />
<br />
The reason to use this method over the one mentioned before is mostly based on what you want to do, but I find it easier because the script (along with an extra tool) can give those who want more control over when E17 is updated than the aforementioned python script. It allows you to install components from E17's repository without having to go through and make a new PKGBUILD for it. With this script, when you uninstall this package, everything that was installed with the script is uninstalled. If you want to learn more about this script, see [http://ubuntuforums.org/showthread.php?t=916690 the thread for it on ubuntuforums.org].<br />
<br />
To install E17 using this script, [http://aur.archlinux.org/packages.php?ID=22793 download the tarball from AUR], extract it to a new directory, and run makepkg. Then run as root: <br />
pacman -U *.pkg.tar.gz.<br />
<br />
It will ask you a few questions and then install. You will need to put this in your .xinitrc in order to start E17:<br />
<br />
exec /opt/e17/bin/enlightenment_start<br />
<br />
It may be helpful to put /opt/e17/bin in your PATH, as then you won't have to add /opt/e17/bin in front of each program in order to run it. To do that, modify this line in /etc/profile:<br />
<br />
PATH="/bin:/usr/bin:/sbin:/usr/sbin"<br />
<br />
So that it reads instead:<br />
<br />
PATH="/bin:/usr/bin:/sbin:/usr/sbin:/opt/e17/bin"<br />
<br />
If you encounter any errors while trying to install E17, first check to make sure it isn't a dependency problem. If it is, install the dependency and continue installing e17 by running this command as root:<br />
<br />
easy_e17.sh -i<br />
<br />
To install one of the many applications from E17's svn repository, simply remove that program's name from /etc/easy_e17.conf, and then run this command as root (replacing name and name2 by the name of the program(s) you removed from easy_e17.conf):<br />
<br />
easy_e17.sh -i --only=''name'',''name2''<br />
<br />
To update E17 without using the program mentioned below, run this command as root:<br />
<br />
easy_e17.sh -u<br />
<br />
=== Update_e17.sh ===<br />
Another package, for OzOs's update_e17.sh script, is helpful when used in conjunction with this script, as it can backup and restore your E17 svn tree (in case there is breakage), as well as roll it back to a specific revision (again, in case of breakage) or even let you know when a new revision has come around on E17's svn tree. See [http://cafelinux.org/OzOs/content/how-administer-your-ozos-e17-desktop this page] for more information on this optional component. To install this, use either of the above methods. The AUR page is located [http://aur.archlinux.org/packages.php?ID=23227 here].<br />
<br />
=== Configuring Entrance ===<br />
If you installed e17 through easy_e17.sh you have to do some further configurations to get entrance working.<br />
<br />
To '''set up entrance as your login manager''' proceed as above.<br />
The correct path of entranced to be put into {{Filename|/etc/inittab}} is of course<br />
x:5:respawn:/opt/e17/sbin/entranced --nodaemon >& /dev/null<br />
If you want to start entrance as daemon put [http://repos.archlinux.org/wsvn/community/entrance-svn/trunk/entranced entranced] from {{Package Official|entrance-svn}} into {{Filename|/etc/rc.d/}} and add it to your DAEMONS array in {{Filename|/etc/rc.conf}}.<br />
<br />
Entrance has one major configuration file which is assumed to be {{Filename|/etc/entrance_config.cfg}} Due to the /opt/e17 prefix has to be linked to this position<br />
ln -s /opt/e17/etc/entrance_config.cfg /etc/entrance_config.cfg<br />
<br />
Note: As all e17 configuration files, this can be read and written via the ''eet'' command line utility. But you can also use entrance_edit to access it. But normally the default configuration works fine.<br />
<br />
Furthermore you have to '''allow authentication via PAM'''. Therefore get [http://repos.archlinux.org/wsvn/community/entrance-svn/trunk/entrance.pam entrance.pam] from the {{Package Official|entrance-svn}} package and store it as {{Filename|/etc/pam.d/entrance}}.<br />
<br />
The following two paragraphs are '''just background information''', skip them if you're in a hurry.<br />
<br />
Now the launching and the user authentication should work correctly. But as you'll notice after authentication entrance will fade out and come right back. The reason is that we didn't tell entrance what to launch after authentication.<br />
This is done through the file {{Filename|/etc/X11/Xsession}} (can be set at compile time by ENTRANCE_XSESSION) and the .desktop files in your xsessions directories.<br />
The following xsessions directories are scanned by entrance:<br />
{{Filename|/opt/e17/etc/xsessions/}} (set at compile time by ENTRANCE_SESSIONS_DIR), {{Filename|$XDG_DATA_HOME/xsessions/}} and all <tt>xsessions</tt> directories in your $XDG_DATA_DIRS.<br />
<br />
Entrance allows you to choose between multiple sessions which are can be configured via the .desktop files in the xsessions directories. After entrance authenticated the user correctly it executes this file and passes it a string as command line argument.<br />
If you chose ''Default'' as session it is just an empty string or "default" whereas the ''Failsafe'' session passes "failsafe".<br />
For any other session it's the ''exec'' line of the .desktop file of your session.<br />
<br />
So we have to '''configure your X11 sessions'''.<br />
At first create {{Filename|/etc/X11/Xsession}} and make it executable<br />
touch /etc/X11/Xsession<br />
chmod +x /etc/X11/Xsession # this is important!<br />
<br />
I use a modified version of KDM's Xsession script (got the base version from [http://bugs.gentoo.org/show_bug.cgi?id=301051 gentoo bug tracker]):<br />
{{File|name=/etc/X11/Xsession|content=<nowiki><br />
#! /bin/sh<br />
# Xsession - run as user<br />
<br />
session=${1:-default}<br />
<br />
# Note that the respective logout scripts are not sourced.<br />
case $SHELL in<br />
*/bash)<br />
[ -z "$BASH" ] && exec $SHELL $0 "$@"<br />
set +o posix<br />
[ -f /etc/profile ] && . /etc/profile<br />
if [ -f $HOME/.bash_profile ]; then<br />
. $HOME/.bash_profile<br />
elif [ -f $HOME/.bash_login ]; then<br />
. $HOME/.bash_login<br />
elif [ -f $HOME/.profile ]; then<br />
. $HOME/.profile<br />
fi<br />
;;<br />
*/zsh)<br />
[ -z "$ZSH_NAME" ] && exec $SHELL $0 "$@"<br />
emulate -R zsh<br />
[ -d /etc/zsh ] && zdir=/etc/zsh || zdir=/etc<br />
zhome=${ZDOTDIR:-$HOME}<br />
# zshenv is always sourced automatically.<br />
[ -f $zdir/zprofile ] && . $zdir/zprofile<br />
[ -f $zhome/.zprofile ] && . $zhome/.zprofile<br />
[ -f $zdir/zlogin ] && . $zdir/zlogin<br />
[ -f $zhome/.zlogin ] && . $zhome/.zlogin<br />
;;<br />
*/csh|*/tcsh)<br />
# [t]cshrc is always sourced automatically.<br />
# Note that sourcing csh.login after .cshrc is non-standard.<br />
xsess_tmp=`mktemp /tmp/xsess-env-XXXXXX`<br />
$SHELL -c "if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c export -p >! $xsess_tmp"<br />
. $xsess_tmp<br />
rm -f $xsess_tmp<br />
;;<br />
*) # Plain sh, ksh, and anything we do not know.<br />
[ -f /etc/profile ] && . /etc/profile<br />
[ -f $HOME/.profile ] && . $HOME/.profile<br />
;;<br />
esac<br />
<br />
[ -f /etc/xprofile ] && . /etc/xprofile<br />
[ -f $HOME/.xprofile ] && . $HOME/.xprofile<br />
<br />
# run all system xinitrc shell scripts.<br />
if [ -d /etc/X11/xinit/xinitrc.d ]; then<br />
for i in /etc/X11/xinit/xinitrc.d/* ; do<br />
if [ -x "$i" ]; then<br />
. "$i"<br />
fi<br />
done<br />
fi<br />
<br />
case $session in<br />
"")<br />
exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session."<br />
;;<br />
failsafe)<br />
exec xterm -geometry 80x24-0-0<br />
;;<br />
custom)<br />
exec $HOME/.xsession<br />
;;<br />
default)<br />
exec /opt/e17/bin/enlightenment_start<br />
;;<br />
*)<br />
eval exec "$session"<br />
;;<br />
esac<br />
exec xmessage -center -buttons OK:0 -default OK "Sorry, cannot execute $session. Check $DESKTOP_SESSION.desktop."<br />
</nowiki>}}<br />
<br />
That's it the next reboot should bring entrance up and after authentication the ''Default'' session should bring you into E.<br />
<br />
== Installing Themes ==<br />
More themes to customize the look of e17 are available from [http://exchange.enlightenment.org/ exchange.enlightenment.org].<br />
Make sure you also check out [http://www.e17-stuff.org e17-stuff.org].<br />
<br />
You can install the themes (coming in .edj format) from the configuration dialog.<br />
<br />
You can also change the theme for the etk toolkit (the one which is used by exhibit). You can start the dialog to change the etk toolkit by starting /usr/bin/etk_prefs<br />
<br />
[http://aur.archlinux.org/packages.php?ID=7896 e17-themes] (aur package), can automate the download and install of lots of themes from exchange.enlightenment.org<br />
<br />
== Troubleshooting ==<br />
* If X complains about X cursors not being available, get the package 'libxcursor'.<br />
* If screenlock does not accept your password add the following to /etc/pam.d/enlightenment:<br />
auth required pam_unix_auth.so<br />
<br />
== External Links ==<br />
* [http://exchange.enlightenment.org/ Exchange.enlightenment.org, a new, integrated site that replaces the former get-e.org. get-e.org closed August, 2008.]<br />
* [http://e17-stuff.org/ e17-stuff.org, Themes, backgrounds, etc. are available here]<br />
* [http://trac.enlightenment.org/e/wiki/Entrance, Entrance Article in official E17 wiki]</div>Buergihttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=97063Dm-crypt2010-02-16T14:41:09Z<p>Buergi: /* Storing the keyfile */ changed heading levels</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why Encryption? ==<br />
Encryption is useful for two (related) reasons. Firstly, it prevents anyone with physical access to your computer, and your hard drive in particular, from getting the data from it (unless they have your passphrase/key). Secondly, it allows you to wipe the data on your hard drive with far more confidence in the event of you selling or discarding your drive.<br />
<br />
Basically, it supplements the access control mechanisms of the operating system (like file permissions) by making it harder to bypass the operating system by inserting a boot CD, for example. Encrypting the root partition prevents anyone from using this method to insert viruses or trojans onto your computer.<br />
<br />
Note that we're not encrypting the boot partition - the bootloader needs to read that one!<br />
<br />
'''ATTENTION: Having encrypted partitions does not protect you from all possible attacks. The encryption is only as good as your key management, and there are other ways to break into computers while they are running. Read the CAVEATS section below!'''<br />
<br />
== Why LUKS for dm-crypt? ==<br />
There are either 3 or 4 rival disk encryption standards in Linux, depending on how you count them.<br />
<br />
The old cryptoloop is deprecated: it's old, insecure and unreliable.<br />
<br />
A much better version, loop-AES (http://loop-aes.sourceforge.net/), was created but, due to politics, never became favorable with the kernel developers. It's far more secure than either cryptoloop or straight device-mapper encryptions (and probably faster than any of the other 3 options), but is not user-friendly. It also requires non-standard kernel support, which ARCH's kernel26 doesn't have.<br />
<br />
The standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]) is another choice.<br />
<br />
[http://code.google.com/p/cryptsetup/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://code.google.com/p/cryptsetup/ LUKS home page] if you're interested), it stores all the needed setup information on the disk itself. All you need then is the password, which can be in a separate file if you like. The Linux implementation uses dm-crypt and it can have up to eight different passwords, which can be changed or revoked easily. It is also supported by mkinitcpio in ARCH linux, which is nice.<br />
<br />
== Caveats ==<br />
<br />
=== Security (encryption) ===<br />
Disk encryption is not the be-all and end-all of security. Why not? Well, for a start, it won't prevent people from hacking into a running computer (either over the network or at a console) if there is a security hole to exploited (and there invariably is). There are a dozen and one things you can (and should) do to secure your computer against this type of attack, but they are all outside the scope of this document.<br />
<br />
What's more, even in situations this type of encryption is useful for (physical access to storage media), it isn't worth a thing if someone has your key. In other words, if someone finds out or guesses your passphrase, or gets access to your external key file if you're using one, they can unlock the encryption on the hard drive in exactly the same way that you can.<br />
<br />
What does this mean for you? Well, if you use an external key file, keep the device it is on '''SAFE'''. Attach it to your keyring or whatever. If you use a passphrase, '''make it hard to guess'''. There are [http://www.google.co.uk/search?q=create+secure+password hundreds of documents] all over the internet telling you how to come up with a secure passphrase; we're not going to go over it here. Note, however, that we use the term "passphrase": '''it doesn't have to be a single word'''.<br />
<br />
== Getting started ==<br />
If you're not starting from an unused hard drive, '''BACK UP YOUR DATA!''' I cannot stress this enough. Ideally, you should be doing this regularly anyway, and it's particularly important with an encrypted hard drive. But beware: if you have unencrypted backups, is there any point in having an encrypted hard drive? Think about where you store your backups.<br />
<br />
'''Note:''' if you want to have encrypted swap, read the section below about Encrypted Swap and decide how you want to set it up ''before'' you start the rest of this HOWTO.<br />
<br />
Since Arch Linux 2009.08 the Arch installer provides a comfortable and easy way to configure dm_crypt (also in combination with [[LVM]]).<br />
Of course you can also do all the work manually.<br />
In either case it's recommended to overwrite the disk to wipe out former unencrypted content.<br />
<br />
== Preparation ==<br />
=== Overwriting ===<br />
Repartitioning and formatting your drive will only remove the filesystem metadata and will mostly leave the actual data intact, allowing determined attackers to recover data using tools like [http://foremost.sourceforge.net/ Foremost]. If your harddisk contained sensitive data from previous use, you might want to overwrite this data. Contrary to popular believe overwriting several times or using random data as source serves no purpose. Data won't be recoverable after being overwritten by zeros. [http://www.springerlink.com/content/408263ql11460147/]<br />
<br />
To overwrite your disk with zeros you can use<br />
# dd if=/dev/zero of=/dev/sda bs=1M<br />
<br />
If you want to check for bad blocks while writing you can use badblocks. <br />
The <tt>badblocks</tt> command will check your disk for bad blocks while writing random data. The pseudorandom algorithm used by this command is faster (although "less random") than <tt>/dev/urandom</tt>, so it can be useful for large disks. [[frandom]] is a fast random generator you might want to use for large disk.<br />
<br />
# badblocks -c 10240 -w -t random -s -v /dev/sda<br />
This will test blocks in groups of 10240 (i.e. 10MB) at a time, writing over them with random data and showing progress as it goes.<br />
<br />
However it should be noted that the pseudo random data generated by badblocks does not serve any other purpose than slowing down the wiping of your drive.<br />
<br />
== Arch Linux Installer (>2009.08) ==<br />
Since Arch Linux 2009.08 the installer supports dm_crypt and LVM (and combination of both) out of the box.<br />
<br />
Just run the installer as usual, i.e. follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]].<br />
When you reach the "Prepare Hard Drive(s)" don't use "Auto-Prepare" but set up your partitions manually.<br />
Beware that you '''have to''' create a separate unencrypted <tt>/boot</tt> partition, or GRUB/LILO has no chance to load the operating system afterwards.<br />
The most important step towards an encrypted system is done in the "Manually Configure ..." step.<br />
<br />
=== Configuring filesystems and mountpoints ===<br />
At first select the device corresponding to your unencrypted <tt>/boot</tt> partition, choose e.g. ext2 as filesystem and select <tt>/boot</tt> as the mountpoint.<br />
For all other partitions you created and which you want to be encrypted select dm_crypt in the filesystem dialog.<br />
You should enter a label for the encrypted device, e.g. 'sda2crypt', or simply 'root'.<br />
<br />
Here is an example listing how it may look like:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt<br />
/dev/sda3 raw->dm_crypt;yes;no_mountpoint;no_opts;sda3crypt<br />
/dev/mapper/sda2crypt dm_crypt->ext3;yes;/;no_opts;no_label;no_params<br />
/dev/mapper/sda3crypt dm_crypt->ext3;yes;/home;no_opts;no_label;no_params<br />
<br />
'''Note''': you can also put a LVM inside the dm_crypt partition, or vice versa a dm_crypt partition inside a LVM volume. See [[#Encrypting a LVM setup|Encrypting a LVM setup]] for details.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
That's it with the dm_crypt specific part for so far. Select your desired packages and install the system.<br />
The installer should perform all steps necessary for configuring the boot and mount process of your new system.<br />
You can check the configuration afterwards and compare them to the one in the section about manual configuration.<br />
Especially the HOOKS section in <tt>mkinitcpio.conf</tt> is important for an encrypted root partition.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
<br />
== Manually configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Partitioning ===<br />
At first set up your partitions as you want. Make sure you have a separate partition for /boot. If you think about it, this is absolutely necessary. If your /boot partition is encrypted, then your bootloader would not be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following - indicative - partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
/dev/sda5 -> /tmp # especially useful if you don't want to encrypt the entire root (/) partition<br />
<br />
=== Loading kernel modules ===<br />
'''Note:''' this article will use XTS-AES as encryption algorithm because it was standardized as IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices and it is quite secure, however the XTS mode is still flagged as "experimental" in the Linux kernel, so if you want something less secure but more proven, you should go with the CBC-ESSIV mode. The XTS mode is supported by Linux 2.6.24 upwards (ISO of Arch 2008.06 upwards).<br />
<br />
'''Note:''' The XTS mode uses two keys of the same size, therefore available sizes (using XTS-AES) are 256 (128 * 2), 384 (192 * 2) and 512 (256 * 2).<br />
<br />
Load the dm-crypt and the optimized AES module:<br />
# modprobe dm-crypt<br />
# modprobe aes-i586<br />
<br />
'''Note:''' x86_64 users can also try the "aes-x86_64" optimized module instead of "aes-i586".<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda4<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda4 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda4 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,4,5<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda4 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda4</tt> or <tt>/dev/sda5</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
'''Note:''' With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.<br />
<br />
'''Note:''' You might also want to replace /var/tmp/ with a symbolic link to /tmp.<br />
<br />
'''Note:''' If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.<br />
<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
'''Note:''' Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). If it is a ''swap'' or ''any other partition'', all is taken care by ''rc.sysinit'' and ''/etc/crypttab'' file'''<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keyboard' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
'''Note''' if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
'''Note:''' eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.<br />
<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda4 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
'''Note:''' Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
'''Note:''' Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, unless it has a LUKS header, then it simply won't work. If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a LUKS swap partition with a persistent key, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above. Omit steps 1 and 2 if you don't intend to use a saved key file.<br><br><br />
1. Generate a random key file <b>in a safe place</b> - encrypted root partition like my examples or secure USB stick.<br />
# dd if=/dev/urandom bs=1 count=512 of=/etc/keys/swap.key<br />
2. For security reasons, no user except root should have read-access to this file.<br />
# chown root:root /etc/keys/swap.key<br />
# chmod go-rwx /etc/keys/swap.key<br />
3. Format the partition you want to use as swap with '''cryptsetup''', using the key stored previously. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device> /etc/keys/swap.key<br />
* as stated in discussion: the -h parameter to specify hash function is (in this case) ignored, also the default hash - ripemd - is not recommended (citation needed). use aes-xts-plain:whirlpool , or aes-xts-sha256 instead. <br />
* check result with # cryptsetup luksDump /dev/<device>(sda3)<br />
<br />
If you don't use a saved key file, use this command:<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device><br />
4. Open the partition in ''/dev/mapper'' using the key:<br />
# cryptsetup luksOpen /dev/<device> swapDevice -d /etc/keys/swap.key<br />
If you don't use a saved key file, use this command:<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
5. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which uses the key file stored in ''/etc/keys/swap.key'' or asks for the passphrase before mounting, depending on your choice. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
6. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice -d /etc/keys/swap.key<br />
}<br />
If you don't use a saved key file, ''openswap'' should instead contain:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
7. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
add_file "/etc/keys/swap.key"<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
If you don't use a saved key file, remove unnecessary line '''add_file "/etc/keys/swap.key"''' from the file above.<br><br><br />
8. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
9. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
10. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
11. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (due to journaling filesystems etc this is also not 100% secure)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption together with LVM. We are not going to cover the process of setting up LVM here as there is already a guide for that ([[Installing_with_Software_RAID_or_LVM]]).<br />
<br />
The best method and easier method to follow for a laptop is to set up the LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda4 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "lvm2" hook in /etc/mkinitcpio.conf '''before''' the "encrypt" hook. And you will have to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
In <tt>/etc/mkinitcpio.conf</tt> add ''lvm2'' '''before''' ''encrypt'' in the HOOKS variable.<br />
<br />
That's it for the LVM&dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2 encrypt'' before ''filesystems.<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root</div>Buergihttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=97062Dm-crypt2010-02-16T14:38:07Z<p>Buergi: /* Quick method */ added note</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why Encryption? ==<br />
Encryption is useful for two (related) reasons. Firstly, it prevents anyone with physical access to your computer, and your hard drive in particular, from getting the data from it (unless they have your passphrase/key). Secondly, it allows you to wipe the data on your hard drive with far more confidence in the event of you selling or discarding your drive.<br />
<br />
Basically, it supplements the access control mechanisms of the operating system (like file permissions) by making it harder to bypass the operating system by inserting a boot CD, for example. Encrypting the root partition prevents anyone from using this method to insert viruses or trojans onto your computer.<br />
<br />
Note that we're not encrypting the boot partition - the bootloader needs to read that one!<br />
<br />
'''ATTENTION: Having encrypted partitions does not protect you from all possible attacks. The encryption is only as good as your key management, and there are other ways to break into computers while they are running. Read the CAVEATS section below!'''<br />
<br />
== Why LUKS for dm-crypt? ==<br />
There are either 3 or 4 rival disk encryption standards in Linux, depending on how you count them.<br />
<br />
The old cryptoloop is deprecated: it's old, insecure and unreliable.<br />
<br />
A much better version, loop-AES (http://loop-aes.sourceforge.net/), was created but, due to politics, never became favorable with the kernel developers. It's far more secure than either cryptoloop or straight device-mapper encryptions (and probably faster than any of the other 3 options), but is not user-friendly. It also requires non-standard kernel support, which ARCH's kernel26 doesn't have.<br />
<br />
The standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]) is another choice.<br />
<br />
[http://code.google.com/p/cryptsetup/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://code.google.com/p/cryptsetup/ LUKS home page] if you're interested), it stores all the needed setup information on the disk itself. All you need then is the password, which can be in a separate file if you like. The Linux implementation uses dm-crypt and it can have up to eight different passwords, which can be changed or revoked easily. It is also supported by mkinitcpio in ARCH linux, which is nice.<br />
<br />
== Caveats ==<br />
<br />
=== Security (encryption) ===<br />
Disk encryption is not the be-all and end-all of security. Why not? Well, for a start, it won't prevent people from hacking into a running computer (either over the network or at a console) if there is a security hole to exploited (and there invariably is). There are a dozen and one things you can (and should) do to secure your computer against this type of attack, but they are all outside the scope of this document.<br />
<br />
What's more, even in situations this type of encryption is useful for (physical access to storage media), it isn't worth a thing if someone has your key. In other words, if someone finds out or guesses your passphrase, or gets access to your external key file if you're using one, they can unlock the encryption on the hard drive in exactly the same way that you can.<br />
<br />
What does this mean for you? Well, if you use an external key file, keep the device it is on '''SAFE'''. Attach it to your keyring or whatever. If you use a passphrase, '''make it hard to guess'''. There are [http://www.google.co.uk/search?q=create+secure+password hundreds of documents] all over the internet telling you how to come up with a secure passphrase; we're not going to go over it here. Note, however, that we use the term "passphrase": '''it doesn't have to be a single word'''.<br />
<br />
== Getting started ==<br />
If you're not starting from an unused hard drive, '''BACK UP YOUR DATA!''' I cannot stress this enough. Ideally, you should be doing this regularly anyway, and it's particularly important with an encrypted hard drive. But beware: if you have unencrypted backups, is there any point in having an encrypted hard drive? Think about where you store your backups.<br />
<br />
'''Note:''' if you want to have encrypted swap, read the section below about Encrypted Swap and decide how you want to set it up ''before'' you start the rest of this HOWTO.<br />
<br />
Since Arch Linux 2009.08 the Arch installer provides a comfortable and easy way to configure dm_crypt (also in combination with [[LVM]]).<br />
Of course you can also do all the work manually.<br />
In either case it's recommended to overwrite the disk to wipe out former unencrypted content.<br />
<br />
== Preparation ==<br />
=== Overwriting ===<br />
Repartitioning and formatting your drive will only remove the filesystem metadata and will mostly leave the actual data intact, allowing determined attackers to recover data using tools like [http://foremost.sourceforge.net/ Foremost]. If your harddisk contained sensitive data from previous use, you might want to overwrite this data. Contrary to popular believe overwriting several times or using random data as source serves no purpose. Data won't be recoverable after being overwritten by zeros. [http://www.springerlink.com/content/408263ql11460147/]<br />
<br />
To overwrite your disk with zeros you can use<br />
# dd if=/dev/zero of=/dev/sda bs=1M<br />
<br />
If you want to check for bad blocks while writing you can use badblocks. <br />
The <tt>badblocks</tt> command will check your disk for bad blocks while writing random data. The pseudorandom algorithm used by this command is faster (although "less random") than <tt>/dev/urandom</tt>, so it can be useful for large disks. [[frandom]] is a fast random generator you might want to use for large disk.<br />
<br />
# badblocks -c 10240 -w -t random -s -v /dev/sda<br />
This will test blocks in groups of 10240 (i.e. 10MB) at a time, writing over them with random data and showing progress as it goes.<br />
<br />
However it should be noted that the pseudo random data generated by badblocks does not serve any other purpose than slowing down the wiping of your drive.<br />
<br />
== Arch Linux Installer (>2009.08) ==<br />
Since Arch Linux 2009.08 the installer supports dm_crypt and LVM (and combination of both) out of the box.<br />
<br />
Just run the installer as usual, i.e. follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]].<br />
When you reach the "Prepare Hard Drive(s)" don't use "Auto-Prepare" but set up your partitions manually.<br />
Beware that you '''have to''' create a separate unencrypted <tt>/boot</tt> partition, or GRUB/LILO has no chance to load the operating system afterwards.<br />
The most important step towards an encrypted system is done in the "Manually Configure ..." step.<br />
<br />
=== Configuring filesystems and mountpoints ===<br />
At first select the device corresponding to your unencrypted <tt>/boot</tt> partition, choose e.g. ext2 as filesystem and select <tt>/boot</tt> as the mountpoint.<br />
For all other partitions you created and which you want to be encrypted select dm_crypt in the filesystem dialog.<br />
You should enter a label for the encrypted device, e.g. 'sda2crypt', or simply 'root'.<br />
<br />
Here is an example listing how it may look like:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt<br />
/dev/sda3 raw->dm_crypt;yes;no_mountpoint;no_opts;sda3crypt<br />
/dev/mapper/sda2crypt dm_crypt->ext3;yes;/;no_opts;no_label;no_params<br />
/dev/mapper/sda3crypt dm_crypt->ext3;yes;/home;no_opts;no_label;no_params<br />
<br />
'''Note''': you can also put a LVM inside the dm_crypt partition, or vice versa a dm_crypt partition inside a LVM volume. See [[#Encrypting a LVM setup|Encrypting a LVM setup]] for details.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
That's it with the dm_crypt specific part for so far. Select your desired packages and install the system.<br />
The installer should perform all steps necessary for configuring the boot and mount process of your new system.<br />
You can check the configuration afterwards and compare them to the one in the section about manual configuration.<br />
Especially the HOOKS section in <tt>mkinitcpio.conf</tt> is important for an encrypted root partition.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
<br />
== Manually configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Partitioning ===<br />
At first set up your partitions as you want. Make sure you have a separate partition for /boot. If you think about it, this is absolutely necessary. If your /boot partition is encrypted, then your bootloader would not be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following - indicative - partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
/dev/sda5 -> /tmp # especially useful if you don't want to encrypt the entire root (/) partition<br />
<br />
=== Loading kernel modules ===<br />
'''Note:''' this article will use XTS-AES as encryption algorithm because it was standardized as IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices and it is quite secure, however the XTS mode is still flagged as "experimental" in the Linux kernel, so if you want something less secure but more proven, you should go with the CBC-ESSIV mode. The XTS mode is supported by Linux 2.6.24 upwards (ISO of Arch 2008.06 upwards).<br />
<br />
'''Note:''' The XTS mode uses two keys of the same size, therefore available sizes (using XTS-AES) are 256 (128 * 2), 384 (192 * 2) and 512 (256 * 2).<br />
<br />
Load the dm-crypt and the optimized AES module:<br />
# modprobe dm-crypt<br />
# modprobe aes-i586<br />
<br />
'''Note:''' x86_64 users can also try the "aes-x86_64" optimized module instead of "aes-i586".<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda4<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda4 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda4 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,4,5<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda4 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda4</tt> or <tt>/dev/sda5</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
'''Note:''' With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.<br />
<br />
'''Note:''' You might also want to replace /var/tmp/ with a symbolic link to /tmp.<br />
<br />
'''Note:''' If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.<br />
<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
'''Note:''' Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). If it is a ''swap'' or ''any other partition'', all is taken care by ''rc.sysinit'' and ''/etc/crypttab'' file'''<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keyboard' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
'''Note''' if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
'''Note:''' eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.<br />
<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda4 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
'''Note:''' Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
'''Note:''' Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, unless it has a LUKS header, then it simply won't work. If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a LUKS swap partition with a persistent key, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above. Omit steps 1 and 2 if you don't intend to use a saved key file.<br><br><br />
1. Generate a random key file <b>in a safe place</b> - encrypted root partition like my examples or secure USB stick.<br />
# dd if=/dev/urandom bs=1 count=512 of=/etc/keys/swap.key<br />
2. For security reasons, no user except root should have read-access to this file.<br />
# chown root:root /etc/keys/swap.key<br />
# chmod go-rwx /etc/keys/swap.key<br />
3. Format the partition you want to use as swap with '''cryptsetup''', using the key stored previously. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device> /etc/keys/swap.key<br />
* as stated in discussion: the -h parameter to specify hash function is (in this case) ignored, also the default hash - ripemd - is not recommended (citation needed). use aes-xts-plain:whirlpool , or aes-xts-sha256 instead. <br />
* check result with # cryptsetup luksDump /dev/<device>(sda3)<br />
<br />
If you don't use a saved key file, use this command:<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device><br />
4. Open the partition in ''/dev/mapper'' using the key:<br />
# cryptsetup luksOpen /dev/<device> swapDevice -d /etc/keys/swap.key<br />
If you don't use a saved key file, use this command:<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
5. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which uses the key file stored in ''/etc/keys/swap.key'' or asks for the passphrase before mounting, depending on your choice. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
6. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice -d /etc/keys/swap.key<br />
}<br />
If you don't use a saved key file, ''openswap'' should instead contain:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
7. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
add_file "/etc/keys/swap.key"<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
If you don't use a saved key file, remove unnecessary line '''add_file "/etc/keys/swap.key"''' from the file above.<br><br><br />
8. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
9. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
10. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
11. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (due to journaling filesystems etc this is also not 100% secure)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Storing the key as plain (visible) file ===<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Storing the key between MBR and 1st partition ===<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption together with LVM. We are not going to cover the process of setting up LVM here as there is already a guide for that ([[Installing_with_Software_RAID_or_LVM]]).<br />
<br />
The best method and easier method to follow for a laptop is to set up the LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda4 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "lvm2" hook in /etc/mkinitcpio.conf '''before''' the "encrypt" hook. And you will have to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
In <tt>/etc/mkinitcpio.conf</tt> add ''lvm2'' '''before''' ''encrypt'' in the HOOKS variable.<br />
<br />
That's it for the LVM&dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2 encrypt'' before ''filesystems.<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root</div>Buergihttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=96409Dm-crypt2010-02-12T14:37:09Z<p>Buergi: update due to new installer(>2009.08), manual sections preserved and extended</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why Encryption? ==<br />
Encryption is useful for two (related) reasons. Firstly, it prevents anyone with physical access to your computer, and your hard drive in particular, from getting the data from it (unless they have your passphrase/key). Secondly, it allows you to wipe the data on your hard drive with far more confidence in the event of you selling or discarding your drive.<br />
<br />
Basically, it supplements the access control mechanisms of the operating system (like file permissions) by making it harder to bypass the operating system by inserting a boot CD, for example. Encrypting the root partition prevents anyone from using this method to insert viruses or trojans onto your computer.<br />
<br />
Note that we're not encrypting the boot partition - the bootloader needs to read that one!<br />
<br />
'''ATTENTION: Having encrypted partitions does not protect you from all possible attacks. The encryption is only as good as your key management, and there are other ways to break into computers while they are running. Read the CAVEATS section below!'''<br />
<br />
== Why LUKS for dm-crypt? ==<br />
There are either 3 or 4 rival disk encryption standards in Linux, depending on how you count them.<br />
<br />
The old cryptoloop is deprecated: it's old, insecure and unreliable.<br />
<br />
A much better version, loop-AES (http://loop-aes.sourceforge.net/), was created but, due to politics, never became favorable with the kernel developers. It's far more secure than either cryptoloop or straight device-mapper encryptions (and probably faster than any of the other 3 options), but is not user-friendly. It also requires non-standard kernel support, which ARCH's kernel26 doesn't have.<br />
<br />
The standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]) is another choice.<br />
<br />
[http://code.google.com/p/cryptsetup/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://code.google.com/p/cryptsetup/ LUKS home page] if you're interested), it stores all the needed setup information on the disk itself. All you need then is the password, which can be in a separate file if you like. The Linux implementation uses dm-crypt and it can have up to eight different passwords, which can be changed or revoked easily. It is also supported by mkinitcpio in ARCH linux, which is nice.<br />
<br />
== Caveats ==<br />
<br />
=== Security (encryption) ===<br />
Disk encryption is not the be-all and end-all of security. Why not? Well, for a start, it won't prevent people from hacking into a running computer (either over the network or at a console) if there is a security hole to exploited (and there invariably is). There are a dozen and one things you can (and should) do to secure your computer against this type of attack, but they are all outside the scope of this document.<br />
<br />
What's more, even in situations this type of encryption is useful for (physical access to storage media), it isn't worth a thing if someone has your key. In other words, if someone finds out or guesses your passphrase, or gets access to your external key file if you're using one, they can unlock the encryption on the hard drive in exactly the same way that you can.<br />
<br />
What does this mean for you? Well, if you use an external key file, keep the device it is on '''SAFE'''. Attach it to your keyring or whatever. If you use a passphrase, '''make it hard to guess'''. There are [http://www.google.co.uk/search?q=create+secure+password hundreds of documents] all over the internet telling you how to come up with a secure passphrase; we're not going to go over it here. Note, however, that we use the term "passphrase": '''it doesn't have to be a single word'''.<br />
<br />
== Getting started ==<br />
If you're not starting from an unused hard drive, '''BACK UP YOUR DATA!''' I cannot stress this enough. Ideally, you should be doing this regularly anyway, and it's particularly important with an encrypted hard drive. But beware: if you have unencrypted backups, is there any point in having an encrypted hard drive? Think about where you store your backups.<br />
<br />
'''Note:''' if you want to have encrypted swap, read the section below about Encrypted Swap and decide how you want to set it up ''before'' you start the rest of this HOWTO.<br />
<br />
Since Arch Linux 2009.08 the Arch installer provides a comfortable and easy way to configure dm_crypt (also in combination with [[LVM]]).<br />
Of course you can also do all the work manually.<br />
In either case it's recommended to overwrite the disk to wipe out former unencrypted content.<br />
<br />
== Preparation ==<br />
=== Overwriting ===<br />
Repartitioning and formatting your drive will only remove the filesystem metadata and will mostly leave the actual data intact, allowing determined attackers to recover data using tools like [http://foremost.sourceforge.net/ Foremost]. If your harddisk contained sensitive data from previous use, you might want to overwrite this data. Contrary to popular believe overwriting several times or using random data as source serves no purpose. Data won't be recoverable after being overwritten by zeros. [http://www.springerlink.com/content/408263ql11460147/]<br />
<br />
To overwrite your disk with zeros you can use<br />
# dd if=/dev/zero of=/dev/sda bs=1M<br />
<br />
If you want to check for bad blocks while writing you can use badblocks. <br />
The <tt>badblocks</tt> command will check your disk for bad blocks while writing random data. The pseudorandom algorithm used by this command is faster (although "less random") than <tt>/dev/urandom</tt>, so it can be useful for large disks. [[frandom]] is a fast random generator you might want to use for large disk.<br />
<br />
# badblocks -c 10240 -w -t random -s -v /dev/sda<br />
This will test blocks in groups of 10240 (i.e. 10MB) at a time, writing over them with random data and showing progress as it goes.<br />
<br />
However it should be noted that the pseudo random data generated by badblocks does not serve any other purpose than slowing down the wiping of your drive.<br />
<br />
== Arch Linux Installer (>2009.08) ==<br />
Since Arch Linux 2009.08 the installer supports dm_crypt and LVM (and combination of both) out of the box.<br />
<br />
Just run the installer as usual, i.e. follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]].<br />
When you reach the "Prepare Hard Drive(s)" don't use "Auto-Prepare" but set up your partitions manually.<br />
Beware that you '''have to''' create a separate unencrypted <tt>/boot</tt> partition, or GRUB/LILO has no chance to load the operating system afterwards.<br />
The most important step towards an encrypted system is done in the "Manually Configure ..." step.<br />
<br />
=== Configuring filesystems and mountpoints ===<br />
At first select the device corresponding to your unencrypted <tt>/boot</tt> partition, choose e.g. ext2 as filesystem and select <tt>/boot</tt> as the mountpoint.<br />
For all other partitions you created and which you want to be encrypted select dm_crypt in the filesystem dialog.<br />
You can should enter a label for the encrypted device, e.g. 'sda2crypt', or simply 'root'.<br />
<br />
Here is an example listing how it may look like:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt<br />
/dev/sda3 raw->dm_crypt;yes;no_mountpoint;no_opts;sda3crypt<br />
/dev/mapper/sda2crypt dm_crypt->ext3;yes;/;no_opts;no_label;no_params<br />
/dev/mapper/sda3crypt dm_crypt->ext3;yes;/home;no_opts;no_label;no_params<br />
<br />
'''Note''': you can also put a LVM inside the dm_crypt partition, or vice versa a dm_crypt partition inside a LVM volume. See [[#Encrypting a LVM setup|Encrypting a LVM setup]] for details.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
That's it with the dm_crypt specific part for so far. Select your desired packages and install the system.<br />
The installer should perform all steps necessary for configuring the boot and mount process of your new system.<br />
You can check the configuration afterwards and compare them to the one in the section about manual configuration.<br />
Especially the HOOKS section in <tt>mkinitcpio.conf</tt> is important for an encrypted root partition.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
<br />
== Manually configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Partitioning ===<br />
At first set up your partitions as you want. Make sure you have a separate partition for /boot. If you think about it, this is absolutely necessary. If your /boot partition is encrypted, then your bootloader would not be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following - indicative - partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
/dev/sda5 -> /tmp # especially useful if you don't want to encrypt the entire root (/) partition<br />
<br />
=== Loading kernel modules ===<br />
'''Note:''' this article will use XTS-AES as encryption algorithm because it was standardized as IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices and it is quite secure, however the XTS mode is still flagged as "experimental" in the Linux kernel, so if you want something less secure but more proven, you should go with the CBC-ESSIV mode. The XTS mode is supported by Linux 2.6.24 upwards (ISO of Arch 2008.06 upwards).<br />
<br />
'''Note:''' The XTS mode uses two keys of the same size, therefore available sizes (using XTS-AES) are 256 (128 * 2), 384 (192 * 2) and 512 (256 * 2).<br />
<br />
Load the dm-crypt and the optimized AES module:<br />
# modprobe dm-crypt<br />
# modprobe aes-i586<br />
<br />
'''Note:''' x86_64 users can also try the "aes-x86_64" optimized module instead of "aes-i586".<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda4<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda4 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda4 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,4,5<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda4 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda4</tt> or <tt>/dev/sda5</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
'''Note:''' With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.<br />
<br />
'''Note:''' You might also want to replace /var/tmp/ with a symbolic link to /tmp.<br />
<br />
'''Note:''' If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.<br />
<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
'''Note:''' Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). If it is a ''swap'' or ''any other partition'', all is taken care by ''rc.sysinit'' and ''/etc/crypttab'' file'''<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keyboard' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
'''Note''' if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
'''Note:''' eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.<br />
<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda4 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
'''Note:''' Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
'''Note:''' Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, unless it has a LUKS header, then it simply won't work. If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a LUKS swap partition with a persistent key, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above. Omit steps 1 and 2 if you don't intend to use a saved key file.<br><br><br />
1. Generate a random key file <b>in a safe place</b> - encrypted root partition like my examples or secure USB stick.<br />
# dd if=/dev/urandom bs=1 count=512 of=/etc/keys/swap.key<br />
2. For security reasons, no user except root should have read-access to this file.<br />
# chown root:root /etc/keys/swap.key<br />
# chmod go-rwx /etc/keys/swap.key<br />
3. Format the partition you want to use as swap with '''cryptsetup''', using the key stored previously. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device> /etc/keys/swap.key<br />
* as stated in discussion: the -h parameter to specify hash function is (in this case) ignored, also the default hash - ripemd - is not recommended (citation needed). use aes-xts-plain:whirlpool , or aes-xts-sha256 instead. <br />
* check result with # cryptsetup luksDump /dev/<device>(sda3)<br />
<br />
If you don't use a saved key file, use this command:<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device><br />
4. Open the partition in ''/dev/mapper'' using the key:<br />
# cryptsetup luksOpen /dev/<device> swapDevice -d /etc/keys/swap.key<br />
If you don't use a saved key file, use this command:<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
5. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which uses the key file stored in ''/etc/keys/swap.key'' or asks for the passphrase before mounting, depending on your choice. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
6. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice -d /etc/keys/swap.key<br />
}<br />
If you don't use a saved key file, ''openswap'' should instead contain:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
7. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
add_file "/etc/keys/swap.key"<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
If you don't use a saved key file, remove unnecessary line '''add_file "/etc/keys/swap.key"''' from the file above.<br><br><br />
8. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
9. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
10. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
11. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (due to journaling filesystems etc this is also not 100% secure)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
=== Storing the key as plain (visible) file ===<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
=== Storing the key between MBR and 1st partition ===<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption together with LVM. We are not going to cover the process of setting up LVM here as there is already a guide for that ([[Installing_with_Software_RAID_or_LVM]]).<br />
<br />
The best method and easier method to follow for a laptop is to set up the LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda4 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "lvm2" hook in /etc/mkinitcpio.conf '''before''' the "encrypt" hook. And you will have to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
In <tt>/etc/mkinitcpio.conf</tt> add ''lvm2'' '''before''' ''encrypt'' in the HOOKS variable.<br />
<br />
That's it for the LVM&dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2 encrypt'' before ''filesystems.<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root</div>Buergihttps://wiki.archlinux.org/index.php?title=TuxOnIce&diff=74660TuxOnIce2009-08-26T10:22:49Z<p>Buergi: /* Recreating the initramfs */ added note and workaround about bug #15240</p>
<hr />
<div>[[Category:Power management (English)]]<br />
[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
This is a quick start guide for installing [http://www.tuxonice.net Tuxonice] (formerly suspend2), an advanced suspend/hibernate framework which supports suspending to a swap-disk or a regular file with fast LZO-compression. Visit the Tuxonice website for a full list of [http://www.tuxonice.net/features features].<br />
<br />
=Preparing the kernel=<br />
<br />
Tuxonice consists of a kernel patch, plus an optional user interface. Only the kernel patch is necessary, the user interface merely provides a graphical interface displayed during the hibernation/resume cycle. <br />
<br />
You can use the [http://aur.archlinux.org/packages.php?ID=15224 kernel26-ice] package in the [[AUR]]. It automatizes all the patch routines, the compilation and installation of the kernel, the regeneration of the initramfs with an appropriate hook. If you use [[Yaourt]] this procedure is very simple:<br />
<br />
# yaourt -S kernel26-ice<br />
<br />
You can also build the package manually, see [[AUR_User_Guidelines#Installing_Packages_from_the_AUR | Installing packages from the AUR]] for more information. Otherwise, you need to patch, configure and compile your own kernel, visit [[Kernel Compilation From Source]] and [[Kernel Compilation with ABS]] for instructions. The required patch can be obtained from the Tuxonice website mentioned above.<br />
<br />
<br />
Next, install the hibernate-script package from the Extra repository which we will use to call Tuxonice. Hibernate-script is the default script developed by the Tuxonice development team:<br />
<br />
# pacman -S hibernate-script<br />
<br />
The configuration files for hibernate-script are in /etc/hibernate, we will get back to them shortly.<br />
<br />
=Setting up the bootmanager=<br />
Before your can use the suspend function, you need to add the "resume" parameter in your bootmanager, unless you have hardcoded your swap partition during the kernel configuration. The resume parameter points to the swap partition or swap file, below are the steps involved for both methods.<br />
<br />
==Suspend to swap partition==<br />
If your swap partition is for instance /dev/sda3, you have to append "resume=swap:/dev/sda3" as a kernel parameter in your lilo.conf file or GRUB's /boot/grub/menu.lst. For example:<br />
<br />
title Arch Linux Ice<br />
kernel /boot/vmlinuz26-ice root=/dev/sda2 ro resume=swap:/dev/sda3<br />
initrd /boot/kernel26-ice.img<br />
<br />
Adjust accordingly to your specific case. Then uncomment and set the swap method in /etc/hibernate/suspend2.conf:<br />
<br />
SuspendDevice swap:/dev/sda3<br />
<br />
==Suspend to file==<br />
For the file allocator, you will have to prepare a hibernation file. First configure the /etc/hibernate/suspend2.conf file, uncomment the "FilewriterLocation" option:<br />
<br />
FilewriterLocation /suspend_file 1000<br />
<br />
1000 is the amount of diskspace reserved for the hibernation file, in this case 1000 Megabytes. Usually an amount of 50% - 75% of your total amount of RAM will suffice.<br />
<br />
Next, run the following command to create the hibernation file:<br />
<br />
# hibernate --no-suspend<br />
<br />
Take a look in /sys/power/tuxonice/resume for what to pass to your kernel. You should see something like file:/dev/hda7:0x10011f, in which case you should append "resume=file:/dev/hda7:0x10011f" as a kernel parameter in your lilo.conf file or GRUB's menu.lst.<br />
<br />
=Recreating the initramfs=<br />
{{Note|Resuming doesn't work with mkinitcpio 0.5.25 due to a bug in /lib/initcpio/hooks/resume.<br />
As a workaround downgrade to version 0.5.24 or replace the 6th line in /lib/initcpio/hooks/resume by<br />
resumedevice&#61;${resume#*:}<br />
resumedevice&#61;${resumedevice%:*}<br />
if [-n "${resumedevice}" ] && poll_device "${resumedevice}" ${rootdelay}; then<br />
}}<br />
If you use an initramfs, you need to add the resume hook in the HOOKS in the configuration of mkinitcpio. Additionally, if you want to speed things up by using LZO compression, add the lzo module to the MODULES array in the same file.<br />
<br />
/etc/mkinitcpio.conf example:<br />
<br />
MODULES="lzo"<br />
HOOKS="base udev autodetect pata scsi sata resume filesystems"<br />
<br />
Rebuild the initramfs:<br />
<br />
# mkinitcpio -p kernel26-ice<br />
<br />
=Suspending and resuming=<br />
With hibernate-script, your preferred hibernation method can be set in the file /etc/hibernate/hibernate.conf. If you list several methods, the first one will be used. Note that ''hibernate'' can also be used with [[Suspend to RAM]] or vanilla swsusp, but this is not part of this guide.<br />
<br />
For Tuxonice use: <br />
<br />
TryMethod suspend2.conf<br />
<br />
Specific settings for Tuxonice are in /etc/hibernate/suspend2.conf. Make sure that the following lines are uncommented and appropriately configured:<br />
<br />
UseSuspend2 yes<br />
Compressor lzo<br />
<br />
There is a number of additional settings and tweaks which you can set in /etc/hibernate/suspend2.conf and /etc/hibernate/common.conf, more information about these can be found on the [http://www.tuxonice.net/HOWTO-4.html Tuxonice] website and on the [[Suspend_to_Disk | Suspend to Disk]] page of this wiki.<br />
<br />
Now try Tuxonice hibernation with the following method:<br />
<br />
# hibernate -F /etc/hibernate/suspend2.conf<br />
<br />
You can abort a suspend cycle if you press the escape key. If you press a capital R, you will force the system to reboot after hibernation.<br />
<br />
If all goes well, you should be able to resume using the same Grub menu selection. If you make that option the default for Grub, you will always default to resuming if a resume image is available. '''Do never use a different kernel to resume than you used to suspend! If pacman updates your kernel, don't suspend before you have rebooted properly.''' It is recommended that you test the suspend/hibernate from a text console first and then once you have confirmed that it works try it from within X.<br />
<br />
You can make this practice safer adding the hibernate-cleanup daemon to your DAEMONS array in /etc/rc.conf. This script will make sure that any stale image is deleted from your swap partition at boot time. This should make your system safe also in the case that you have chosen the mistaken kernel at the grub prompt. The hibernate-cleanup service is included in the hibernate-script package.<br />
<br />
=Using userui - a user interface for Tuxonice (optional)=<br />
<br />
Optionally, you can use a text or graphical (fbsplash) interface with a progress bar with tuxonice. To do this, install the tuxonice-userui package from the AUR. This package depends on the static freetype2 library that is provided by freetype2-static (also in the AUR).<br />
<br />
In /etc/hibernate/suspend2.conf, set the desired user interface:<br />
<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_text # Text interface<br />
<br />
or<br />
<br />
ProcSetting user_interface/program /usr/sbin/tuxoniceui_fbsplash # Graphical fbsplash interface<br />
<br />
The fbsplash interface also needs a fbsplash theme placed in /etc/splash/suspend2/.<br />
<br />
The text interface may be good for debugging suspend2, as it displays some messages.<br />
You won't see a user interface for the first few seconds of the resume process unless you add the ''userui'' hook to your mkinitcpio (before the ''resume'' hook) configuration and regenerate your initramfs, but this is also optional. <br />
<br />
Generate initramfs:<br />
<br />
# mkinitcpio -p kernel26-ice<br />
<br />
To test if userui works, switch to a text console and run:<br />
<br />
tuxoniceui_text --test<br />
<br />
For the graphical interface run:<br />
<br />
tuxoniceui_fbsplash --test<br />
<br />
=References=<br />
<br />
*The [http://www.tuxonice.net Tuxonice website] and [http://wiki.tuxonice.net/ Tuxonice wiki] are excellent sources of documentation.<br />
*More general information about suspend/hibernate with hibernate-script can be found on the [[Suspend_to_Disk | Suspend to Disk]] page of this wiki. This also covers some advanced topics like problems with specific hardware and configurations.<br />
*Another good source of information is the [http://en.gentoo-wiki.com/wiki/TuxOnIce Gentoo wiki]</div>Buergi