https://wiki.archlinux.org/api.php?action=feedcontributions&user=Nrm&feedformat=atomArchWiki - User contributions [en]2024-03-29T14:42:18ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Tcplay&diff=317811Tcplay2014-06-03T09:27:18Z<p>Nrm: /* Encrypting a file as a virtual volume */ Modification of dd command, fallocate is dedicated to that.</p>
<hr />
<div>{{DISPLAYTITLE:tcplay}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
{{Related articles start}}<br />
{{Related|Disk encryption}}<br />
{{Related|TrueCrypt}}<br />
{{Related|Tomb}}<br />
{{Related articles end}}<br />
''tcplay'' is a free, fully featured and stable TrueCrypt implementation including multiple keyfiles and cipher cascades.<br />
<br />
Source: [https://github.com/bwalex/tc-play github project home]<br />
<br />
== Installation ==<br />
Install {{Pkg|tcplay}} or {{AUR|tcplay-git}} from the AUR.<br />
<br />
== Encrypting a file as a virtual volume ==<br />
<br />
Invoke <br />
<br />
$ losetup -f<br />
<br />
to find the first unused loopback device; in this example, {{Ic|/dev/loop0}}.<br />
<br />
{{Note|As of udev 181-5, the {{Ic|loop}} device module is no longer auto-loaded.}}<br />
<br />
Create a new container {{Ic|foo.tc}}, 20M in size for instance, in the working<br />
directory:<br />
<br />
# fallocate -l 20M foo.tc<br />
# losetup /dev/loop0 foo.tc<br />
# tcplay -c -d /dev/loop0 -a whirlpool -b AES-256-XTS<br />
<br />
Enter a secure password for the volume, and confirm the query to overwrite<br />
{{Ic|foo.tc}} with the new volume. tcplay will then write random data into the<br />
volume. Map the volume and create a filesystem on it in order to mount<br />
<br />
# tcplay -m foo.tc -d /dev/loop0<br />
# mkfs.ext4 /dev/mapper/foo.tc<br />
# mount /dev/mapper/foo.tc /mnt/truecrypt/<br />
<br />
To unset the container,<br />
<br />
# umount /mnt/truecrypt<br />
# dmsetup remove foo.tc<br />
# losetup -d /dev/loop0<br />
<br />
==Mounting an existing container for a user==<br />
<br />
Consider {{Ic|/dev/loop0}} the first unused loop device, {{Ic|foo.tc}} the<br />
TrueCrypt container, {{Ic|/home/you/truecrypt/}} the desired mount point. The<br />
user {{Ic|you}} in this example has {{Ic|uid&#61;1000}} and {{Ic|gid&#61;100}}. The<br />
steps for mounting the container as a virtual volume are:<br />
<br />
# Associate loop device with the container<br />
# Map the container to the loop device<br />
# Mount the container in the filesystem<br />
<br />
The following commands perform the above actions.<br />
<br />
# losetup /dev/loop0 foo.tc<br />
# tcplay -m foo.tc -d /dev/loop0<br />
# mount -o nosuid,uid=1000,gid=100 /dev/mapper/foo.tc /home/you/truecrypt/<br />
<br />
To reverse them:<br />
<br />
# umount /home/you/truecrypt/<br />
# dmsetup remove foo.tc<br />
# losetup -d /dev/loop0<br />
<br />
== See also ==<br />
<br />
* [http://leaf.dragonflybsd.org/cgi/web-man?command=tcplay&section=8 Manual page for tcplay]<br />
* [http://jasonwryan.com/blog/2013/01/10/truecrypt/ Jason Ryan: Replacing TrueCrypt]<br />
* [http://www.truecrypt.org/ TrueCrypt Homepage]<br />
* [http://en.gentoo-wiki.com/wiki/TrueCrypt HOWTO: Truecrypt Gentoo wiki]<br />
* [http://www.howtoforge.com/truecrypt_data_encryption Truecrypt Tutorial on HowToForge]<br />
* [http://www.privacylover.com/encryption/analysis-is-there-a-backdoor-in-truecrypt-is-truecrypt-a-cia-honeypot/ There is a good chance the CIA has a backdoor?] (via [https://secure.wikimedia.org/wikipedia/en/wiki/Truecrypt wp])</div>Nrmhttps://wiki.archlinux.org/index.php?title=MariaDB&diff=313261MariaDB2014-05-03T19:25:38Z<p>Nrm: /* Reset the root password */ add use mysql to fix database selection</p>
<hr />
<div>[[Category:Database management systems]]<br />
[[cs:MySQL]]<br />
[[de:MySQL]]<br />
[[es:MySQL]]<br />
[[fr:MySQL]]<br />
[[it:MySQL]]<br />
[[ja: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's 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 chosen by Arch Linux is called [https://mariadb.org/ MariaDB].<br />
[[pacman|Install]] {{Pkg|mariadb}} from the [[official repositories]].<br />
Alternative implementations are:<br />
* {{App|Oracle MySQL|An implementation by Oracle Corporation.|https://www.mysql.com/|{{AUR|mysql}}}}<br />
* {{App|Percona Server|An implementation by Percona LLC.|http://www.percona.com/software/percona-server/|{{Pkg|percona-server}}}}<br />
<br />
{{Tip|If the database (in {{ic|/var/lib/mysql}}) resides in a [[btrfs]] file system 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 />
[[systemd#Using units|Start]] {{ic|mysqld.service}}, and then run the setup script:<br />
# mysql_secure_installation<br />
and restart {{ic|mysqld.service}} afterwards.<br />
<br />
Front-ends available are {{AUR|mysql-gui-tools}} and its successor {{AUR|mysql-workbench}}.<br />
<br />
=== Enable at startup ===<br />
To start the MySQL daemon at boot, enable the {{ic|mysqld.service}} unit.<br />
<br />
=== Upgrade from Oracle MySQL to MariaDB ===<br />
{{Note|It could be needed to remove the following files from {{ic|/var/lib/mysql}} : {{ic|ib_logfile0}}, {{ic|ib_logfile1}} and {{ic|aria_log_control}} before restarting the daemon in the following procedure.}}<br />
<br />
Users who want to switch will need to stop {{ic|mysqld.service}}, install {{pkg|mariadb}}, start {{ic|mysqld.service}}, and execute:<br />
# mysql_upgrade -p<br />
in order to migrate their systems.<br />
<br />
=== On update ===<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 />
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 />
=== Grant Remote Access ===<br />
If you want to access your MySQL server from other LAN hosts, you have to commen (with #) the following lines in your {{ic|/etc/mysql/my.cnf}}:<br />
[mysqld]<br />
...<br />
#skip-networking<br />
#bind-address = <some ip-address><br />
...<br />
Then you grant any mysql user you like remote access from your local network (example for root):<br />
Connect to your database with root:<br />
mysql -p -u root<br />
Check current users with remote access privileged:<br />
SELECT User, Host FROM mysql.user WHERE Host <> 'localhost';<br />
Now grant remote access for your user (here root)::<br />
GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.1.%' IDENTIFIED BY 'my_optional_remote_password' WITH GRANT OPTION;<br />
You can change the '%' wildcard to a specific host if you like. The password can be different from user's main password.<br />
<br />
=== Disable remote access ===<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 />
{{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 />
In the {{ic|/etc/mysql/my.cnf}} file section under the {{ic|mysqld}} group, add:<br />
<br />
{{bc|<nowiki><br />
[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<br />
</nowiki>}}<br />
<br />
=== Using a TMPFS for tmpdir ===<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 {{ic|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 {{ic|mysqld}} group:<br />
tmpdir = /var/lib/mysqltmp<br />
<br />
Then reboot or ( shutdown mysql, mount the tmpdir, start mysql ).<br />
<br />
== Backup ==<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|<nowiki><br />
#!/bin/bash<br />
<br />
THISDIR=$(dirname $(readlink -f "$0"))<br />
<br />
mysqldump --single-transaction --flush-logs --master-data=2 --all-databases \<br />
| gzip > $THISDIR/db_backup.gz<br />
echo 'purge master logs before date_sub(now(), interval 7 day);' | mysql<br />
</nowiki>}}<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 />
=== MySQL daemon cannot start ===<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 />
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 />
Stop {{ic|mysqld.service}}. 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 />
mysq/> use mysql;<br />
mysql> UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root';<br />
mysql> FLUSH PRIVILEGES;<br />
mysql> exit<br />
Start {{ic|mysqld.service}}.<br />
<br />
=== Check and repair all tables ===<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 />
Forcefully optimize all tables, automatically fixing table errors that may come up.<br />
# mysqlcheck -A --auto-repair -f -o -u root -p<br />
<br />
=== OS error 22 when running on ZFS ===<br />
If you are using [[ZFS]] and get the following error:<br />
InnoDB: Operating system error number 22 in a file operation.<br />
You need to disable aio_writes by adding a line to the mysqld-section in /etc/mysql/my.cnf <br />
[mysqld]<br />
...<br />
innodb_use_native_aio = 0<br />
<br />
=== Cannot login through CLI, but phpmyadmin works well ===<br />
This may happen if you're using a long (>70-75) password.<br />
As for 5.5.36, for some reason, mysql CLI cannot handle that much characters in readline mode.<br />
So, if you're planning to use the recommended password input mode:<br />
$ mysql -u <user> -p<br />
Password:<br />
consider changing the password to smaller one.<br />
<br />
{{Note|You still can log in by specifying the password an an argument to mysql command. <br />
{{Warning|This behavior considered dangerous, because your password might leak, for example, to the logs. Use it only in case of emergency and don't forget to change password right afterwards.}}<br />
$ mysql -u <user> -p"<some-veryveryveryveryveryveryveryveryveryveryveryveryveryveryvery-long-and-veryveryveryveryveryveryveryveryveryvery-strong-password>"<br />
}}<br />
<br />
== See also ==<br />
* [[LAMP]] - ArchWiki article covering the setup of a LAMP server (Linux Apache MySQL PHP)<br />
* [[PhpMyAdmin]] - ArchWiki article covering the web-based tool to help manage MySQL databases using an Apache/PHP front-end.<br />
* [[PHP]] - ArchWiki article on PHP.<br />
* [http://www.askapache.com/mysql/performance-tuning-mysql.html MySQL Performance Tuning Scripts and Know-How]</div>Nrmhttps://wiki.archlinux.org/index.php?title=Syslog-ng&diff=271804Syslog-ng2013-08-20T08:05:16Z<p>Nrm: /* Creating Filters for Messages */ Fix error</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
{{Note|After upgrading to systemd, syslog-ng is unnecessary for most users and can be uninstalled, since the systemd journal provides this functionality.}}<br />
<br />
==Overview==<br />
syslog-ng takes incoming log messages from defined '[[Syslog-ng#Sources|sources]]' and forwards them to the appropriate [[Syslog-ng#Destinations|destinations]], based on powerful [[Syslog-ng#Creating Filters for Messages|filter]] directives. In a typical simple set-up, syslog-ng will read messages from three sources:<br />
# the default {{ic|/dev/log}} device, where most logs are sent<br />
# syslog-ng "internal" log messages<br />
# {{ic|/proc/kmsg}} kernel messages<br />
<br />
Sources are defined using the "source" directive. These incoming messages are then filtered according to defined filters ("filter" keyword), i.e. according to originating program or log level, and sent to the appropriate "destination". Destinations include log files (e.g. {{ic|/var/log/messages.log}}), printing messages on a console and remote servers. The pivotal function is [[Syslog-ng#Log Paths|log]]. This function defines which filters should be applied to a certain source, and where the resulting messages should be sent to.<br />
<br />
==Example configuration file==<br />
For a quick start, here there is a classic configuration file slightly modified from the one in the <br />
[http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1&chap=3#doc_chap4 Gentoo Security Guide], the default {{ic|syslog-ng.conf}} provided with the source distribution, and my own personal preferences. This example includes logging from a chrooted bind source and logging to a remote server destination.<br />
<br />
{{hc|/etc/syslog-ng/syslog-ng.conf|<nowiki>@version: 3.0<br />
# For a description of syslog-ng configuration file directives, please read<br />
# the syslog-ng Administrator's guide at:<br />
#<br />
# http://www.balabit.com/dl/html/syslog-ng-admin-guide_en.html/bk01-toc.html<br />
#<br />
<br />
##########################################################<br />
# OPTIONS<br />
#<br />
options {<br />
create_dirs(yes);<br />
# use_dns(no);<br />
use_dns(persist_only);<br />
dns_cache_hosts(/etc/hosts);<br />
dns_cache_expire(87600);<br />
<br />
# disable the chained hostname format in logs (default is enabled)<br />
chain_hostnames(0);<br />
<br />
# the number of lines fitting in the output queue<br />
log_fifo_size(512);<br />
<br />
# enable or disable directory creation for destination files<br />
create_dirs(yes);<br />
<br />
# default owner, group, and permissions for log files (defaults are 0, 0, 0600)<br />
owner(root);<br />
group(log);<br />
perm(0640);<br />
<br />
# default owner, group, and permissions for created directories (defaults are 0, 0, 0700)<br />
dir_owner(root);<br />
dir_group(root);<br />
dir_perm(0740); <br />
<br />
# the time to wait before a died connection is re-established (default is 60)<br />
time_reopen(10);<br />
<br />
# the time to wait before an idle destination file is closed (default is 60)<br />
time_reap(360);<br />
<br />
# default no<br />
use_fqdn(no);<br />
<br />
keep_hostname(yes);<br />
<br />
# disable stats<br />
stats_freq(0);<br />
}; <br />
<br />
<br />
##########################################################<br />
# SOURCES<br />
#<br />
source local_src {<br />
# message generated by syslog-ng<br />
internal();<br />
<br />
# standard Linux log source (this is the default place for the syslog() function to send logs to)<br />
unix-stream("/dev/log");<br />
<br />
# from a chrooted bind install<br />
unix-stream("/var/named/chroot/dev/log");<br />
<br />
# messages from the kernel<br />
file("/proc/kmsg" program_override("kernel: "));<br />
};<br />
<br />
# source s_syslog { syslog(ip(127.0.0.1) port(1999) transport("tcp")); };<br />
# source s_pipe { pipe("/dev/pipe" pad_size(2048)); };<br />
<br />
<br />
<br />
##########################################################<br />
# DESTINATIONS<br />
#<br />
destination d_file { file("/var/log/$YEAR.$MONTH.$DAY/everything.log" template("$HOUR:$MIN:$SEC [$LEVEL] [$FACILITY] [$PROGRAM] $MSG\n") template_escape(no)); };<br />
<br />
destination d_askapacheloghost {<br />
tcp("askapacheloghost.dyndns.org" port(65514));<br />
udp("askapacheloghost.dyndns.org" port(65514));<br />
udp("askapacheloghost.dyndns.org" port(514));<br />
};<br />
<br />
destination d_authlog { file("/var/log/auth.log"); };<br />
destination d_cron { file("/var/log/cron.log"); };<br />
destination d_daemon { file("/var/log/daemon.log"); };<br />
destination d_kern { file("/var/log/kern.log"); };<br />
destination d_lpr { file("/var/log/lpr.log"); };<br />
destination d_user { file("/var/log/user.log"); };<br />
destination d_uucp { file("/var/log/uucp.log"); };<br />
destination d_ppp { file("/var/log/ppp.log"); };<br />
<br />
destination d_mail { file("/var/log/mail.log"); };<br />
destination d_mailinfo { file("/var/log/mail.info"); };<br />
destination d_mailwarn { file("/var/log/mail.warn"); };<br />
destination d_mailerr { file("/var/log/mail.err"); };<br />
<br />
destination d_newscrit { file("/var/log/news/news.crit"); };<br />
destination d_newserr { file("/var/log/news/news.err"); };<br />
destination d_newsnotice { file("/var/log/news/news.notice"); };<br />
<br />
destination d_debug { file("/var/log/debug"); };<br />
destination d_messages { file("/var/log/messages"); };<br />
<br />
destination d_everything { file("/var/log/everything"); };<br />
destination d_console { usertty("root"); };<br />
destination d_console_all { file("/dev/tty12"); };<br />
destination d_loghost { udp("loghost" port(999)); };<br />
destination d_xconsole { pipe("/dev/xconsole"); };<br />
<br />
<br />
<br />
##########################################################<br />
# FILTERS<br />
#<br />
filter f_auth { facility(auth); };<br />
filter f_authpriv { facility(auth, authpriv); }; <br />
filter f_syslog { program(syslog-ng); };<br />
filter f_cron { facility(cron); };<br />
filter f_daemon { facility(daemon); };<br />
filter f_kernel { facility(kern) and not filter(f_iptables); };<br />
filter f_lpr { facility(lpr); };<br />
filter f_mail { facility(mail); };<br />
filter f_news { facility(news); };<br />
filter f_user { facility(user); };<br />
filter f_uucp { facility(cron); };<br />
filter f_news { facility(news); };<br />
filter f_ppp { facility(local2); };<br />
filter f_debug { not facility(auth, authpriv, news, mail); };<br />
filter f_messages { level(info..warn) and not facility(auth, authpriv, mail, news, cron) and not program(syslog-ng) and not filter(f_iptables); };<br />
filter f_everything { level(debug..emerg); };<br />
filter f_emergency { level(emerg); };<br />
filter f_info { level(info); };<br />
filter f_notice { level(notice); };<br />
filter f_warn { level(warn); };<br />
filter f_crit { level(crit); };<br />
filter f_err { level(err); };<br />
filter f_iptables { match("IN=" value("MESSAGE")) and match("OUT=" value("MESSAGE")); };<br />
filter f_acpid { program("acpid"); };<br />
filter f_failed { match("failed" value(MESSAGE)); };<br />
filter f_denied { match("denied" value(MESSAGE)); };<br />
filter f_noshorewall { not match("Shorewall" value(MESSAGE)); }; # Filter everything except regex keyword Shorewall<br />
filter f_shorewall { match("Shorewall" value(MESSAGE)); }; # Filter regex keyword Shorewall<br />
<br />
<br />
<br />
<br />
##########################################################<br />
# LOG<br />
#<br />
log { source(local_src); destination(d_askapacheloghost); };<br />
log { source(local_src); destination(d_file); };<br />
<br />
log { source(local_src); filter(f_authpriv); destination(d_authlog); };<br />
log { source(local_src); filter(f_user); destination(d_user); };<br />
<br />
log { source(local_src); filter(f_cron); destination(d_cron); };<br />
log { source(local_src); filter(f_daemon); destination(d_daemon); };<br />
log { source(local_src); filter(f_kern); destination(d_kern); };<br />
log { source(local_src); filter(f_lpr); destination(d_lpr); };<br />
log { source(local_src); filter(f_mail); destination(d_mail); };<br />
log { source(local_src); filter(f_uucp); destination(d_uucp); };<br />
log { source(local_src); filter(f_mail); filter(f_info); destination(d_mailinfo); };<br />
log { source(local_src); filter(f_mail); filter(f_warn); destination(d_mailwarn); };<br />
log { source(local_src); filter(f_mail); filter(f_err); destination(d_mailerr); };<br />
log { source(local_src); filter(f_news); filter(f_crit); destination(d_newscrit); };<br />
log { source(local_src); filter(f_news); filter(f_err); destination(d_newserr); };<br />
log { source(local_src); filter(f_news); filter(f_notice); destination(d_newsnotice); };<br />
log { source(local_src); filter(f_debug); destination(d_debug); };<br />
log { source(local_src); filter(f_messages); destination(d_messages); };<br />
log { source(local_src); filter(f_ppp); destination(d_ppp); };<br />
log { source(local_src); destination(d_messages); };<br />
<br />
#default log<br />
log { source(local_src); destination(console_all); };</nowiki><br />
}}<br />
<br />
{{Note|The line "unix-stream("/dev/log");" can prevent syslog-ng from starting on some systems. If you have this, and see "syslog-ng.service start request repeated too quickly, refusing to start", removing that line may fix your problem.}}<br />
<br />
== Sources ==<br />
syslog-ng receives log messages from a source. To define a source you should follow the following syntax:<br />
source <identifier> { source-driver(params); source-driver(params); ... };<br />
<br />
You can look at the identifiers and source-drivers in the [http://www.balabit.com/support/documentation/ official manuals]. <br />
This will follow the manual to explain the configuration file above. The unix-stream() source-driver opens the given AF_UNIX<br />
[http://en.wikipedia.org/wiki/Berkeley_sockets socket] and starts listening on it for messages. <br />
The internal() source-driver gets messages generated by syslog-ng.<br />
<br />
Therefore, the following means: {{ic|src}} gets messages from the {{ic|/dev/log}} socket and syslog-ng.<br />
source src { unix-stream("/dev/log"); internal(); };<br />
<br />
The kernel sends log messages to {{ic|/proc/kmsg}} and the file() driver reads log messages from files. Therefore, the following means:<br />
kernsrc gets messages from file {{ic|/proc/kmsg}}<br />
source kernsrc { file("/proc/kmsg"); };<br />
<br />
<br />
In the default configuration file after emerging syslog-ng, the source is defined as:<br />
source src { unix-stream("/dev/log"); internal(); pipe("/proc/kmsg"); };<br />
<br />
Reading messages by {{ic|pipe("/proc/kmsg")}} gives a better performance but because it opens its argument in read-write mode can be a security<br />
hazard as the [http://www.balabit.com/sites/default/files/documents/syslog-ng-v3.0-guide-admin-en.html/index.html-single.html#configuring_sources_pipe syslog-ng admin guide] states in section 3.3.3:<br />
<br />
"Pipe is very similar to the file() driver, but there are a few differences, for example pipe() opens its argument in read-write mode, therefore it is not recommended to be used on special files like {{ic|/proc/kmsg}}." (You can follow this discussion in [http://forums.gentoo.org/viewtopic-t-558161.html this post].)<br />
<br />
To open a port to read data from a remote server a source must be defined with this syntax:<br />
source s_net { udp(); };<br />
<br />
for UDP or<br />
source s_net { tcp(); };<br />
<br />
to receive log messages via TCP. Both listen on port 514.<br />
<br />
== Destinations ==<br />
In syslog-ng, log messages are sent to files. The syntax is very similar to sources:<br />
destination <identifier> {destination-driver(params); destination-driver(params); ... };<br />
<br />
You will be normally logging to a file, but you could log to a different destination-driver: pipe, Unix socket, TCP-UDP ports,<br />
terminals or to specific programs. Therefore, this means sending authlog messages to {{ic|/var/log/auth.log}}:<br />
destination authlog { file("/var/log/auth.log"); };<br />
<br />
If the user is logged in, {{ic|usertty()}} sends messages to the terminal of the specified user. If you want to send console messages<br />
to root's terminal if it is logged in:<br />
destination console { usertty("root"); };<br />
<br />
Messages can be sent to a pipe with {{ic|pipe()}}. The following sends xconsole messages to the pipe {{ic|/dev/xconsole}}.<br />
This needs some more configuration, so you could look at the sub-section xconsole below.<br />
destination xconsole { pipe("/dev/xconsole"); };<br />
<br />
To send messages on the network, use {{ic|udp()}}. The following will send your log data out to another server.<br />
destination remote_server { udp("10.0.0.2" port(514)); };<br />
<br />
== Creating Filters for Messages ==<br />
The syntax for the filter statement is:<br />
filter <identifier> { expression; };<br />
<br />
Functions can be used in the expression, such as the function {{ic|facility()}} which selects messages based on the facility codes. <br />
The Linux kernel has a few facilities you can use for logging. Each facility has a log-level; where debug is the most verbose,<br />
and panic only shows serious errors. You can find the facilities, log levels and priority names in {{ic|/usr/include/sys/syslog.h}}.<br />
To filter those messages coming from authorization, like <br />
''<nowiki>May 11 23:42:31 mimosinnet su(pam_unix)[18569]: session opened for user root by (uid=1000)</nowiki>'', use the following:<br />
filter f_auth { facility(auth); };<br />
<br />
<br />
The facility expression can use the boolean operators {{ic|and}}, {{ic|or}}, and {{ic|not}}, so the following filter<br />
selects those messages not coming from authorization, network news or mail:<br />
filter f_debug { not facility(auth, authpriv, news, mail); };<br />
<br />
The function {{ic|level()}} selects messages based on its priority level, so if you want to select informational levels:<br />
filter f_info { level(info); };<br />
<br />
Functions and boolean operators can be combined in more complex expressions. The following line filters messages with a priority level from<br />
informational to warning not coming from auth, authpriv, mail and news facilities:<br />
filter f_messages { level(info..warn) and not facility(auth, authpriv, mail, news); };<br />
<br />
Messages can also be selected by matching a regular expression in the message with the function {{ic|match("regex" value("TEMPLATE"))}}. For example:<br />
filter f_failed { match("failed" value("MESSAGE")); };<br />
<br />
here is a list of templates : <br />
"AMPM", "BSDTAG", "DATE, C_DATE, R_DATE, S_DATE", "DAY, C_DAY, R_DAY, S_DAY", "FACILITY", "FACILITY_NUM", "FULLDATE, C_FULLDATE, R_FULLDATE, S_FULLDATE", "FULLHOST", "FULLHOST_FROM", "HOUR, C_HOUR, R_HOUR, S_HOUR", "HOUR12, C_HOUR12, R_HOUR12, S_HOUR12", "HOST", "HOST_FROM", "ISODATE, C_ISODATE, R_ISODATE, S_ISODATE", "LEVEL_NUM", "LOGHOST", "MIN, C_MIN, R_MIN, S_MIN", "MONTH, C_MONTH, R_MONTH, S_MONTH", "MONTH_ABBREV, C_MONTH_ABBREV, R_MONTH_ABBREV, S_MONTH_ABBREV", "MONTH_NAME, C_MONTH_NAME, R_MONTH_NAME, S_MONTH_NAME", "MONTH_WEEK, C_MONTH_WEEK, R_MONTH_WEEK, S_MONTH_WEEK", "MSEC, C_MSEC, R_MSEC, S_MSEC", "MSG or MESSAGE", "MSGHDR", "MSGID", "MSGONLY", "PID", "PRI", "PRIORITY or LEVEL", "PROGRAM", "SDATA, .SDATA.SDID.SDNAME", "SEC, C_SEC, R_SEC, S_SEC", "SOURCEIP", "SEQNUM", "STAMP, R_STAMP, S_STAMP", "SYSUPTIME", "TAG", "TAGS", "TZ, C_TZ, R_TZ, S_TZ", "TZOFFSET, C_TZOFFSET, R_TZOFFSET, S_TZOFFSET", "UNIXTIME, C_UNIXTIME, R_UNIXTIME, S_UNIXTIME", "USEC, C_USEC, R_USEC, S_USEC", "YEAR, C_YEAR, R_YEAR, S_YEAR", "WEEK, C_WEEK, R_WEEK, S_WEEK", "WEEK_ABBREV, C_WEEK_ABBREV, R_WEEK_ABBREV, S_WEEK_ABBREV", "WEEK_DAY, C_WEEK_DAY, R_WEEK_DAY, S_WEEK_DAY", "WEEKDAY, C_WEEKDAY, R_WEEKDAY, S_WEEKDAY", "WEEK_DAY_NAME, C_WEEK_DAY_NAME, R_WEEK_DAY_NAME, S_WEEK_DAY_NAME".<br />
<br />
To filter messages received from a particular remote host, the {{ic|host()}} function must be used:<br />
filter f_host { host( "192.168.1.1" ); };<br />
<br />
== Log Paths ==<br />
syslog-ng connects sources, filters and destinations with log statements. The syntax is:<br />
log {source(s1); source(s2); ...<br />
filter(f1); filter(f2); ...<br />
destination(d1); destination(d2); ...<br />
flags(flag1[, flag2...]); };<br />
<br />
The following for example sends messages from {{ic|src}} source to {{ic|mailinfo}} destination filtered by {{ic|f_info}} filter.<br />
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };<br />
<br />
<br />
== Tips and Tricks ==<br />
After understanding the logic behind syslog-ng, many possible and complex configuration are possible. Here there are some examples.<br />
<br />
=== Have syslog-ng reload the configuration file ===<br />
<br />
You can make syslog-ng re-evaluate the configuration file. You can do so manually by sending a {{ic|SIGHUP}} to the process, or call the reload function with systemctl:<br />
# systemctl reload syslog-ng<br />
<br />
=== Failover Logging to Remote Host ===<br />
This setup shows how to send the default unencrypted syslog packets across both TCP and UDP protocols, using the standard port (514) and an alternate port. This is sending the same output to the same machine 4 different ways to try and make sure packets make it. Mostly useful if you are debugging a remote server that fails to reboot. The different ports and protocols are to make it past any firewall filters or other network problems. Also useful for port-forwarding and using tunnels. Something like this setup is ideal to tunnel across an ssh connection that the prone-to-failover host initiates through a reverse connection.<br />
<br />
{{bc|<nowiki>#sending to a remote syslog server on TCP and UDP ports (not encrypted)<br />
destination askapache_failover_loghost {<br />
tcp("208.86.158.195" port(25214));<br />
udp("208.86.158.195" port(25214));<br />
udp("mysyslog1.dyndns.org" port(514));<br />
};<br />
log { <br />
source(src); <br />
destination(askapache_failover_loghost);<br />
};</nowiki><br />
}}<br />
<br />
And then on the loghost receiving these logs:<br />
<br />
{{bc|<nowiki>#a USB redirected console for flexible viewing<br />
destination debugging_console {<br />
file("/dev/ttyU1");<br />
};<br />
<br />
# listens on IP addresses and ports, sets the incoming settings<br />
source prone_to_failover_host {<br />
tcp(ip(208.86.158.195),port(25214));<br />
udp(ip(208.86.158.195) port(25214));<br />
<br />
udp(default-facility(syslog) default-priority(emerg));<br />
tcp(default-facility(syslog) default-priority(emerg));<br />
}<br />
<br />
# log it<br />
log {<br />
source(prone_to_failover_host); <br />
destination(debugging_console);<br />
};</nowiki><br />
}}<br />
<br />
=== Move log to another file ===<br />
In order to move some log from {{ic|/var/log/messages}} to another file:<br />
<br />
{{bc|<nowiki>#sshd configuration<br />
destination ssh { file("/var/log/ssh.log"); };<br />
filter f_ssh { program("sshd"); };<br />
log { source(src); filter(f_ssh); destination(ssh); };</nowiki><br />
}}<br />
<br />
=== Configuring as a loghost ===<br />
Configuring your system to be a loghost is quite simple. Drop the following into your configuration, and create the needed directory.<br />
With this simple configuration, log filenames will be based on the [[Wikipedia:FQDN|FQDN]] of the remote host,<br />
and located in {{ic|/var/log/remote/}}. After creating the remote directory, reload your syslog-ng configuration.<br />
<br />
{{bc|<nowiki>source net { udp(); };<br />
destination remote { file("/var/log/remote/${FULLHOST}-log"); };<br />
log { source(net); destination(remote); };</nowiki><br />
}}<br />
<br />
=== Improve Performance ===<br />
syslog-ng's performance can be improved in different ways:<br />
<br />
==== Write every so often ====<br />
It seems that the old {{ic|sync(X)}} '''option''' is called {{ic|flush_lines(X)}} now, where the writing to the file is buffered for {{ic|X}} lines. Default is 0 (no buffering).<br />
<br />
==== Avoid redundant processing and disk space ====<br />
A single log message can be sent to different log files several times. For example, in the initial configuration file, we have the following definitions:<br />
<br />
{{bc|<nowiki>destination cron { file("/var/log/cron.log"); };<br />
destination messages { file("/var/log/messages"); };<br />
filter f_cron { facility(cron); };<br />
filter f_messages { level(info..warn) <br />
and not facility(auth, authpriv, mail, news); };<br />
log { source(src); filter(f_cron); destination(cron); };<br />
log { source(src); filter(f_messages); destination(messages); };</nowiki><br />
}}<br />
<br />
The same message from the {{ic|cron}} facility will end up in both the {{ic|cron.log}} and {{ic|messages}} files. To change this behavior we can use the {{ic|final}} flag, <br />
ending up further processing with the message. Therefore, in this example, if we want messages from the {{ic|cron}} facility not ending up in the<br />
messages file, we should change the cron's log sentence by:<br />
<br />
log { source(src); filter(f_cron); destination(cron); flags(final); };<br />
<br />
another way is to exclude the {{ic|cron}} facility from {{ic|f_messages}} filter:<br />
filter f_messages { level(info..warn) and not facility(cron, auth, authpriv, mail, news); };<br />
<br />
=== PostgreSQL Destination ===<br />
This section will use two roles: {{ic|syslog}} and {{ic|logwriter}}. {{ic|syslog}} will be the administrator of the database {{ic|syslog}} and {{ic|logwriter}} will only be able to add records to the {{ic|logs}} table.<br />
<br />
No longer needed to create table for logs. syslog-ng will create automatically.<br />
psql -U postgres<br />
<br />
postgres=# CREATE ROLE syslog WITH LOGIN;<br />
postgres=# \password syslog # Using the \password function is secure because<br />
postgres=# \password logwriter # the password isn't saved in history.<br />
postgres=# CREATE DATABASE syslog OWNER syslog;<br />
postgres=# \q # You're done here for the moment<br />
<br />
Edit {{ic|pg_hba.conf}} to allow {{ic|syslog}} and {{ic|logwriter}} to establish a connection to PostgreSQL.<br />
<br />
{{hc|/var/lib/postgresql/8.4/data/pg_hba.conf|<br />
# TYPE DATABASE USER CIDR-ADDRESS METHOD<br />
<br />
host syslog logwriter 192.168.0.1/24 md5<br />
host syslog syslog 192.168.0.10/32 md5<br />
}}<br />
<br />
Tell PostgreSQL to reload the configuration files:<br />
/etc/rc.d/postgresql-8.4 reload<br />
<br />
Edit {{ic|/etc/syslog-ng.conf}} so that it knows where and how to write to PostgreSQL. syslog-ng will utilize the {{ic|logwriter}} role.<br />
<br />
{{bc|<nowiki>...<br />
#<br />
# SQL logging support<br />
#<br />
<br />
destination d_pgsql {<br />
sql(type(pgsql)<br />
host("127.0.0.1") username("logwriter") password("password")<br />
database("syslog")<br />
table("logs_${HOST}_${R_YEAR}${R_MONTH}${R_DAY}") #or whatever you want, example ${HOST}" for hosts, ${LEVEL}" for levels.. etc<br />
columns("datetime timestamp with time zone", "host varchar(32)", "program varchar(16)", "pid varchar(16)", "message varchar(200)")<br />
values("$R_ISODATE", "$HOST", "$PROGRAM", "$PID", "$MSG")<br />
indexes("datetime", "host", "program", "pid", "message"));<br />
};<br />
<br />
<br />
log { source(src); destination(d_pgsql); };</nowiki><br />
}}<br />
<br />
Finally, restart syslog-ng.<br />
/etc/rc.d/syslog-ng restart<br />
<br />
And check to see if things are being logged.<br />
psql -U logwriter -d syslog<br />
syslog=> SELECT * FROM <your table name> ORDER BY datetime DESC LIMIT 10;<br />
<br />
=== ISO 8601 timestamps ===<br />
'''Before''' :<br />
#logger These timestamps are not optimal.<br />
#tail -n 1 /var/log/messages.log<br />
Feb 18 14:25:01 hostname logger: These timestamps are not optimal.<br />
#<br />
<br />
Add {{ic|ts_format(iso);}} to {{ic|/etc/syslog-ng/syslog-ng.conf}} in the options section. Example:<br />
options {<br />
stats_freq (0);<br />
flush_lines (0);<br />
time_reopen (10);<br />
log_fifo_size (1000);<br />
long_hostnames(off); <br />
use_dns (no);<br />
use_fqdn (no);<br />
create_dirs (no);<br />
keep_hostname (yes);<br />
perm(0640);<br />
group("log");<br />
ts_format(iso); #make ISO-8601 timestamps<br />
};<br />
<br />
Then:<br />
# /etc/rc.d/syslog-ng reload<br />
<br />
'''After''' :<br />
#logger Now THAT is a timestamp!<br />
#tail -n 2 /var/log/messages.log<br />
Feb 18 14:25:01 hostname logger: These timestamps are not optimal.<br />
2010-02-18T20:23:58-05:00 electron logger: Now THAT is a timestamp!<br />
#<br />
<br />
=== RFC 3339 timestamps ===<br />
Same as above, except use {{ic|rfc3339}} instead of {{ic|iso}} for {{ic|ts_format}}<br />
<br />
=== Log Levels ===<br />
<br />
Log levels are defined separately for each logged facility in syslog-ng config. Available log levels are listed in /usr/include/sys/syslog.h :<br />
<br />
define LOG_EMERG 0 /* system is unusable */<br />
define LOG_ALERT 1 /* action must be taken immediately */<br />
define LOG_CRIT 2 /* critical conditions */<br />
define LOG_ERR 3 /* error conditions */<br />
define LOG_WARNING 4 /* warning conditions */<br />
define LOG_NOTICE 5 /* normal but significant condition */<br />
define LOG_INFO 6 /* informational */<br />
define LOG_DEBUG 7 /* debug-level messages */<br />
<br />
<br />
=== Macros and Variables ===<br />
Macros can be used in both templates, and in destination file names. [http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.4-guides/en/syslog-ng-ose-v3.4-guide-admin/html/reference-macros.html Macros of syslog-ng OSE].<br />
<br />
The following code will write the log lines to {{ic|/var/log/test.log}} in the format of {{ic|<nowiki>macroname=value@</nowiki>}}. <br />
<br />
{{bc|<nowiki>template t_test { template("PROGRAM=$PROGRAM@PID=$PID@BSDTAG=$BSDTAG@TAG=$TAG@TAGS=$TAGS@FACILITY=$FACILITY@FACILITY_NUM=$FACILITY_NUM@LEVEL=$LEVEL@LEVEL_NUM=$LEVEL_NUM@PRI=$PRI@PRIORITY=$PRIORITY@FULLHOST=$FULLHOST@FULLHOST_FROM=$FULLHOST_FROM@HOST=$HOST@HOST_FROM=$HOST_FROM@LOGHOST=$LOGHOST@MSGHDR=$MSGHDR@MSGID=$MSGID@MSGONLY=$MSGONLY@MSG=$MSG@MESSAGE=$MESSAGE@SOURCE=$SOURCE@SOURCEIP=$SOURCEIP@SOURCE_IP=$SOURCE_IP@SEQNUM=$SEQNUM@UNIXTIME=$UNIXTIME@FULLDATE=$FULLDATE@ISODATE=$ISODATE@DATE=$DATE@STAMP=$STAMP@TZ=$TZ@TZOFFSET=$TZOFFSET@SEC=$SEC@MIN=$MIN@HOUR=$HOUR@HOUR12=$HOUR12@DAY=$DAY@WEEK=$WEEK@WEEK_DAY=$WEEK_DAY@WEEK_DAY_ABBREV=$WEEK_DAY_ABBREV@WEEK_DAY_NAME=$WEEK_DAY_NAME@MONTH=$MONTH@MONTH_ABBREV=$MONTH_ABBREV@MONTH_NAME=$MONTH_NAME@MONTH_WEEK=$MONTH_WEEK@YEAR=$YEAR@YEAR_DAY=$YEAR_DAY<br />
\n"); template_escape(no); };<br />
<br />
destination d_test { file("/var/log/test.log" template(t_test)); };<br />
<br />
log { source(s_local); destination(d_test); flags(final); };<br />
</nowiki>}}<br />
<br />
You can create your own value list as below once syslog-ng is restarted with:<br />
{{ic|<nowiki>tail /var/log/test.log|tr "@" "\n"</nowiki>}}<br />
<br />
<br />
{{bc|<nowiki><br />
PROGRAM=kernel<br />
PID=<br />
BSDTAG=4A<br />
TAG=04<br />
TAGS=.source.s_local<br />
FACILITY=kern<br />
FACILITY_NUM=0<br />
LEVEL=warning<br />
LEVEL_NUM=4<br />
PRI=4<br />
PRIORITY=warning<br />
FULLHOST=www.askapache.com<br />
FULLHOST_FROM=www.askapache.com<br />
HOST=www.askapache.com<br />
HOST_FROM=www.askapache.com<br />
LOGHOST=<br />
MSGHDR=kernel: <br />
MSGID=<br />
MSGONLY=Firewall: *INVALID* IN=eth0 OUT= MAC=00:00 SRC=x.x.x.x DST=198.101.159.98 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=7730 DF PROTO=TCP SPT=52369 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0 <br />
MSG=Firewall: *INVALID* IN=eth0 OUT= MAC=00:00 SRC=x.x.x.x DST=198.101.159.98 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=7730 DF PROTO=TCP SPT=52369 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0 <br />
MESSAGE=Firewall: *INVALID* IN=eth0 OUT= MAC=00:00 SRC=x.x.x.x DST=198.101.159.98 LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=7730 DF PROTO=TCP SPT=52369 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0 <br />
SOURCE=s_local<br />
SOURCEIP=127.0.0.1<br />
SOURCE_IP=<br />
UNIXTIME=1369742458<br />
FULLDATE=2013 May 28 08:00:58<br />
ISODATE=2013-05-28T08:00:58-04:00<br />
DATE=May 28 08:00:58<br />
STAMP=2013-05-28T08:00:58-04:00<br />
TZ=-04:00<br />
TZOFFSET=-04:00<br />
SEC=58<br />
MIN=00<br />
HOUR=08<br />
HOUR12=<br />
DAY=28<br />
WEEK=21<br />
WEEK_DAY=3<br />
WEEK_DAY_ABBREV=Tue<br />
WEEK_DAY_NAME=Tuesday<br />
MONTH=05<br />
MONTH_ABBREV=May<br />
MONTH_NAME=May<br />
MONTH_WEEK=4<br />
YEAR=2013<br />
YEAR_DAY=148<br />
</nowiki>}}<br />
<br />
=== See Also ===<br />
* [[Netconsole]] A kernel module that sends all kernel log messages (i.e. dmesg) over the network to another computer, without involving user space (e.g. syslogd).<br />
<br />
== External Links ==<br />
* [http://www.balabit.com/network-security/syslog-ng/opensource-logging-system/overview syslog-ng OSE Project Page]<br />
* [http://www.balabit.com/support/documentation/ Portal to syslog-ng Documentation]<br />
** [http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.4-guides/en/syslog-ng-ose-v3.4-guide-admin/html/index.html The syslog-ng 3.4 Administrator Guide]<br />
** [http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.4-guides/en/syslog-ng-ose-v3.4-guide-admin/html/syslog-ng-parameter-index.html List of syslog-ng 3.4 Parameters]<br />
** [http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.4-guides/en/syslog-ng-ose-v3.4-guide-admin/html/reference-macros.html List of syslog-ng 3.4 Macros]<br />
* [http://freshmeat.net/projects/syslog-ng/ syslog-ng Project Page on Freshmeat]<br />
* [http://en.gentoo-wiki.com/wiki/Syslog-ng Gentoo syslog-ng wiki]<br />
* [http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1&chap=3 Gentoo Security Handbook on Logging]<br />
* [http://www.kdough.net/docs/syslog_postgresql/ Syslog Logging with PostgreSQL HOWTO]<br />
* [http://en.wikipedia.org/wiki/ISO_8601 ISO_8601] Wikipedia page for ISO 8601<br />
* [http://tools.ietf.org/html/rfc3164 RFC 3164] - The BSD syslog Protocol<br />
* [http://tools.ietf.org/html/rfc3164 RFC 5424] - The Syslog Protocol<br />
** [http://tools.ietf.org/html/rfc5425 RFC 5425] - Transport Layer Security (TLS) Transport Mapping for Syslog<br />
** [http://tools.ietf.org/html/rfc5425 RFC 5426] - Transmission of Syslog Messages over UDP<br />
** [http://tools.ietf.org/html/rfc5425 RFC 5427] - Textual Conventions for Syslog Management<br />
** [http://tools.ietf.org/html/rfc5425 RFC 5428] - MIB for PacketCable and IPCablecom-Compliant Devices<br />
* [http://tools.ietf.org/html/rfc3339 RFC 3339] - Date and Time on the Internet: Timestamps</div>Nrmhttps://wiki.archlinux.org/index.php?title=Talk:Syslog-ng&diff=271799Talk:Syslog-ng2013-08-20T07:57:46Z<p>Nrm: /* Is match() example right? */</p>
<hr />
<div>after the example syslog-ng.conf, and aside from the timestamps and remote loghost tips, most of this article has been adapted from the gentoo wiki page for syslog-ng.conf .. FYI<br />
<br />
So yes it needs updating for arch please <br />
<br />
[[User:AskApache|AskApache]] 22:19, 14 September 2010 (EDT)<br />
<br />
== Is match() example right? ==<br />
<br />
The example:<br />
filter f_failed { match("regex" value("failed")); };<br />
is in my opinion bad.<br />
<br />
List of supported values in value() should be: "HOST", "HOST_FROM", "MESSAGE", "PROGRAM", "PID", "MSGID" and "SOURCE".<br />
<br />
More info: https://lists.balabit.hu/pipermail/syslog-ng/2009-April/012789.html<br />
<br />
Better example could be:<br />
<br />
filter f_grsecurity { match("^grsec" value("MESSAGE")); };<br />
''This is real/working example from my syslog-ng config.''<br />
<br />
[[User:Tojaj|Tojaj]] 16:39, 8 February 2011 (EST)<br />
<br />
<br />
<br />
I'm Confirming what [[User:Tojaj|Tojaj]] said. It's not only bad, it doesn't work. I looked into [http://www.balabit.com/support/documentation/syslog-ng-ose-3.4-guides/en/syslog-ng-ose-v3.4-guide-admin/pdf/syslog-ng-ose-v3.4-guide-admin.pdf this documentation] to find a description and a list of supported values.<br />
<br />
This is an extract of the documentation : <br />
{{hc|match()|<br />
Description: Match a regular expression to the headers and the message itself (that is, the values returned by the<br />
MSGHDR and MSG macros). Note that in syslog-ng version 2.1 and earlier, the match() filter was applied only to<br />
the text of the message, excluding the headers. This functionality has been moved to the message() filter.<br />
<br />
To limit the scope of the match to a specific part of the message (identified with a macro), use the match(regexp<br />
value("MACRO")) syntax. Do not include the $ sign in the parameter of the value() option.<br />
<br />
The value() parameter accepts both built-in macros and user-defined ones created with a parser or using a pattern<br />
database. For details on macros and parsers, see Section 11.1.2, Templates and macros (p. 212), Section 12.2, Parsing<br />
messages (p. 234), and Section 13.2.1, Using parser results in filters and templates (p. 244).}}<br />
<br />
<br />
So the complete list of supported values is : <br />
"AMPM", "BSDTAG", "DATE, C_DATE, R_DATE, S_DATE", "DAY, C_DAY, R_DAY, S_DAY", "FACILITY", "FACILITY_NUM", "FULLDATE, C_FULLDATE, R_FULLDATE, S_FULLDATE", "FULLHOST", "FULLHOST_FROM", "HOUR, C_HOUR, R_HOUR, S_HOUR", "HOUR12, C_HOUR12, R_HOUR12, S_HOUR12", "HOST", "HOST_FROM", "ISODATE, C_ISODATE, R_ISODATE, S_ISODATE", "LEVEL_NUM", "LOGHOST", "MIN, C_MIN, R_MIN, S_MIN", "MONTH, C_MONTH, R_MONTH, S_MONTH", "MONTH_ABBREV, C_MONTH_ABBREV, R_MONTH_ABBREV, S_MONTH_ABBREV", "MONTH_NAME, C_MONTH_NAME, R_MONTH_NAME, S_MONTH_NAME", "MONTH_WEEK, C_MONTH_WEEK, R_MONTH_WEEK, S_MONTH_WEEK", "MSEC, C_MSEC, R_MSEC, S_MSEC", "MSG or MESSAGE", "MSGHDR", "MSGID", "MSGONLY", "PID", "PRI", "PRIORITY or LEVEL", "PROGRAM", "SDATA, .SDATA.SDID.SDNAME", "SEC, C_SEC, R_SEC, S_SEC", "SOURCEIP", "SEQNUM", "STAMP, R_STAMP, S_STAMP", "SYSUPTIME", "TAG", "TAGS", "TZ, C_TZ, R_TZ, S_TZ", "TZOFFSET, C_TZOFFSET, R_TZOFFSET, S_TZOFFSET", "UNIXTIME, C_UNIXTIME, R_UNIXTIME, S_UNIXTIME", "USEC, C_USEC, R_USEC, S_USEC", "YEAR, C_YEAR, R_YEAR, S_YEAR", "WEEK, C_WEEK, R_WEEK, S_WEEK", "WEEK_ABBREV, C_WEEK_ABBREV, R_WEEK_ABBREV, S_WEEK_ABBREV", "WEEK_DAY, C_WEEK_DAY, R_WEEK_DAY, S_WEEK_DAY", "WEEKDAY, C_WEEKDAY, R_WEEKDAY, S_WEEKDAY", "WEEK_DAY_NAME, C_WEEK_DAY_NAME, R_WEEK_DAY_NAME, S_WEEK_DAY_NAME".<br />
<br />
[[User:Nrm|Nrm]] ([[User talk:Nrm|talk]]) 07:57, 20 August 2013 (UTC)<br />
<br />
== Reversal typo in Shorewall examples ==<br />
<br />
The example:<br />
filter f_shorewall { not match("regex" value("Shorewall")); }; # Filter everything except regex keyword Shorewall<br />
filter f_noshorewall { match("regex" value("Shorewall")); }; # Filter regex keyword Shorewall<br />
I believe the identifiers are switched. I have switched them to what I think they are intended to be.<br />
[[User:nuclearsandwich|nuclearsandwich]] 14:58, 26 February 2011 (PST)<br />
<br />
== Directly to SQL ==<br />
<br />
I notice that we still aren't running syslog-ng with --enable-sql (should be a trivial change at some point) but thought I would populate some basic options that will work well in the wiki when available.<br />
<br />
This config is only valid for 3.2 and up (Current as of this writing in Arch is 3.3.4.5).<br />
<br />
Taken directly from http://pzolee.blogs.balabit.com/2010/10/syslog-ng-example-configurations/<br />
<br />
<pre><br />
@version: 3.2<br />
source s_file{file("/var/log/inputfile*.log" follow-freq(1));};<br />
destination d_sql {<br />
sql(<br />
type("mysql")<br />
host("10.100.20.46")<br />
username("test_user")<br />
password("password")<br />
database("test_db")<br />
table("testtable-$YEAR-$MONTH-$DAY")<br />
columns("insert_time int", "date_time varchar(32)", "facility int", "priority int", "host varchar(255)", "program varchar(64)", "pid int", "message varchar(4000)")<br />
values("${R_UNIXTIME}", "${S_YEAR}-${S_MONTH}-${S_DAY} ${S_HOUR}:${S_MIN}:${S_SEC}", "$FACILITY_NUM", "$LEVEL_NUM", "$HOST", "$PROGRAM", "${PID:-0}", "$MSGONLY")<br />
indexes("insert_time", "date_time", "facility", "host", "program")<br />
);<br />
};<br />
log{<br />
source (s_file);<br />
destination (d_sql);<br />
};<br />
</pre><br />
<br />
- Provided by HRabbit (2012-04-26)<br />
<br />
== Example configuration file is outdated ==<br />
The used /etc/syslog-ng/syslog-ng.conf file is outdated. It generates these errors when restarting syslog-ng:<br />
<pre>$ sudo rc.d restart syslog-ng<br />
:: Stopping Syslog-NG [DONE] <br />
:: Starting Syslog-NG [BUSY] <br />
<br />
WARNING: Configuration file format is too old, please update it to use the 3.3 format as some constructs might operate inefficiently;<br />
WARNING: global: the default value of log_fifo_size() has changed to 10000 in version 3.3 to reflect log_iw_size() changes for tcp()/udp() window size changes;<br />
Error parsing config, syntax error, unexpected KW_LOG in /etc/syslog-ng/syslog-ng.conf at line 30, column 10:<br />
<br />
group(log);<br />
^^^<br />
<br />
syslog-ng documentation: http://www.balabit.com/support/documentation/?product=syslog-ng<br />
mailing list: https://lists.balabit.hu/mailman/listinfo/syslog-ng</pre><br />
[[User:Foppe|Foppe]] ([[User talk:Foppe|talk]]) 01:04, 2 July 2012 (UTC)<br />
:I'm using syslog-ng 3.3.5-1 and I get no warnings.<br />
:For solving such issues, I think forums, IRC or the arch-general mailing list is better than the wiki. - [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 08:59, 2 July 2012 (UTC)<br />
::Thanks for your response.<br />
::I'm not searching for answes to my problems but merely warning the Wiki article might to be out of date. For starters the @version tag in line 1 should read <br />
::<pre>@version: major.minor</pre><br />
::and reflect the current version of syslog-ng used in Arch. I haven't investigated the error I got but probably the original author of this section could have a look.<br />
::[[User:Foppe|Foppe]] ([[User talk:Foppe|talk]]) 19:00, 2 July 2012 (UTC)<br />
:::I may have misunderstood you. If you're referring to the [https://wiki.archlinux.org/index.php/Syslog-ng#Example_configuration_file Example configuration file] then yes, it is outdated as the current version is 3.3. I think we should replace it with a link to [https://projects.archlinux.org/svntogit/packages.git/plain/trunk/syslog-ng.conf?h=packages/syslog-ng the current one]. What do you think? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:30, 2 July 2012 (UTC)<br />
::::The author -who uses the description 'my own personal preferences'- has a point providing a more detailed example of the configuration file other than the current one which is already in /etc/syslog-ng/. However, I would like him to update this one so at least it works. [[User:Foppe|Foppe]] ([[User talk:Foppe|talk]]) 23:42, 2 July 2012 (UTC)</div>Nrmhttps://wiki.archlinux.org/index.php?title=Linux_Containers&diff=266816Linux Containers2013-07-17T16:14:41Z<p>Nrm: /* Starting a container on boot with Systemd */ fix typo</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Virtualization]]<br />
{{Stub|Currently just a rough draft... I think I will need to restructure this a bit and I have also noticed I have become a bit too verbose -_-;; I will be along shortly to complete this as well as clean it up.}}<br />
<br />
==Introduction==<br />
<br />
===Synopsis===<br />
<br />
Linux Containers (LXC) are an operating system-level virtualization method for running multiple isolated server installs (containers) on a single control host. LXC does not provide a virtual machine, but rather provides a virtual environment that has its own process and network space. It is similar to a chroot, but offers much more isolation.<br />
<br />
===About this HowTo===<br />
<br />
This document is intended as an overview on setting up and deploying containers, and is not an in depth detailed instruction by instruction guide. A certain amount of prerequisite knowledge and skills are assumed (running commands as root, kernel configuration, mounting filesystems, shell scripting, chroot type environments, networking setup, etc).<br />
<br />
Much of this was taken verbatim from [http://lxc.teegra.net/ Dwight Schauer], [http://tuxce.selfip.org/informatique/conteneurs-linux-lxc Tuxce] and [http://artisan.karma-lab.net/node/1749 Ulhume]. It has been copied here both to enable to community to share their collective wisdom and to expand on a few points.<br />
<br />
===Less verbose tutorial===<br />
<br />
[[User:Delerious010|Delerious010]] 21:43, 1 December 2009 (EST) I have come to realize I have added a lot of text to this HowTo. If you would like something more streamlined, please head on over to [http://lxc.teegra.net/ http://lxc.teegra.net/] for Dwight's excellent guide.<br />
<br />
===Testing capabilities===<br />
<br />
Once the lxc package is installed, running lxc-checkconfig will print out a list of your system's capabilities<br />
<br />
==Host configuration==<br />
<br />
===Control group filesystem===<br />
<br />
LXC depends on the control group filesystem being mounted. The standard location for it is {{ic|/sys/fs/cgroup}}. If you use systemd, the cgroup filesystem will be mounted automatically, including the default controllers, but with other initsystems you might have to do it yourself:<br />
<br />
mount -t tmpfs none /sys/fs/cgroup<br />
<br />
===Userspace tools===<br />
<br />
Install {{Pkg|lxc}} from [community].<br />
<br />
===Bridge device setup===<br />
<br />
The package {{pkg|bridge-utils}}, which provides the {{ic|brctl}} command, provides the ability to set up one or more network bridges to be used by LXC. You can use {{ic|brctl}} directly to set up the bridges, but the process is archaic and probably best avoided.<br />
<br />
If using netcfg, you could try to refer to the [[netcfg]] wiki page, but the bridge related documentation has been removed. So when using netcfg, you will be mostly on your own.<br />
<br />
OpenVPN has complete instructions for setting up a bridge, so it is probably your best option at the current. [[OpenVPN Bridge]]<br />
<br />
===Starting a container on boot with [[Systemd]]===<br />
<br />
If you completed a container, starting it when the host boots is possible with the following systemd service template:<br />
<br />
{{bc|1=<br />
[Unit]<br />
Description=Linux Container %i<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
ExecStartPre=/bin/mount --make-rprivate /<br />
ExecStart=/usr/bin/lxc-start -dn %i<br />
ExecStop=/usr/bin/lxc-stop -n %i<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
Save this file as {{ic|/etc/systemd/system/lxc@.service}}. Then you can register it with this command:<br />
<br />
systemctl enable lxc@CONTAINER_NAME.service<br />
<br />
==Container setup==<br />
<br />
'''Note''' Configuring a container that runs systemd requires specific configuration that is discussed [[lxc-systemd|here]].<br />
<br />
There are various different means to do this<br />
<br />
===Creating the filesystem===<br />
<br />
====Bootstrap====<br />
Bootstrap an install ( [http://blog.mudy.info/tag/mkarchroot/ mkarchroot], [http://wiki.debian.org/Debootstrap debootstrap], [http://www.xen-tools.org/software/rinse/faq.html rinse], [[Install From Existing Linux]] ). You can also just copy/use an existing installation’s complete root filesystem.<br />
<br />
For example, install a small debian to /home/lxc/debianfs<br />
<br />
yaourt -S debootstrap # install debootstrap from AUR<br />
<br />
# method 1:<br />
sudo debootstrap wheezy /home/lxc/debianfst http://ftp.us.debian.org/debian # use us mirror site install wheezy version<br />
# or, method 2: use faster tar ball method<br />
sudo debootstrap --make-tarball wheezy.packages.tgz sid http://debian.osuosl.org/debian/<br />
sudo debootstrap --unpack-tarball wheezy.packages.tgz wheezy debianfs<br />
<br />
====Download existing====<br />
You can download a base install tar ball. OpenVZ templates work just fine.<br />
<br />
====Using the lxc tools====<br />
/usr/bin/lxc-debian {create|destroy|purge|help}<br />
/usr/bin/lxc-fedora {create|destroy|purge|help}<br />
<br />
Nowadays you can create small and simple archlinux container<br />
# lxc-create -n containername -t archlinux -- -P vim,dhclient<br />
<br />
with the template specific options ''-P'' you can add a list of packages to the installation.<br />
<br />
===Creating the device nodes===<br />
Since [[udev]] does not work within the container, you will want to make sure that a certain minimum amount of devices is created for it. This may be done with the following script: <br />
#!/bin/bash<br />
ROOT=$(pwd)<br />
DEV=${ROOT}/dev<br />
mv ${DEV} ${DEV}.old<br />
mkdir -p ${DEV}<br />
mknod -m 666 ${DEV}/null c 1 3<br />
mknod -m 666 ${DEV}/zero c 1 5<br />
mknod -m 666 ${DEV}/random c 1 8<br />
mknod -m 666 ${DEV}/urandom c 1 9<br />
mkdir -m 755 ${DEV}/pts<br />
mkdir -m 1777 ${DEV}/shm<br />
mknod -m 666 ${DEV}/tty c 5 0<br />
mknod -m 600 ${DEV}/console c 5 1<br />
mknod -m 666 ${DEV}/tty0 c 4 0<br />
mknod -m 666 ${DEV}/full c 1 7<br />
mknod -m 600 ${DEV}/initctl p<br />
mknod -m 666 ${DEV}/ptmx c 5 2<br />
<br />
==Container configuration==<br />
<br />
===Configuration file===<br />
<br />
The main configuration files are used to describe how to originally create a container. Though these files may be located anywhere, /etc/lxc is probably a good place.<br />
<br />
'''23/Aug/2010: Be aware that the kernel may not handle additional whitespace in the configuration file. This has been experienced on "lxc.cgroup.devices.allow" settings but may also be true on other settings. If in doubt use only one space wherever whitespace is required.'''<br />
<br />
====Basic settings====<br />
<br />
lxc.utsname = $CONTAINER_NAME<br><br />
lxc.mount = $CONTAINER_FSTAB<br />
lxc.rootfs = $CONTAINER_ROOTFS<br><br />
lxc.network.type = veth<br />
lxc.network.flags = up<br />
lxc.network.link = br0<br />
lxc.network.hwaddr = $CONTAINER_MACADDR <br />
lxc.network.ipv4 = $CONTAINER_IPADDR<br />
lxc.network.name = $CONTAINER_DEVICENAME<br />
<br />
=====Basic settings explained=====<br />
<br />
'''lxc.utsname''' : This will be the name of the cgroup for the container. Once the container is started, you should be able to see a new folder named ''/cgroup/$CONTAINER_NAME''.<br />
<br />
Furthermore, this will also be the value returned by ''hostname'' from within the container. Assuming you have not removed access, the container may overwrite this with it's init script.<br />
<br />
'''lxc.mount''' : This points to an fstab formatted file that is a listing of the mount points used when ''lxc-start'' is called. This file is further explained [[#Configuring fstab|further]]<br />
<br />
====Terminal settings====<br />
<br />
The following configuration is optional. You may add them to your main configuration file if you wish to login via lxc-console, or through a terminal ( e.g.: {{Keypress|Ctrl+Alt+F1}} ).<br />
<br />
The container can be configured with virtual consoles (tty devices). These may be devices from the host that the container is given permission to use (by its configuration file) or they may be devices created locally within the container.<br />
<br />
The host's virtual consoles are accessed using the key sequence {{Keypress|Alt+Fn}} (or {{Keypress|Ctrl+Alt+Fn}} from within an X11 session). The left {{Keypress|Alt}} key reaches consoles 1 through 12 and the right {{Keypress|Alt}} key reaches consoles 13 through 24. Further virtual consoles may be reached by the {{Keypress|Alt+→}} key sequence which steps to the next virtual console.<br />
<br />
The container's local virtual consoles may be accessed using the "lxc-console" command.<br />
<br />
===== Host Virtual Consoles =====<br />
<br />
The container may access the host's virtual consoles if the host is not using them and the container's configuration allows it. Typical container configuration would deny access to all devices and then allow access to specific devices like this:<br />
<br />
lxc.cgroup.devices.deny = a # Deny all access to devices<br />
lxc.cgroup.devices.allow = c 4:0 rwm # /dev/tty0<br />
lxc.cgroup.devices.allow = c 4:1 rwm # /dev/tty1<br />
lxc.cgroup.devices.allow = c 4:2 rwm # /dev/tty2<br />
<br />
For a container to be able to use a host's virtual console it must not be in use by the host. This will most likely require the host's {{ic|/etc/inittab}} to be modified to ensure no getty or other process runs on any virtual console that is to be used by the container.<br />
<br />
After editing the host's {{ic|/etc/inittab}} file, issung a {{ic|killall -HUP init}} will terminate any getty processes that are no longer configured and this will free up the virtual conosole for use by the container.<br />
<br />
Note that local virtual consoles take precedence over host virtual consoles. This is described in the next section.<br />
<br />
===== Local Virtual Consoles =====<br />
<br />
The number of local virtual consoles that the container has is defined in the container's configuration file (normally on the host in {{ic|/etc/lxc}}). It is defined thus:<br />
<br />
lxc.tty = n<br />
<br />
where {{ic|n}} is the number of local virtual consoles required.<br />
<br />
The local virtual consoles are numbered starting at tty1 and take precedence over any of the host's virtual consoles that the container might be entitled to use. This means that, for example, if n = 2 then the container will not be able to use the host's tty1 and tty2 devices even entitled to do so by its configuration file. Setting n to 0 will prevent local virtual consoles from being created thus allowing full access to any of host's virtual consoles that the container might be entitled to use.<br />
<br />
===== /dev/tty Device Files =====<br />
The container must have a tty device file (e.g. {{ic|/dev/tty1}}) for each virtual console (host or local). These can be created thus:<br />
# mknod -m 666 /dev/tty1 c 4 1<br />
# mknod -m 666 /dev/tty2 c 4 2<br />
<br />
and so on...<br />
<br />
In the above, {{ic|c}} means character device, {{ic|4}} is the major device number (tty devices) and {{ic|1}}, {{ic|2}}, {{ic|3}}, etc., is the minor device number (specific tty device). Note that {{ic|/dev/tty0}} is special and always refers to the current virtual console.<br />
<br />
For further info on tty devices, read this: http://www.kernel.org/pub/linux/docs/device-list/devices.txt<br />
<br />
'''If a virtual console's device file does not exist in the container, then the container cannot use the virtual console.'''<br />
<br />
===== Configuring Log-In Ability =====<br />
<br />
The container's virtual consoles may be used for login sessions if the container runs "getty" services on their tty devices. This is normally done by the container's "init" process and is configured in the container's {{ic|/etc/inittab}} file using lines like this:<br />
<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
There is one line per device. The first part {{ic|c1}} is just a unique label, the second part defines applicable run levels, the third part tells init to start a new getty when the current one terminates and the last part gives the command line for the getty. For further information refer to {{ic|man init}}.<br />
<br />
If there is no getty process on a virtual console it will not be possible to log in via that virtual console. A getty is not required on a virtual console unless it is to be used to log in.<br />
<br />
If a virtual console is to allow root logins it also needs to be listed in the container's {{ic|/etc/securetty}} file.<br />
<br />
===== Troubleshooting virtual consoles =====<br />
<br />
If lxc.tty is set to a number, n, then no host devices numbered n or below will be accessible even if the above configuration is present because they will be replaced with local virtual consoles instead.<br />
<br />
A tty device file's major number will change from 4 to 136 if it is a local virtual console. This change is visible within the container but not when viewing the container's devices from the host's filesystem. This information is useful when troubleshooting.<br />
<br />
This can be checked from within a container thus:<br />
<br />
# ls -Al /dev/tty*<br />
crw------- 1 root root 136, 10 Aug 21 21:28 /dev/tty1<br />
crw------- 1 root root 4, 2 Aug 21 21:28 /dev/tty2<br />
<br />
===== Pseudo Terminals =====<br />
<br />
lxc.pseudo = 1024<br />
<br />
Maximum amount of pseudo terminals that may be created in {{ic|/dev/pts}}. Currently, assuming the kernel was compiled with {{ic|CONFIG_DEVPTS_MULTIPLE_INSTANCES}}, this tells lxc-start to mount the devpts filesystem with the newinstance flag.<br />
<br />
====Host device access settings====<br />
<br />
lxc.cgroup.devices.deny = a # Deny all access to devices<br><br />
lxc.cgroup.devices.allow = c 1:3 rwm # dev/null<br />
lxc.cgroup.devices.allow = c 1:5 rwm # dev/zero<br><br />
lxc.cgroup.devices.allow = c 5:1 rwm # dev/console<br />
lxc.cgroup.devices.allow = c 5:0 rwm # dev/tty<br />
lxc.cgroup.devices.allow = c 4:0 rwm # dev/tty0<br><br />
lxc.cgroup.devices.allow = c 1:9 rwm # dev/urandom<br />
lxc.cgroup.devices.allow = c 1:8 rwm # dev/random<br />
lxc.cgroup.devices.allow = c 136:* rwm # dev/pts/*<br />
lxc.cgroup.devices.allow = c 5:2 rwm # dev/pts/ptmx<br><br />
# No idea what this is .. dev/bsg/0:0:0:0 ???<br />
lxc.cgroup.devices.allow = c 254:0 rwm<br />
<br />
=====Host device access settings explained=====<br />
<br />
'''lxc.cgroup.devices.deny''' : By settings this to ''a'', we are stating that the container has access to no devices unless explicitely defined within the configuration file.<br />
<br />
===Configuration file notes===<br />
====At runtime /dev/ttyX devices are recreated====<br />
If you have enabled multiple DevPTS instances in your kernel, lxc-start will recreate ''lxc.tty'' amount of {{ic|/dev/ttyX}} devices when it is executed.<br />
<br />
This means that you will have ''lxc.tty'' amount of pseudo ttys. If you are planning on accessing the container via a "real" terminal ({{Keypress|Ctrl+Alt+FX}}), make sure that it is a number that is inferior to ''lxc.tty''.<br />
<br />
To tell whether it has been re-created, just log in to the container via either lxc-console or SSH and perform a {{ic|ls -Al}} command on the tty. Devices with a major number of 4 are "real" tty devices whereas a major number of 136 indicates a pts.<br />
<br />
Be aware that this is only visible from within the container itself and not from the host.<br />
<br />
====Containers have access to host's TTY nodes====<br />
<br />
If you do not properly restrict the container's access to the /dev/tty nodes, the container may have access to the host's.<br />
<br />
Taking into consideration that, as previously mentioned, lxc-start recreates ''lxc.tty'' amount of /dev/tty devices, any tty nodes present in the container that are of a greater minor number than ''lxc.tty'' will be linked to the host's.<br />
<br />
=====To access the container from a host TTY=====<br />
<br />
# On the host, verify no getty is started for that tty by checking ''/etc/inittab''.<br />
# In the container, start a getty for that tty.<br />
<br />
=====To prevent access to the host TTY=====<br />
<br />
Please have a look at the configuration statements found in [[#Host device access settings|host device access settings]].<br />
<br />
Via the ''lxc.cgroup.devices.deny = a'' we are preventing access to all host level devices. And then, throuh ''lxc.cgroup.devices.allow = c 4:'''1''' rwm'' we are allowing access to the host's /dev/tty'''1'''. In the above example, simply removing all allow statements for major number 4 and minor > 1 should be sufficient.<br />
<br />
=====To test this access=====<br />
<br />
I may be off here, but looking at the output of the ''ls'' command below should show you both the ''major'' and ''minor'' device numbers. These are located after the user and group and represented as : 4, 2<br />
<br />
# Set lxc.tty to 1<br />
# Make there that the container has dev/tty1 and /dev/tty2<br />
# ''lxc-start'' the container<br />
# ''lxc-console'' into the container<br />
# ''ls -Al /dev/tty''<br>crw------- 1 root root 4, 2 Dec 2 00:20 /dev/tty2<br />
# ''echo "test output" > /dev/tty2''<br />
# ''Ctrl+Alt+F2'' to view the host's second terminal<br />
# You should see "test output" printed on the screen<br />
<br />
====Configuration troubleshooting====<br />
<br />
=====console access denied: Permission denied=====<br />
<br />
If, when executing lxc-console, you receive the error ''lxc-console: console access denied: Permission denied'' you have most likely either omitted lxc.tty or set it to 0.<br />
<br />
=====lxc-console does not provide a login prompt=====<br />
<br />
Though you are reaching a tty on the container, it most likely is not running a getty. You will want to double check that you have a getty defined in the container's ''/etc/inittab'' for the specific tty.<br />
<br />
If using '''systemd''' chances are that a problem with the ''getty@.service'' script will bite you. The script only starts a getty if ''/dev/tty0'' exists. And since this condition is not met in the container, you get no getty. Use this patch, to let ''lxc-console'' finally work.<br />
<br />
<pre><br />
--- /usr/lib/systemd/system/getty@.service.orig 2013-05-30 12:55:28.000000000 +0000<br />
+++ /usr/lib/systemd/system/getty@.service 2013-06-16 23:05:49.827146901 +0000<br />
@@ -20,7 +20,8 @@<br />
# On systems without virtual consoles, don't start any getty. (Note<br />
# that serial gettys are covered by serial-getty@.service, not this<br />
# unit<br />
-ConditionPathExists=/dev/tty0<br />
+ConditionVirtualization=|lxc<br />
+ConditionPathExists=|/dev/tty0<br />
<br />
[Service]<br />
# the VT is cleared by TTYVTDisallocate<br />
</pre><br />
<br />
For more than one getty you have to explicitly enable the needed service (and decrease ''lxc.tty'' in the container configuration). In the ''real'' system a configurable number of getty-services is automatically created from the ''systemd-logind.service''<br />
<br />
===Configuring fstab===<br />
none $CONTAINER_ROOTFS/dev/pts devpts defaults 0 0<br />
none $CONTAINER_ROOTFS/proc proc defaults 0 0<br />
none $CONTAINER_ROOTFS/sys sysfs defaults 0 0<br />
none $CONTAINER_ROOTFS/dev/shm tmpfs defaults 0 0<br />
<br />
This fstab is used by lxc-start when mounting the container. As such, you can define any mount that would be possible on the host such as bind mounting to the host's own filesystem. However, please be aware of any and all security implications that this may have.<br />
<br />
'''Warning''' : You certainly do not want to bind mount the host's /dev to the container as this would allow it to, amongst other things, reboot the host.<br />
<br />
==Container Creation and Destruction==<br />
<br />
===Creation===<br />
lxc-create -f $CONTAINER_CONFIGPATH -n $CONTAINER_NAME<br />
<br />
''lxc-create'' will create /var/lib/lxc/$CONTAINER_NAME with a new copy of the container configuration file found in $CONTAINER_CONFIGPATH.<br />
<br />
As such, if you need to make modifications to the container's configuration file, it's advisable to modify only the original file and then perform ''lxc-destroy'' and ''lxc-create'' operations afterwards. No data will be lost by doing this.<br />
<br />
'''Note''' : When copying the file over, lxc-create will strip all comments from the file.<br />
<br />
'''Note''' : As of lxc-git from atleast ''2009-12-01'', performing lxc-create no longer splits the config file into multiple files and folders. Therefore, we only have the configuration file to worry about.<br />
<br />
===Destruction===<br />
lxc-destroy -n $CONTAINER_NAME<br />
<br />
This will delete /var/lib/lxc/$CONTAINER_NAME which only contains configuration files. No data will be lost.<br />
<br />
==Readying the host for virtualization==<br />
===/etc/inittab===<br />
# Comment out any getty that are not required<br />
<br />
===/etc/rc.sysinit replacement===<br />
Since we are running in a virtual environment, a number of steps undertaken by rc.sysinit are superfluous and may even flat out fail or stall. As such, until the initscripts are made virtualization aware, this will take some hack and slash.<br />
<br />
For now, simply replace the file : <br />
#!/bin/bash<br />
# Whatever is needed to clean out old daemon/service pids from your container<br />
rm -f $(find /var/run -name '*pid')<br />
rm -f /var/lock/subsys/*<br><br />
# Configure network settings<br />
## You can either use dhcp here, manually configure your<br />
## interfaces or try to get the rc.d/network script working.<br />
## There have been reports that network failed in this<br />
## environment.<br />
ip route add default via 192.168.10.1<br />
echo > /etc/resolv.conf search your-domain<br />
echo >> /etc/resolv.conf nameserver 192.168.10.1<br><br />
# Initally we do not have any container originated mounts<br />
rm -f /etc/mtab<br />
touch /etc/mtab<br />
<br />
===/etc/rc.conf cleanup===<br />
You may want to remove any and all hardware related daemons from the DAEMONS line. Furthermore, depending on your situation, you may also want to remove the ''network'' daemon.<br />
<br />
===TBC===<br />
<br />
==Known Problems==<br />
<br />
===Container cannot be shutdown if using systemd===<br />
''lxc-shutdown'' should be used for clean shutdown or reboot of the container, but only the ''reboot'' is working out of the box when using systemd.<br />
<br />
Shutdown will be signalled to the container with ''SIGPWR'' but current systemd doesn't have any services in place to handle the ''sigpwr.target''. But for the container we can simply reuse the ''poweroff.target'' and get exactly what we want.<br />
# ln -s /usr/lib/systemd/system/poweroff.target ${CONTAINER_RFS}/etc/systemd/system/sigpwr.target</div>Nrmhttps://wiki.archlinux.org/index.php?title=Linux_Containers&diff=266815Linux Containers2013-07-17T16:14:10Z<p>Nrm: /* Starting a container on boot with Systemd */ Modification of systemd template to be more generic</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Virtualization]]<br />
{{Stub|Currently just a rough draft... I think I will need to restructure this a bit and I have also noticed I have become a bit too verbose -_-;; I will be along shortly to complete this as well as clean it up.}}<br />
<br />
==Introduction==<br />
<br />
===Synopsis===<br />
<br />
Linux Containers (LXC) are an operating system-level virtualization method for running multiple isolated server installs (containers) on a single control host. LXC does not provide a virtual machine, but rather provides a virtual environment that has its own process and network space. It is similar to a chroot, but offers much more isolation.<br />
<br />
===About this HowTo===<br />
<br />
This document is intended as an overview on setting up and deploying containers, and is not an in depth detailed instruction by instruction guide. A certain amount of prerequisite knowledge and skills are assumed (running commands as root, kernel configuration, mounting filesystems, shell scripting, chroot type environments, networking setup, etc).<br />
<br />
Much of this was taken verbatim from [http://lxc.teegra.net/ Dwight Schauer], [http://tuxce.selfip.org/informatique/conteneurs-linux-lxc Tuxce] and [http://artisan.karma-lab.net/node/1749 Ulhume]. It has been copied here both to enable to community to share their collective wisdom and to expand on a few points.<br />
<br />
===Less verbose tutorial===<br />
<br />
[[User:Delerious010|Delerious010]] 21:43, 1 December 2009 (EST) I have come to realize I have added a lot of text to this HowTo. If you would like something more streamlined, please head on over to [http://lxc.teegra.net/ http://lxc.teegra.net/] for Dwight's excellent guide.<br />
<br />
===Testing capabilities===<br />
<br />
Once the lxc package is installed, running lxc-checkconfig will print out a list of your system's capabilities<br />
<br />
==Host configuration==<br />
<br />
===Control group filesystem===<br />
<br />
LXC depends on the control group filesystem being mounted. The standard location for it is {{ic|/sys/fs/cgroup}}. If you use systemd, the cgroup filesystem will be mounted automatically, including the default controllers, but with other initsystems you might have to do it yourself:<br />
<br />
mount -t tmpfs none /sys/fs/cgroup<br />
<br />
===Userspace tools===<br />
<br />
Install {{Pkg|lxc}} from [community].<br />
<br />
===Bridge device setup===<br />
<br />
The package {{pkg|bridge-utils}}, which provides the {{ic|brctl}} command, provides the ability to set up one or more network bridges to be used by LXC. You can use {{ic|brctl}} directly to set up the bridges, but the process is archaic and probably best avoided.<br />
<br />
If using netcfg, you could try to refer to the [[netcfg]] wiki page, but the bridge related documentation has been removed. So when using netcfg, you will be mostly on your own.<br />
<br />
OpenVPN has complete instructions for setting up a bridge, so it is probably your best option at the current. [[OpenVPN Bridge]]<br />
<br />
===Starting a container on boot with [[Systemd]]===<br />
<br />
If you completed a container, starting it when the host boots is possible with the following systemd service template:<br />
<br />
{{bc|1=<br />
[Unit]<br />
Description=Linux Container %i<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
ExecStartPre=/bin/mount --make-rprivate /<br />
ExecStart=/usr/bin/lxc-start -dn %i<br />
ExecStop=/usr/bin/lxc-stop -n %i<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
Save this file as {{ic|/etc/systemd/system/lxc@.service}}. Then you can register it with this command:<br />
<br />
systemctl enable lxc@CONTAINER_NAME.service<br />
<br />
==Container setup==<br />
<br />
'''Note''' Configuring a container that runs systemd requires specific configuration that is discussed [[lxc-systemd|here]].<br />
<br />
There are various different means to do this<br />
<br />
===Creating the filesystem===<br />
<br />
====Bootstrap====<br />
Bootstrap an install ( [http://blog.mudy.info/tag/mkarchroot/ mkarchroot], [http://wiki.debian.org/Debootstrap debootstrap], [http://www.xen-tools.org/software/rinse/faq.html rinse], [[Install From Existing Linux]] ). You can also just copy/use an existing installation’s complete root filesystem.<br />
<br />
For example, install a small debian to /home/lxc/debianfs<br />
<br />
yaourt -S debootstrap # install debootstrap from AUR<br />
<br />
# method 1:<br />
sudo debootstrap wheezy /home/lxc/debianfst http://ftp.us.debian.org/debian # use us mirror site install wheezy version<br />
# or, method 2: use faster tar ball method<br />
sudo debootstrap --make-tarball wheezy.packages.tgz sid http://debian.osuosl.org/debian/<br />
sudo debootstrap --unpack-tarball wheezy.packages.tgz wheezy debianfs<br />
<br />
====Download existing====<br />
You can download a base install tar ball. OpenVZ templates work just fine.<br />
<br />
====Using the lxc tools====<br />
/usr/bin/lxc-debian {create|destroy|purge|help}<br />
/usr/bin/lxc-fedora {create|destroy|purge|help}<br />
<br />
Nowadays you can create small and simple archlinux container<br />
# lxc-create -n containername -t archlinux -- -P vim,dhclient<br />
<br />
with the template specific options ''-P'' you can add a list of packages to the installation.<br />
<br />
===Creating the device nodes===<br />
Since [[udev]] does not work within the container, you will want to make sure that a certain minimum amount of devices is created for it. This may be done with the following script: <br />
#!/bin/bash<br />
ROOT=$(pwd)<br />
DEV=${ROOT}/dev<br />
mv ${DEV} ${DEV}.old<br />
mkdir -p ${DEV}<br />
mknod -m 666 ${DEV}/null c 1 3<br />
mknod -m 666 ${DEV}/zero c 1 5<br />
mknod -m 666 ${DEV}/random c 1 8<br />
mknod -m 666 ${DEV}/urandom c 1 9<br />
mkdir -m 755 ${DEV}/pts<br />
mkdir -m 1777 ${DEV}/shm<br />
mknod -m 666 ${DEV}/tty c 5 0<br />
mknod -m 600 ${DEV}/console c 5 1<br />
mknod -m 666 ${DEV}/tty0 c 4 0<br />
mknod -m 666 ${DEV}/full c 1 7<br />
mknod -m 600 ${DEV}/initctl p<br />
mknod -m 666 ${DEV}/ptmx c 5 2<br />
<br />
==Container configuration==<br />
<br />
===Configuration file===<br />
<br />
The main configuration files are used to describe how to originally create a container. Though these files may be located anywhere, /etc/lxc is probably a good place.<br />
<br />
'''23/Aug/2010: Be aware that the kernel may not handle additional whitespace in the configuration file. This has been experienced on "lxc.cgroup.devices.allow" settings but may also be true on other settings. If in doubt use only one space wherever whitespace is required.'''<br />
<br />
====Basic settings====<br />
<br />
lxc.utsname = $CONTAINER_NAME<br><br />
lxc.mount = $CONTAINER_FSTAB<br />
lxc.rootfs = $CONTAINER_ROOTFS<br><br />
lxc.network.type = veth<br />
lxc.network.flags = up<br />
lxc.network.link = br0<br />
lxc.network.hwaddr = $CONTAINER_MACADDR <br />
lxc.network.ipv4 = $CONTAINER_IPADDR<br />
lxc.network.name = $CONTAINER_DEVICENAME<br />
<br />
=====Basic settings explained=====<br />
<br />
'''lxc.utsname''' : This will be the name of the cgroup for the container. Once the container is started, you should be able to see a new folder named ''/cgroup/$CONTAINER_NAME''.<br />
<br />
Furthermore, this will also be the value returned by ''hostname'' from within the container. Assuming you have not removed access, the container may overwrite this with it's init script.<br />
<br />
'''lxc.mount''' : This points to an fstab formatted file that is a listing of the mount points used when ''lxc-start'' is called. This file is further explained [[#Configuring fstab|further]]<br />
<br />
====Terminal settings====<br />
<br />
The following configuration is optional. You may add them to your main configuration file if you wish to login via lxc-console, or through a terminal ( e.g.: {{Keypress|Ctrl+Alt+F1}} ).<br />
<br />
The container can be configured with virtual consoles (tty devices). These may be devices from the host that the container is given permission to use (by its configuration file) or they may be devices created locally within the container.<br />
<br />
The host's virtual consoles are accessed using the key sequence {{Keypress|Alt+Fn}} (or {{Keypress|Ctrl+Alt+Fn}} from within an X11 session). The left {{Keypress|Alt}} key reaches consoles 1 through 12 and the right {{Keypress|Alt}} key reaches consoles 13 through 24. Further virtual consoles may be reached by the {{Keypress|Alt+→}} key sequence which steps to the next virtual console.<br />
<br />
The container's local virtual consoles may be accessed using the "lxc-console" command.<br />
<br />
===== Host Virtual Consoles =====<br />
<br />
The container may access the host's virtual consoles if the host is not using them and the container's configuration allows it. Typical container configuration would deny access to all devices and then allow access to specific devices like this:<br />
<br />
lxc.cgroup.devices.deny = a # Deny all access to devices<br />
lxc.cgroup.devices.allow = c 4:0 rwm # /dev/tty0<br />
lxc.cgroup.devices.allow = c 4:1 rwm # /dev/tty1<br />
lxc.cgroup.devices.allow = c 4:2 rwm # /dev/tty2<br />
<br />
For a container to be able to use a host's virtual console it must not be in use by the host. This will most likely require the host's {{ic|/etc/inittab}} to be modified to ensure no getty or other process runs on any virtual console that is to be used by the container.<br />
<br />
After editing the host's {{ic|/etc/inittab}} file, issung a {{ic|killall -HUP init}} will terminate any getty processes that are no longer configured and this will free up the virtual conosole for use by the container.<br />
<br />
Note that local virtual consoles take precedence over host virtual consoles. This is described in the next section.<br />
<br />
===== Local Virtual Consoles =====<br />
<br />
The number of local virtual consoles that the container has is defined in the container's configuration file (normally on the host in {{ic|/etc/lxc}}). It is defined thus:<br />
<br />
lxc.tty = n<br />
<br />
where {{ic|n}} is the number of local virtual consoles required.<br />
<br />
The local virtual consoles are numbered starting at tty1 and take precedence over any of the host's virtual consoles that the container might be entitled to use. This means that, for example, if n = 2 then the container will not be able to use the host's tty1 and tty2 devices even entitled to do so by its configuration file. Setting n to 0 will prevent local virtual consoles from being created thus allowing full access to any of host's virtual consoles that the container might be entitled to use.<br />
<br />
===== /dev/tty Device Files =====<br />
The container must have a tty device file (e.g. {{ic|/dev/tty1}}) for each virtual console (host or local). These can be created thus:<br />
# mknod -m 666 /dev/tty1 c 4 1<br />
# mknod -m 666 /dev/tty2 c 4 2<br />
<br />
and so on...<br />
<br />
In the above, {{ic|c}} means character device, {{ic|4}} is the major device number (tty devices) and {{ic|1}}, {{ic|2}}, {{ic|3}}, etc., is the minor device number (specific tty device). Note that {{ic|/dev/tty0}} is special and always refers to the current virtual console.<br />
<br />
For further info on tty devices, read this: http://www.kernel.org/pub/linux/docs/device-list/devices.txt<br />
<br />
'''If a virtual console's device file does not exist in the container, then the container cannot use the virtual console.'''<br />
<br />
===== Configuring Log-In Ability =====<br />
<br />
The container's virtual consoles may be used for login sessions if the container runs "getty" services on their tty devices. This is normally done by the container's "init" process and is configured in the container's {{ic|/etc/inittab}} file using lines like this:<br />
<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
There is one line per device. The first part {{ic|c1}} is just a unique label, the second part defines applicable run levels, the third part tells init to start a new getty when the current one terminates and the last part gives the command line for the getty. For further information refer to {{ic|man init}}.<br />
<br />
If there is no getty process on a virtual console it will not be possible to log in via that virtual console. A getty is not required on a virtual console unless it is to be used to log in.<br />
<br />
If a virtual console is to allow root logins it also needs to be listed in the container's {{ic|/etc/securetty}} file.<br />
<br />
===== Troubleshooting virtual consoles =====<br />
<br />
If lxc.tty is set to a number, n, then no host devices numbered n or below will be accessible even if the above configuration is present because they will be replaced with local virtual consoles instead.<br />
<br />
A tty device file's major number will change from 4 to 136 if it is a local virtual console. This change is visible within the container but not when viewing the container's devices from the host's filesystem. This information is useful when troubleshooting.<br />
<br />
This can be checked from within a container thus:<br />
<br />
# ls -Al /dev/tty*<br />
crw------- 1 root root 136, 10 Aug 21 21:28 /dev/tty1<br />
crw------- 1 root root 4, 2 Aug 21 21:28 /dev/tty2<br />
<br />
===== Pseudo Terminals =====<br />
<br />
lxc.pseudo = 1024<br />
<br />
Maximum amount of pseudo terminals that may be created in {{ic|/dev/pts}}. Currently, assuming the kernel was compiled with {{ic|CONFIG_DEVPTS_MULTIPLE_INSTANCES}}, this tells lxc-start to mount the devpts filesystem with the newinstance flag.<br />
<br />
====Host device access settings====<br />
<br />
lxc.cgroup.devices.deny = a # Deny all access to devices<br><br />
lxc.cgroup.devices.allow = c 1:3 rwm # dev/null<br />
lxc.cgroup.devices.allow = c 1:5 rwm # dev/zero<br><br />
lxc.cgroup.devices.allow = c 5:1 rwm # dev/console<br />
lxc.cgroup.devices.allow = c 5:0 rwm # dev/tty<br />
lxc.cgroup.devices.allow = c 4:0 rwm # dev/tty0<br><br />
lxc.cgroup.devices.allow = c 1:9 rwm # dev/urandom<br />
lxc.cgroup.devices.allow = c 1:8 rwm # dev/random<br />
lxc.cgroup.devices.allow = c 136:* rwm # dev/pts/*<br />
lxc.cgroup.devices.allow = c 5:2 rwm # dev/pts/ptmx<br><br />
# No idea what this is .. dev/bsg/0:0:0:0 ???<br />
lxc.cgroup.devices.allow = c 254:0 rwm<br />
<br />
=====Host device access settings explained=====<br />
<br />
'''lxc.cgroup.devices.deny''' : By settings this to ''a'', we are stating that the container has access to no devices unless explicitely defined within the configuration file.<br />
<br />
===Configuration file notes===<br />
====At runtime /dev/ttyX devices are recreated====<br />
If you have enabled multiple DevPTS instances in your kernel, lxc-start will recreate ''lxc.tty'' amount of {{ic|/dev/ttyX}} devices when it is executed.<br />
<br />
This means that you will have ''lxc.tty'' amount of pseudo ttys. If you are planning on accessing the container via a "real" terminal ({{Keypress|Ctrl+Alt+FX}}), make sure that it is a number that is inferior to ''lxc.tty''.<br />
<br />
To tell whether it has been re-created, just log in to the container via either lxc-console or SSH and perform a {{ic|ls -Al}} command on the tty. Devices with a major number of 4 are "real" tty devices whereas a major number of 136 indicates a pts.<br />
<br />
Be aware that this is only visible from within the container itself and not from the host.<br />
<br />
====Containers have access to host's TTY nodes====<br />
<br />
If you do not properly restrict the container's access to the /dev/tty nodes, the container may have access to the host's.<br />
<br />
Taking into consideration that, as previously mentioned, lxc-start recreates ''lxc.tty'' amount of /dev/tty devices, any tty nodes present in the container that are of a greater minor number than ''lxc.tty'' will be linked to the host's.<br />
<br />
=====To access the container from a host TTY=====<br />
<br />
# On the host, verify no getty is started for that tty by checking ''/etc/inittab''.<br />
# In the container, start a getty for that tty.<br />
<br />
=====To prevent access to the host TTY=====<br />
<br />
Please have a look at the configuration statements found in [[#Host device access settings|host device access settings]].<br />
<br />
Via the ''lxc.cgroup.devices.deny = a'' we are preventing access to all host level devices. And then, throuh ''lxc.cgroup.devices.allow = c 4:'''1''' rwm'' we are allowing access to the host's /dev/tty'''1'''. In the above example, simply removing all allow statements for major number 4 and minor > 1 should be sufficient.<br />
<br />
=====To test this access=====<br />
<br />
I may be off here, but looking at the output of the ''ls'' command below should show you both the ''major'' and ''minor'' device numbers. These are located after the user and group and represented as : 4, 2<br />
<br />
# Set lxc.tty to 1<br />
# Make there that the container has dev/tty1 and /dev/tty2<br />
# ''lxc-start'' the container<br />
# ''lxc-console'' into the container<br />
# ''ls -Al /dev/tty''<br>crw------- 1 root root 4, 2 Dec 2 00:20 /dev/tty2<br />
# ''echo "test output" > /dev/tty2''<br />
# ''Ctrl+Alt+F2'' to view the host's second terminal<br />
# You should see "test output" printed on the screen<br />
<br />
====Configuration troubleshooting====<br />
<br />
=====console access denied: Permission denied=====<br />
<br />
If, when executing lxc-console, you receive the error ''lxc-console: console access denied: Permission denied'' you have most likely either omitted lxc.tty or set it to 0.<br />
<br />
=====lxc-console does not provide a login prompt=====<br />
<br />
Though you are reaching a tty on the container, it most likely is not running a getty. You will want to double check that you have a getty defined in the container's ''/etc/inittab'' for the specific tty.<br />
<br />
If using '''systemd''' chances are that a problem with the ''getty@.service'' script will bite you. The script only starts a getty if ''/dev/tty0'' exists. And since this condition is not met in the container, you get no getty. Use this patch, to let ''lxc-console'' finally work.<br />
<br />
<pre><br />
--- /usr/lib/systemd/system/getty@.service.orig 2013-05-30 12:55:28.000000000 +0000<br />
+++ /usr/lib/systemd/system/getty@.service 2013-06-16 23:05:49.827146901 +0000<br />
@@ -20,7 +20,8 @@<br />
# On systems without virtual consoles, don't start any getty. (Note<br />
# that serial gettys are covered by serial-getty@.service, not this<br />
# unit<br />
-ConditionPathExists=/dev/tty0<br />
+ConditionVirtualization=|lxc<br />
+ConditionPathExists=|/dev/tty0<br />
<br />
[Service]<br />
# the VT is cleared by TTYVTDisallocate<br />
</pre><br />
<br />
For more than one getty you have to explicitly enable the needed service (and decrease ''lxc.tty'' in the container configuration). In the ''real'' system a configurable number of getty-services is automatically created from the ''systemd-logind.service''<br />
<br />
===Configuring fstab===<br />
none $CONTAINER_ROOTFS/dev/pts devpts defaults 0 0<br />
none $CONTAINER_ROOTFS/proc proc defaults 0 0<br />
none $CONTAINER_ROOTFS/sys sysfs defaults 0 0<br />
none $CONTAINER_ROOTFS/dev/shm tmpfs defaults 0 0<br />
<br />
This fstab is used by lxc-start when mounting the container. As such, you can define any mount that would be possible on the host such as bind mounting to the host's own filesystem. However, please be aware of any and all security implications that this may have.<br />
<br />
'''Warning''' : You certainly do not want to bind mount the host's /dev to the container as this would allow it to, amongst other things, reboot the host.<br />
<br />
==Container Creation and Destruction==<br />
<br />
===Creation===<br />
lxc-create -f $CONTAINER_CONFIGPATH -n $CONTAINER_NAME<br />
<br />
''lxc-create'' will create /var/lib/lxc/$CONTAINER_NAME with a new copy of the container configuration file found in $CONTAINER_CONFIGPATH.<br />
<br />
As such, if you need to make modifications to the container's configuration file, it's advisable to modify only the original file and then perform ''lxc-destroy'' and ''lxc-create'' operations afterwards. No data will be lost by doing this.<br />
<br />
'''Note''' : When copying the file over, lxc-create will strip all comments from the file.<br />
<br />
'''Note''' : As of lxc-git from atleast ''2009-12-01'', performing lxc-create no longer splits the config file into multiple files and folders. Therefore, we only have the configuration file to worry about.<br />
<br />
===Destruction===<br />
lxc-destroy -n $CONTAINER_NAME<br />
<br />
This will delete /var/lib/lxc/$CONTAINER_NAME which only contains configuration files. No data will be lost.<br />
<br />
==Readying the host for virtualization==<br />
===/etc/inittab===<br />
# Comment out any getty that are not required<br />
<br />
===/etc/rc.sysinit replacement===<br />
Since we are running in a virtual environment, a number of steps undertaken by rc.sysinit are superfluous and may even flat out fail or stall. As such, until the initscripts are made virtualization aware, this will take some hack and slash.<br />
<br />
For now, simply replace the file : <br />
#!/bin/bash<br />
# Whatever is needed to clean out old daemon/service pids from your container<br />
rm -f $(find /var/run -name '*pid')<br />
rm -f /var/lock/subsys/*<br><br />
# Configure network settings<br />
## You can either use dhcp here, manually configure your<br />
## interfaces or try to get the rc.d/network script working.<br />
## There have been reports that network failed in this<br />
## environment.<br />
ip route add default via 192.168.10.1<br />
echo > /etc/resolv.conf search your-domain<br />
echo >> /etc/resolv.conf nameserver 192.168.10.1<br><br />
# Initally we do not have any container originated mounts<br />
rm -f /etc/mtab<br />
touch /etc/mtab<br />
<br />
===/etc/rc.conf cleanup===<br />
You may want to remove any and all hardware related daemons from the DAEMONS line. Furthermore, depending on your situation, you may also want to remove the ''network'' daemon.<br />
<br />
===TBC===<br />
<br />
==Known Problems==<br />
<br />
===Container cannot be shutdown if using systemd===<br />
''lxc-shutdown'' should be used for clean shutdown or reboot of the container, but only the ''reboot'' is working out of the box when using systemd.<br />
<br />
Shutdown will be signalled to the container with ''SIGPWR'' but current systemd doesn't have any services in place to handle the ''sigpwr.target''. But for the container we can simply reuse the ''poweroff.target'' and get exactly what we want.<br />
# ln -s /usr/lib/systemd/system/poweroff.target ${CONTAINER_RFS}/etc/systemd/system/sigpwr.target</div>Nrmhttps://wiki.archlinux.org/index.php?title=Desktop_notifications&diff=231182Desktop notifications2012-10-24T16:07:35Z<p>Nrm: /* Other servers */ Add twmn</p>
<hr />
<div>[[Category:Development]]<br />
[[es:Libnotify]]<br />
[[ru:Libnotify]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|This article discusses how to install, configure and use libnotify for application development.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GTK+}}<br />
{{Article summary wiki|Libcanberra}}<br />
{{Article summary end}}<br />
<br />
'''Libnotify''' is an easy way to display desktop notifications and information in a small dialog. It implements the [http://developer.gnome.org/notification-spec/ Desktop Notifications Specification] and it is already used by many open source apps like [[Evolution]], [[Pidgin]], etc. It has support for [[GTK+]] and [[Qt]] applications and is desktop independent.<br />
<br />
==Installation==<br />
<br />
Libnotify can be installed with the package {{Pkg|libnotify}}, available in the [[official repositories]].<br />
<br />
In order to use libnotify, you have to install a notification server:<br />
<br />
===Builtin servers===<br />
[[GNOME]] and [[KDE]] use their own implementations to display notifications, and you can't replace them. Their notification servers are started automatically on login to receive notifications from applications via DBus.<br />
* {{Pkg|gnome-shell}} provides a notification server itself. Notifications are displayed at the bottom of the screen.<br />
* KDE uses '''knotify4''' from package {{Pkg|kdebase-runtime}} to display notifications. Notifications are displayed at the bottom right corner of the screen.<br />
<br />
===Other servers===<br />
In other desktop environments, the notification server is launched on the first call via DBus. You can choose one of the following implementations:<br />
* {{pkg|notification-daemon}} is the notification server used by GNOME in Fallback Mode. Notifications are displayed at the top right corner of the screen.<br />
:{{Note|notification-daemon doesn't have a DBus service file, so you have to [[autostart]] it. (Already done in GNOME Fallback Mode.)}}<br />
:{{Tip|To start the daemon manually: {{ic|/usr/lib/notification-daemon-1.0/notification-daemon}}.}}<br />
* {{Pkg|xfce4-notifyd}} is a notification server for [[Xfce]], available in the official repositories.<br />
:{{Tip|To configure xfce4-notifyd, run the following command in the terminal: {{ic|xfce4-notifyd-config}}.}}<br />
* {{pkg|dunst}} is a minimalistic notification daemon for Linux designed to fit nicely into minimalistic windowmanagers like [[dwm]]. <br />
* {{AUR|notify-osd}} is a notification server for [[Unity]], available in the AUR.<br />
* {{AUR|awn-extras-applets}} contains a notification-daemon applet for the [[Avant Window Navigator]], available in the [[Arch User Repository]].<br />
* {{AUR|statnot}} is a small, lightweight notification daemon that can output notifications to the root window's title, stdout or FIFO pipes, making it integrate very well with tiling window managers. It's available in the [[Arch User Repository]] or as a [https://github.com/halhen/statnot git repo].<br />
* {{AUR|twmn}} is a notification system for tiling window managers. It's available in the [[Arch User Repository]] or as a [https://github.com/sboli/twmn git repo].<br />
<br />
==Tips and tricks==<br />
<br />
===Write your own notify app===<br />
You can write your own libnotify display messages easily in many programming languages through GObject-Introspection or bindings, or you can simply use bash.<br />
<br />
The following examples display simple a "Hello world" notification.<br />
<br />
====Bash====<br />
*Dependency: {{Pkg|libnotify}}<br />
{{hc|hello_world.sh|<nowiki>#!/bin/bash<br />
notify-send 'Hello world!' 'This is an example notification.' --icon=dialog-information</nowiki>}}<br />
<br />
====Boo====<br />
*Dependency: {{Pkg|notify-sharp}} ({{Pkg|boo}})<br />
*Makedependency: {{Pkg|boo}}<br />
*Build with: {{ic|booc hello_world.boo}}<br />
*Run with: {{ic|mono hello_world.exe}} (or {{ic|booi hello_world.boo}})<br />
<br />
{{hc|hello_world.boo|<nowiki>import Notifications from "notify-sharp"<br />
Hello = Notification()<br />
Hello.Summary = "Hello world!"<br />
Hello.Body = "This is an example notification."<br />
Hello.IconName = "dialog-information"<br />
Hello.Show()</nowiki>}}<br />
<br />
====C====<br />
*Dependency: {{Pkg|libnotify}}<br />
*Build with: {{ic|gcc -o hello_world `pkg-config --cflags --libs libnotify` hello_world.c}}<br />
{{hc|hello_world.c|<nowiki>#include <libnotify/notify.h><br />
void main () {<br />
notify_init ("Hello world!");<br />
NotifyNotification * Hello = notify_notification_new ("Hello world", "This is an example notification.", "dialog-information");<br />
notify_notification_show (Hello, NULL);<br />
}</nowiki>}}<br />
<br />
====C++====<br />
*Dependency: {{AUR|libnotifymm}} from AUR<br />
*Build with: {{Ic|g++ -o hello_world `pkg-config --cflags --libs libnotifymm-1.0` hello_world.cc}}<br />
{{hc|hello_world.cc|<nowiki>#include <libnotifymm.h><br />
int main(int argc, char *argv[]) {<br />
Notify::init("Hello world!");<br />
Notify::Notification Hello("Hello world", "This is an example notification.", "dialog-information");<br />
Hello.show();<br />
}</nowiki>}}<br />
<br />
====C#====<br />
*Dependency: {{Pkg|notify-sharp}}<br />
*Build with: {{ic|mcs -pkg:notify-sharp hello_world.cs}}<br />
*Run with: {{ic|mono hello_world.exe}}<br />
{{hc|hello_world.cs|<nowiki>using Notifications;<br />
public class HelloWorld {<br />
static void Main() {<br />
var Hello = new Notification();<br />
Hello.Summary = "Hello world!";<br />
Hello.Body = "This is an example notification.";<br />
Hello.IconName = "dialog-information";<br />
Hello.Show();<br />
}<br />
}</nowiki>}}<br />
<br />
====Genie====<br />
*Dependency: {{Pkg|libnotify}}<br />
*Makedependency: {{Pkg|vala}}<br />
*Build with: {{ic|valac --pkg libnotify hello_world.gs}}<br />
{{hc|hello_world.gs|<nowiki>uses <br />
Notify<br />
<br />
init<br />
Notify.init ("Hello world")<br />
var Hello=new Notification ("Hello world!","This is an example notification.","dialog-information")<br />
Hello.show ()</nowiki>}}<br />
<br />
====Go====<br />
* [https://github.com/lenormf/go-notify/blob/master/examples/single_notification/main.go go-notify]<br />
<br />
====Java====<br />
*Dependency: {{AUR|java-gnome}} from AUR<br />
*Makedependency: java-environment<br />
*Build with: {{ic|mkdir HelloWorld && javac -classpath /usr/share/java/gtk.jar -d HelloWorld HelloWorld.java}}<br />
*Run with: {{ic|java -classpath /usr/share/java/gtk.jar:HelloWorld HelloWorld}}<br />
<br />
{{hc|HelloWorld.java|<nowiki>import org.gnome.gtk.Gtk;<br />
import org.gnome.notify.Notify;<br />
import org.gnome.notify.Notification;<br />
<br />
public class HelloWorld<br />
{<br />
public static void main(String[] args) {<br />
Gtk.init(args);<br />
Notify.init("Hello world");<br />
Notification Hello = new Notification("Hello world!", "This is an example notification.", "dialog-information");<br />
Hello.show();<br />
}<br />
}</nowiki>}}<br />
<br />
====JavaScript====<br />
*Dependencies: {{Pkg|libnotify}}, {{Pkg|gjs}} (works also with {{Pkg|seed}})<br />
{{hc|hello_world.js|<nowiki>#!/usr/bin/gjs<br />
Notify = imports.gi.Notify;<br />
Notify.init ("Hello world");<br />
Hello=new Notify.Notification ({summary: "Hello world!",<br />
body: "This is an example notification.",<br />
"icon-name": "dialog-information"});<br />
Hello.show ();</nowiki>}}<br />
<br />
====Perl====<br />
*Dependencies: {{Pkg|libnotify}}, {{AUR|perl-glib-object-introspection}} from AUR<br />
{{hc|hello_world.pl|<nowiki>#!/usr/bin/perl<br />
use Glib::Object::Introspection;<br />
Glib::Object::Introspection->setup (<br />
basename => 'Notify',<br />
version => '0.7',<br />
package => 'Notify');<br />
Notify->init;<br />
my $hello = Notify::Notification->new("Hello world!", "This is an example notification.", "dialog-information");<br />
$hello->show;</nowiki>}}<br />
<br />
Or you can use the old, static perl-gtk2-notify bindings:<br />
*Dependency: {{AUR|perl-gtk2-notify}} from AUR<br />
{{hc|hello_world.pl|<nowiki>#!/usr/bin/perl<br />
use Gtk2::Notify -init, "Hello world";<br />
my $hello = Gtk2::Notify->new("Hello world!", "This is an example notification.", "dialog-information");<br />
$hello->show;</nowiki>}}<br />
<br />
====Python====<br />
*Dependencies: {{Pkg|libnotify}}, {{Pkg|python-gobject}}<br />
{{hc|hello_world.py|<nowiki>#!/usr/bin/python<br />
from gi.repository import Notify<br />
Notify.init ("Hello world")<br />
Hello=Notify.Notification.new ("Hello world","This is an example notification.","dialog-information")<br />
Hello.show ()</nowiki>}}<br />
<br />
Or you can use the old, static python-notify bindings:<br />
*Dependency: {{Pkg|python-notify}}<br />
{{hc|hello_world.py|<nowiki>#!/usr/bin/python2<br />
import pynotify<br />
pynotify.init ("Hello world")<br />
Hello=pynotify.Notification ("Hello world!","This is an example notification.","dialog-information")<br />
Hello.show ()</nowiki>}}<br />
<br />
====Ruby====<br />
*Dependencies: {{Pkg|libnotify}}, {{AUR|ruby-gir-ffi}} from AUR<br />
{{hc|hello_world.rb|<nowiki>#!/usr/bin/ruby<br />
require 'gir_ffi'<br />
GirFFI.setup :Notify<br />
Notify.init("Hello world")<br />
Hello = Notify::Notification.new("Hello world!", "This is an example notification.", "dialog-information")<br />
Hello.show</nowiki>}}<br />
<br />
Or you can use the old, static ruby-libnotify bindings:<br />
*Dependency: {{AUR|ruby-libnotify}} from AUR<br />
{{hc|hello_world.rb|<nowiki>#!/usr/bin/ruby<br />
require 'RNotify'<br />
Notify.init("Hello world")<br />
Hello = Notify::Notification.new("Hello world!", "This is an example notification.", "dialog-information")<br />
Hello.show</nowiki>}}<br />
<br />
====Vala====<br />
*Dependency: {{Pkg|libnotify}}<br />
*Makedependency: {{Pkg|vala}}<br />
*Build with: {{ic|valac --pkg libnotify hello_world.vala}}<br />
{{hc|hello_world.vala|<nowiki>using Notify;<br />
public class HelloWorld {<br />
static void main () {<br />
Notify.init ("Hello world");<br />
var Hello = new Notification("Hello world!", "This is an example notification.", "dialog-information");<br />
Hello.show ();<br />
}<br />
}</nowiki>}}<br />
<br />
====Visual Basic .NET====<br />
*Dependency: {{Pkg|notify-sharp}}<br />
*Makedependency: {{Pkg|mono-basic}}<br />
*Build with: {{ic|vbnc -r:/usr/lib/mono/notify-sharp/notify-sharp.dll hello_world.vb}}<br />
*Run with: {{ic|mono hello_world.exe}}<br />
<br />
{{hc|hello_world.vb|<nowiki>Imports Notifications<br />
Public Class Hello<br />
Public Shared Sub Main<br />
Dim Hello As New Notification<br />
Hello.Summary = "Hello world!"<br />
Hello.Body = "This is an example notification."<br />
Hello.IconName = "dialog-information"<br />
Hello.Show<br />
End Sub<br />
End Class</nowiki>}}<br />
<br />
==See also==<br />
*[http://developer.gnome.org/libnotify/ Libnotify Reference Manual]<br />
*[http://milky.manishsinha.net/2009/03/29/working-with-libnotify/ C example]<br />
*[http://code.valaide.org/content/genie-libnotify-example Genie example]<br />
*[http://roscidus.com/desktop/node/336 Python example]</div>Nrm