https://wiki.archlinux.org/api.php?action=feedcontributions&user=Philfifi&feedformat=atomArchWiki - User contributions [en]2024-03-28T21:47:50ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Wake-on-LAN&diff=323959Wake-on-LAN2014-07-07T19:19:30Z<p>Philfifi: Details on BIOS option</p>
<hr />
<div>[[Category:Networking]]<br />
'''Wake-on-LAN''', otherwise known as 'wol', is the ability to switch on a computer that is connected to a network (be it the internet or intranet). This article deals with what it is, how it can be used from an Arch Linux computer, and its general uses.<br />
<br />
It is important to note that Wake-on-LAN applies to the computers being physically connected (ie, not wireless).<br />
<br />
==Does my motherboard support Wake-on-LAN?==<br />
<br />
For Wake-on-LAN to work, the target computer motherboard must support this feature. Generally speaking, the Wake-on-LAN (non)ability of the target motherboard will be specified by the hardware manufacturer. Sometimes, this ability is evident by browsing through said motherboard's BIOS and looking for something like 'PCI Power up' or “Allow PCI wake up event”. Most modern motherboards should support Wake-on-LAN.<br />
<br />
==Ensure that Wake-on-LAN is enabled and survives a reboot==<br />
A common problem with the Wake-on-LAN in computers running Linux is that the network drivers have Wake-on-LAN switched off by default. To manually switch on the Wake-on-LAN feature on your driver, you will need to install {{Pkg|ethtool}}.<br />
<br />
{{Note|For the following commands substitute net0 with your network device, e.g. eth0}}<br />
<br />
First query the driver to see if it's defaulted to 'on' by using ethtool:<br />
<br />
{{hc|<nowiki># ethtool net0 | grep Wake-on</nowiki>|<nowiki><br />
Supports Wake-on: pg<br />
Wake-on: d<br />
</nowiki>}}<br />
<br />
{{Note|We need a 'Wake-on' value of 'g' for WOL to work.}}<br />
<br />
To enable the wol feature in the driver, simply run the following<br />
# ethtool -s net0 wol g<br />
<br />
This command does not last beyond the '''next''' reboot. If using netctl, one can make this setting persistent by adding the following to your netctl profile:<br />
{{hc|/etc/netctl/PROFILE|2=<br />
ExecUpPost='/usr/bin/ethtool -s net0 wol g'<br />
}}<br />
<br />
*If for some reason, you find that after using the command to switch your network drivers Wake-on-LAN feature on, the computer shuts down normally but then starts again, experiment with combinations of [u/b/m]g<br />
*For some network cards, you may also need the following command:<br />
<br />
# echo enabled > /sys/class/net/net0/device/power/wakeup<br />
<br />
===With udev===<br />
<br />
udev is capable of running any command you desire as soon as a device is visible. We want udev to turn on wake on lan for our device. Put the following in /etc/udev/rules.d/50-wol.rules, replacing N with the number for your interface:<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="netN", RUN+="/usr/bin/ethtool -s %k wol g"<br />
<br />
This tells udev to run "/usr/bin/ethtool -s netN wol g" as soon as the device netN exists. To turn on wake on lan for all new devices, replace the N with a '*':<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="net*", RUN+="/usr/bin/ethtool -s %k wol g"<br />
<br />
===With cron===<br />
<br />
A command can be run each time the computer is (re)booted using "@reboot" in a crontab. First, make sure [[Cron#Installation|cron]] is enabled, and then [[Cron#Basic_commands|edit a crontab]] for the root user that contains the following line:<br />
@reboot /usr/bin/ethtool -s [net-device] wol g<br />
<br />
===With systemd===<br />
<br />
If for some reason udev fails or is not an option, systemd can be used instead as a last resort. (In this editor's experience, systemd is rather intermittent.) To use systemd, do ''not'' follow the udev instructions. Instead, create a new service unit file /etc/systemd/system/wol@.service:<br />
<br />
{{bc|1=<br />
[Unit]<br />
Description=Wake-on-LAN for %i<br />
Requires=network.target<br />
After=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/ethtool -s %i wol g<br />
Type=oneshot<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Or install {{AUR|wol-systemd}} package from the [[AUR]]<br />
<br />
Then activate this new service for your network adapter:<br />
<br />
# systemctl enable wol@net0<br />
<br />
and start it right now<br />
<br />
# systemctl start wol@net0<br />
<br />
==Wake-on-LAN in different situations==<br />
<br />
The computer that you want to use Wake-on-LAN on may be directly linked to your computer through a network cable, connected to the same router that you are using, or remotely, across the internet.<br />
<br />
There are four essential things needed in order to use Wake-on-LAN on a target PC:<br />
<br />
#Some kind of Wake-on-LAN software on the host (your) PC<br />
#A connection to the internet or intranet of the target PC<br />
#The MAC address of the target PC<br />
#The internal or external IP of the target PC<br />
<br />
*Firstly, install a Wake-on-LAN software. In this article, {{Pkg|wol}} (available in the [[official repositories]]) will be used.<br />
<br />
*'''It is recommended that you read the documentation of wol'''<br />
<br />
man wol<br />
wol --help<br />
<br />
*wol requires several parameters, the most basic needed:<br />
<br />
wol MACADDRESS<br />
<br />
*But it is good practice to include the IP address or hostname, therefore this syntax should be the minimal used:<br />
<br />
# wol -i HOSTNAME_OR_IP MACADDRESS<br />
<br />
*The documentation of wol states that:<br />
<br />
::''Each MAC-ADDRESS is written as x:x:x:x:x:x, where x is a hexadecimal number between 0 and ff which represents one byte of the address, which is in network byte order (big endian).''<br />
<br />
*To obtain the MACADDRESS of the target computer:<br />
<br />
$ ip link<br />
<br />
The port, IP or hostname of the target PC will be addressed in the relevant following sections.<br />
<br />
===Across your intranet/network (no router)===<br />
<br />
If you are connected directly to another computer through a network cable, or have disabled your router firewall (not a good idea), then using Wake-on-LAN should be very simple.<br />
<br />
====For two computers connected to each other====<br />
<br />
wol MACADDRESS_OF_TARGET_PC<br />
<br />
====For computers connected to a non-firewalled router====<br />
<br />
wol -i INTERNAL_IP_OF_TARGET_PC MACADDRESS_OF_TARGET_PC<br />
<br />
*To find the internal IP:<br />
{{bc|<nowiki>ip addr | grep 'inet '</nowiki>}}<br />
<br />
*Since you are not firewalled, then there is no need to worry about port redirects.<br />
*If you intend to continue using Wake-on-LAN, it is recommended that you assign your computer's MACADDRESS to a specific IP on your router. Consult your router for details as to how to do this.<br />
<br />
===Across your intranet/network (router)===<br />
<br />
The syntax used in this situation:<br />
<br />
wol -p PORT_FORWARDED_TO_INTERNAL_IP -i INTERNAL_IP MACADDRESS_OF_TARGET_PC<br />
<br />
*When you send the MagicPacket signal to the target computer via a specific port, the signal passes through your router. The router must be instructed to forward any signal heading for that specific port to the internal IP of the target PC.<br />
<br />
*It is recommended that for multiple computers connected to one computer, to assign a different port forward to each internal IP<br />
<br />
*For port forwarding help, please consult http://portforward.com/ (though this website has some Windows specific content, it has a very large database of router web interfaces)<br />
<br />
===Across the internet===<br />
{{Expansion|Request for OpenWRT instructions.}}<br />
The syntax needed in this case:<br />
<br />
wol -p X -i HOSTNAME_OR_EXTERNAL_IP_OF_TARGET MACADDRESS<br />
<br />
*Assuming that you know the external IP of the target machine, and that the [[Wake-on-LAN#Across_your_intranet.2Fnetwork_.28router.29|router ports]] on both sides have been forwarding correctly, then this should be exactly as the syntax states.<br />
<br />
<br />
Usually it is necessary to forward your wol port (typically UDP 9) to the broadcast address on your network, not to a particular IP. Most routers do not allow you to forward to broadcast, however if you can get shell access to your router (through telnet, ssh, serial cable, etc) you can implement this workaround:<br />
ip neighbor add 192.168.1.254 lladdr FF:FF:FF:FF:FF:FF dev net0<br />
<br />
(The above command assumes your network is 192.168.1.0/24 and use net0 as network interface). Now, forward UDP port 9 to 192.168.1.254. This has worked for me on a Linksys WRT54G running Tomato, and on the Verizon FIOS ActionTec router.<br />
<br />
For notes on how to do it on DD-WRT routers, see [http://www.dd-wrt.com/wiki/index.php/WOL#Remote_Wake_On_LAN_via_Port_Forwarding this tutorial].<br />
<br />
==Battery draining problem==<br />
Some laptops have battery draining problem after shutdown [http://ubuntuforums.org/archive/index.php/t-1729782.html]. This might be caused by enabled Wake-on-LAN. To solve this problem, we can disable it by using ethtool as mentioned above.<br />
<br />
# ethtool -s net0 wol d<br />
<br />
We can also add this to the '''/etc/rc.local''' or '''/etc/rc.local.shutdown'''.<br />
<br />
==Additional Notes==<br />
<br />
*A common problem is that some forget to switch on the Wake-on-LAN feature in their BIOS.<br />
<br />
*In some systems the BIOS option "Boot from PCI/PCI-E" needs to be Enabled.<br />
<br />
==Example WOL script==<br />
Here is a script you can use to automate wol to several different machine. Modify as you see fit:<br />
<br />
<pre>#!/bin/bash<br />
<br />
# definition of MAC addresses<br />
monster=01:12:46:82:ab:4f<br />
chronic=00:3a:53:21:bc:30<br />
powerless=1a:32:41:02:29:92<br />
ghost=01:1a:d2:56:6b:e6<br />
<br />
while [ "$input1" != quit ]; do<br />
echo "Which PC to wake?"<br />
echo "p) powerless"<br />
echo "m) monster"<br />
echo "c) chronic"<br />
echo "g) ghost"<br />
echo "b) wake monster, wait 40sec, then wake chronic"<br />
echo "q) quit and take no action"<br />
read input1<br />
if [ $input1 == p ]; then<br />
/usr/bin/wol $powerless<br />
exit 1<br />
fi<br />
<br />
if [ $input1 == m ]; then<br />
/usr/bin/wol $monster<br />
exit 1<br />
fi<br />
<br />
if [ $input1 == c ]; then<br />
/usr/bin/wol $chronic<br />
exit 1<br />
fi<br />
<br />
# this line requires an IP address in /etc/hosts for ghost<br />
# and should use wol over the internet provided that port 9<br />
# is forwarded to ghost on ghost's router<br />
<br />
if [ $input1 == g ]; then<br />
/usr/bin/wol -v -h -p 9 ghost $ghost<br />
exit 1<br />
fi<br />
<br />
if [ $input1 == b ]; then<br />
/usr/bin/wol $monster<br />
echo "monster sent, now waiting for 40sec then waking chronic"<br />
sleep 40<br />
/usr/bin/wol $chronic<br />
exit 1<br />
fi<br />
<br />
if [ $input1 == Q ] || [ $input1 == q ]; then<br />
echo "later!"<br />
exit 1<br />
fi<br />
<br />
done<br />
echo "this is the (quit) end!! c-ya!"</pre><br />
== See also ==<br />
<br />
* [http://www.depicus.com/wake-on-lan/woli.aspx Wake-On-Lan]</div>Philfifihttps://wiki.archlinux.org/index.php?title=SSH_keys&diff=187871SSH keys2012-03-05T20:24:23Z<p>Philfifi: kdm needs kde-agent package</p>
<hr />
<div>[[Category:Secure Shell (English)]]<br />
{{i18n|Using SSH Keys}}<br />
<br />
SSH keys serve as a means of identifying yourself to an SSH server using [[Wikipedia:Public-key cryptography|public-key cryptography]] and [[Wikipedia:Challenge-response authentication|challenge-response authentication]]. One immediate advantange this method has over traditional password authentication is that you can be authenticated by the server without ever having to send your password over the network. Anyone eavesdropping on your connection will not be able to intercept and crack your password because it is never actually transmitted. Additionally, Using SSH keys for authentication virtually eliminates the risk posed by brute-force password attacks by drastically reducing the chances of the attacker correctly guessing the proper credentials.<br />
<br />
As well as offering additional security, SSH key authentication can be more convenient than the more traditional password authentication. When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.<br />
<br />
SSH keys are not without their drawbacks and may not be appropriate for all environments, but in many circumstances they can offer some strong advantages. A general understanding of how SSH keys work will help you decide how and when to use them to meet your needs. This article assumes you already have a basic understanding of the [[Secure Shell]] protocol and have installed the {{Pkg|openssh}} package, available in the [[Official Repositories]].<br />
<br />
==Background==<br />
SSH keys always come in pairs, one private and the other public. The private key is known only to you and it should be safely guarded. By contrast, the public key can be shared freely with any SSH server to which you would like to connect.<br />
<br />
When an SSH server has your public key on file and sees you requesting a connection, it uses your public key to construct and send you a challenge. This challenge is like a coded message and it must be met with the appropriate response before the server will grant you access. What makes this coded message particularly secure is that it can only be understood by someone with the private key. While the public key can be used to encrypt the message, it cannot be used to decrypt that very same message. Only you, the holder of the private key, will be able to correctly understand the challenge and produce the correct response.<br />
<br />
This challenge-response phase happens behind the scenes and is invisible to the user. As long as you hold the private key, which is typically stored in the {{ic|~/.ssh/}} directory, your SSH client should be able to reply with the appropriate response to the server.<br />
<br />
Because private keys are considered sensitive information, they are often stored on disk in an encrypted form. In this case, when the private key is required, a passphrase must first be entered in order to decrypt it. While this might superficially appear the same as entering a login password on the SSH server, it is only used to decrypt the private key on the local system. This passphrase is not, and should not, be transmitted over the network.<br />
<br />
==Generating an SSH key pair==<br />
An SSH key pair can be generated by running the {{ic|ssh-keygen}} command:<br />
{{hc|1=<br />
$ ssh-keygen -b 521 -t ecdsa -C"$(id -un)@$(hostname)-$(date --rfc-3339=date)"|2= <nowiki>Generating public/private ecdsa key pair.<br />
Enter file in which to save the key (/home/username/.ssh/id_ecdsa):<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /home/username/.ssh/id_ecdsa.<br />
Your public key has been saved in /home/username/.ssh/id_ecdsa.pub.<br />
The key fingerprint is:<br />
dd:15:ee:24:20:14:11:01:b8:72:a2:0f:99:4c:79:7f username@localhost-2011-12-22<br />
The key's randomart image is:<br />
+--[ECDSA 521]---+<br />
| ..oB=. . |<br />
| . . . . . |<br />
| . . . + |<br />
| oo.o . . = |<br />
|o+.+. S . . . |<br />
|=. . E |<br />
| o . |<br />
| . |<br />
| |<br />
+-----------------+</nowiki>}}<br />
<br />
In the above example, {{ic|ssh-keygen}} generates a 521 bit long ({{ic|-b 521}}) public/private ECDSA ({{ic|-t ecdsa}}) key pair with an extended comment including the data ({{ic|-C"$(id -un)"@$(hostname)-$(date --rfc-3339&#61;date)}}). The [http://www.cs.berkeley.edu/~dawnsong/papers/randomart.pdf randomart image] was introduced in OpenSSH 5.1 as an easier means of visually identifying the key fingerprint.<br />
<br />
===Choosing the type of encryption===<br />
The Elliptic Curve Digital Signature Algorithm (ECDSA) provides smaller key sizes and faster operations for equivalent estimated security to the previous methods. It was introduced as the preferred algorithm for authentication in OpenSSH 5.7, see [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]. ECDSA keys might not be compatible with systems that ship old versions of OpenSSH. Some vendors also disable the required implementations due to potential patent issues.<br />
<br />
If you choose to create an RSA (2048-4096 bit) or DSA (1024 bit) key pair instead of ECDSA, use the {{ic|-t rsa}} or {{ic|-t dsa}} switches in your {{ic|ssh-keygen}} command and do not forget to increase the key size. Running {{ic|ssh-keygen}} without the {{ic|-b}} switch should provide reasonable defaults.<br />
<br />
{{Note|These keys are used only to authenticate you, choosing stronger keys will not increase CPU load when transferring data over SSH.}}<br />
<br />
===Choosing the key location and passphrase===<br />
Upon issuing the {{ic|ssh-keygen}} command, you will be prompted for the desired name an location of your private key. By default, keys are stored in the {{ic|~/.ssh/}} directory and named according the type of encryption used. You are advised to accept the default name and location in order for later code examples in this article to work properly.<br />
<br />
When prompted for a passphrase, choose something that will be hard to guess if you have the security of your private key in mind. A longer, more random password will generally be stronger and harder to crack should it fall into the wrong hands.<br />
<br />
It is also possible to create your private key without a passphrase. While this can be convenient, you need to be aware of the associated risks. Without a passphrase, your private key will be stored on disk in an unencrypted form. Anyone who gains access to your private key file will then be able to assume your identity on any SSH server to which you connect using key-based authentication. Furthermore, without a passphrase, you must also trust the root user, as he can bypass file permissions and will be able to access your unencrypted private key file at any time.<br />
<br />
==Copying the public key to the remote server==<br />
Once you have generated a key pair, you will need to copy the public key to the remote server so that it will use SSH key authentication. The public key file shares the same name as the private key except that is appended with a {{ic|.pub}} extension. Note that the private key is not shared and remains on the local machine.<br />
<br />
===Simple method===<br />
If your key file is {{ic|~/.ssh/id_rsa.pub}} you can simply enter the following command.<br />
$ ssh-copy-id remote-server.org<br />
<br />
If your username differs on remote machine, be sure to prepend the username followed by {{ic|@}} to the server name.<br />
$ ssh-copy-id username@remote-server.org<br />
<br />
If your public key filename is anything other than the default of {{ic|~/.ssh/id_rsa.pub}} you will get an error stating {{ic|/usr/bin/ssh-copy-id: ERROR: No identities found}}. In this case, you must explicitly provide the location of the public key.<br />
$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub username@remote-server.org<br />
<br />
If the ssh server is listening on a port other than default of 22, be sure to include it within the host argument.<br />
$ ssh-copy-id -i ~/.ssh/id_rsa.pub '-p 221 username@remote-server.org'<br />
<br />
===Traditional method===<br />
By default, for OpenSSH, the public key needs to be concatenated with {{ic|~/.ssh/authorized_keys}}. Begin by copying the public key to the remote server.<br />
<br />
$ scp ~/.ssh/id_ecdsa.pub username@remote-server.org:<br />
<br />
The above example copies the public key ({{ic|id_ecdsa.pub}}) to your home directory on the remote server via {{ic|scp}}. Do not forget to include the {{ic|:}} at the end of the server address. Also note that the name of your public key may differ from the example given.<br />
<br />
On the remote server, you will need to create the {{ic|~/.ssh}} directory if it does not yet exist and append your public key to the {{ic|authorized_keys}} file.<br />
<br />
$ ssh username@remote-server.org<br />
username@remote-server.org's password:<br />
$ mkdir ~/.ssh<br />
$ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys<br />
$ rm ~/id_ecdsa.pub<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
The last two commands remove the public key file from the server and set the permissions on the {{ic|authorized_keys}} file such that it is only readable and writable by you, the owner.<br />
<br />
Disconnect from the server and then attempt to reconnect. You should now be asked for the passphrase of the key.<br />
<br />
$ ssh username@remote-server.org<br />
Enter passphrase for key '/home/username/.ssh/id_ecdsa':<br />
<br />
If you are unable to login with the key, double check the permissions on the {{ic|authorized_keys}} file.<br />
<br />
Also check the permissions on the {{ic|~/.ssh}} directory, which should have write permissions off for 'group' and 'other'. Run the following command to disable 'group' and 'other' write permissions for the {{ic|~/.ssh}} directory.<br />
$ chmod go-w ~/.ssh<br />
<br />
==Disabling password logins==<br />
While copying your public key to the remote SSH server eliminates the need to transmit your password over the network, it does not give any added protection against a brute-force password attack. In the absense of a private key, the SSH server will fall back to password authentication by default, thus allowing a malicious user to attempt to gain access by guessing your password. To disable this behavior, edit the following lines in the {{ic|/etc/ssh/sshd_config}} file on the remote server.<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
PasswordAuthentication no<br />
ChallengeResponseAuthentication no}}<br />
<br />
==SSH agents==<br />
If your private key is encrypted with a passphrase, this passphrase must be entered every time you attempt to connect to an SSH server using public-key authentication. Each individual invocation of {{ic|ssh}} or {{ic|scp}} will need the passphrase in order to decrypt your private key before authentication can proceed.<br />
<br />
An SSH agent is a program which caches your decrypted private keys and provides them to SSH client programs on your behalf. In this arrangement, you must only provide your passphrase once, when adding your private key to the agent's cache. This facility can be of great convenience when making frequent SSH connections.<br />
<br />
An agent is typically configured to run automatically upon login and persist for the duration of your login session. A variety of agents, front-ends, and configurations exist to achieve this effect. This section provides an overview of a number of different solutions which can be adapted to meet your specific needs.<br />
<br />
===ssh-agent===<br />
ssh-agent is the default agent included with OpenSSH. It can be used directly or serve as the back-end to a few of the front-end solutions mentioned later in this section. When {{ic|ssh-agent}} is run, it will fork itself to the background and print out the environment variables it would use.<br />
<br />
$ ssh-agent<br />
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;<br />
SSH_AGENT_PID=2148; export SSH_AGENT_PID;<br />
echo Agent pid 2148;<br />
<br />
To make use of these variables, run the command through the {{ic|eval}} command.<br />
<br />
$ eval $(ssh-agent)<br />
Agent pid 2157<br />
<br />
You can append the above command to your {{ic|~/.bash_profile}} script so that it will run automatically when starting a login shell.<br />
<br />
$ echo 'eval $(ssh-agent)' >> ~/.bash_profile<br />
<br />
If you would rather have ssh-agent run automatically for all users append the command to {{ic|/etc/profile}} instead.<br />
<br />
# echo 'eval $(ssh-agent)' >> /etc/profile<br />
<br />
Once {{ic|ssh-agent}} is running, you will need to add your private key to its cache.<br />
<br />
$ ssh-add ~/.ssh/id_ecdsa<br />
Enter passphrase for /home/user/.ssh/id_ecdsa:<br />
Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)<br />
<br />
If you would like your private keys to be added automatically on login. Append the following command to your {{ic|~/.bash_profile}} as well.<br />
<br />
$ echo 'ssh-add' >> ~/.bash_profile<br />
<br />
If your private key is encrypted {{ic|ssh-add}} will prompt you to enter your passphrase. Once your private key has been successfully added to the agent you will be able to make SSH connections without having to enter a passphrase.<br />
<br />
One downside to this approach is that a new instance of {{ic|ssh-agent}} is created for every login shell and each instance will persist between login sessions. Over time you can wind up with dozens of needless {{ic|ssh-agent}} processes running. There exist a number of front-ends to ssh-agent and alternative agents described later in this section which avoid this problem.<br />
<br />
===GnuPG Agent===<br />
<br />
The [[GnuPG]] agent, distributed with the {{Pkg|gnupg2}} package, available in the [[Official Repositories]], has OpenSSH agent emulation. If you use GPG you might consider using its agent to take care of all of your keys. Otherwise you might like the PIN entry dialog it provides and its passphrase management, which is different from Keychain.<br />
<br />
To start using GPG agent for your SSH keys you should first start the gpg-agent with the {{ic|--enable-ssh-support}} option. Example (do not forget to make the file executable):<br />
{{hc|/etc/profile.d/gpg-agent.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Start the GnuPG agent and enable OpenSSH agent emulation<br />
gnupginf="${HOME}/.gnupg/gpg-agent.info"<br />
<br />
if pgrep -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
eval `cat $gnupginf`<br />
eval `cut -d= -f1 $gnupginf | xargs echo export`<br />
else<br />
eval `gpg-agent --enable-ssh-support --daemon`<br />
fi<br />
</nowiki>}}<br />
<br />
Once gpg-agent is running you can use ssh-add to approve keys, just like you did with plain ssh-agent. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved you will get a PIN entry dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have gpg-agent cache your keys for 3 hours: <br />
<br />
# Cache settings<br />
default-cache-ttl 10800<br />
default-cache-ttl-ssh 10800<br />
<br />
Other useful settings for this file include the PIN entry program (GTK, QT or ncurses version), keyboard grabbing and so on...:<br />
<br />
# Environment file<br />
write-env-file /home/username/.gnupg/gpg-agent.info<br />
<br />
# Keyboard control<br />
#no-grab<br />
<br />
# PIN entry program<br />
#pinentry-program /usr/bin/pinentry-curses<br />
#pinentry-program /usr/bin/pinentry-qt4<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
<br />
===Keychain===<br />
[http://www.funtoo.org/en/security/keychain/intro/ Keychain] is a program designed to help you easily manage your SSH keys with minimal user interaction. It is implemented as a shell script which drives both {{ic|ssh-agent}} and {{ic|ssh-add}}. A notable feature of Keychain is that it can maintain a single {{ic|ssh-agent}} process across multiple login sessions. This means that you only need to enter your passphrase once each time your local machine is booted.<br />
<br />
[[pacman|Install]] the {{Pkg|keychain}} package, available from the [[Official Repositories]].<br />
<br />
Append the following line to {{ic|~/.bash_profile}}, or create {{ic|/etc/profile.d/keychain.sh}} as root and make it executable (e.g. {{ic|chmod 755 keychain.sh}}):<br />
{{hc|~/.bash_profile|<br />
eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa)<br />
}}<br />
<br />
In the above example, the {{ic|--eval}} switch outputs lines to be evaluated by the opening {{ic|eval}} command. This sets the necessary environments variables for SSH client to be able to find your agent. The {{ic|--agents}} switch is not strictly necessary, because Keychain will build the list automatically based on the existence of ssh-agent or gpg-agent on the system. Adding the {{ic|--quiet}} switch will limit output to warnings, errors, and user prompts. If you want greater security replace {{ic|-Q}} with {{ic|--clear}} but will be less convenient.<br />
<br />
If necessary, replace {{ic|~/.ssh/id_ecdsa}} with the path to your private key. For those using a non-Bash compatible shell, see {{ic|keychain --help}} or {{ic|man keychain}} for details on other shells.<br />
<br />
To test Keychain, log out from your session and log back in. If this is your first time running Keychain, it will prompt you for the passphrase of the specified private key. Because Keychain reuses the same {{ic|ssh-agent}} process on successive logins, you shouldn't have to enter your passphrase the next time you log in. You will only ever be prompted for your passphrase once each time the machine is rebooted.<br />
<br />
====Alternate startup methods====<br />
There are numerous ways in which Keychain can be invoked and you are encouraged to experiment to find a method that works for you. The {{ic|keychain}} command itself comes with dozens of command-line options which are described in the Keychain man page.<br />
<br />
One alternative implementation of a Keychain startup script could be to create the file {{ic|/etc/profile.d/keychain.sh}} as the root user and add the following lines.<br />
<br />
{{hc|/etc/profile.d/keychain.sh|<nowiki><br />
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_ecdsa<br />
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh<br />
</nowiki>}}<br />
<br />
Be sure to also make {{ic|/etc/profile.d/keychain.sh}} executable by changing its file permissions.<br />
# chmod 755 /etc/profile.d/keychain.sh<br />
<br />
If you do not want to get asked for your passphrase every time you login but rather the first time you actually attempt to connect, you may add the following to your {{ic|.bashrc}}:<br />
alias ssh='eval $(/usr/bin/keychain --eval --agents ssh -Q --quiet .ssh/id_rsa) && ssh'<br />
This will ask you if you try to use ssh for the first time. Remember however that this will ONLY ask you if {{ic|.bashrc}} is applicable. So you would always have your first ssh-command to be executed in a terminal.<br />
<br />
===x11-ssh-askpass===<br />
The x11-ssh-askpass package provides a graphical dialog for entering your passhrase when running an X session. x11-ssh-askpass depends only the {{Pkg|libx11}} and {{Pkg|libxt}} libraries, and the appearance of x11-ssh-askpass is customizable. While it can be invoked by the {{ic|ssh-add}} program which will then load your decrypted keys into [[#ssh-agent|ssh-agent]], the following instructions will instead configure x11-ssh-askpass to be invoked by the aforementioned [[#Keychain|Keychain]] script.<br />
<br />
Install {{Pkg|keychain}} and {{Pkg|x11-ssh-askpass}}, both available in the [[Official Repositories]].<br />
<br />
Edit your {{ic|~/.xinitrc}} file to include the lines highlighted in bold, replacing the name and location of your private if necessary. Be sure to place these commands '''before''' the line which invokes your window mananger.<br />
<br />
{{hc|~/.xinitrc|<br />
'''keychain ~/.ssh/id_ecdsa'''<br />
'''[ -f ~/.keychain/$HOSTNAME-sh ] && . ~/.keychain/$HOSTNAME-sh 2>/dev/null'''<br />
'''[ -f ~/.keychain/$HOSTNAME-sh-gpg ] && . ~/.keychain/$HOSTNAME-sh-gpg 2>/dev/null'''<br />
...<br />
exec openbox-session}}<br />
<br />
In the above example, the first line invokes {{ic|keychain}} and passes the name and location of your private key. If this is not the first time keychain was invoked, the following two lines load the contents of {{ic|$HOSTNAME-sh}} and {{ic|$HOSTNAME-sh-gpg}} if they exist. These files store the environment variables of the previous instance of {{ic|keychain}}.<br />
<br />
====Theming====<br />
The appearance of the x11-ssh-askpass dialog can be customized by setting its associated [[X resources]]. The x11-ssh-askpass [http://www.jmknoble.net/software/x11-ssh-askpass/ homepage] presents some example [http://www.jmknoble.net/software/x11-ssh-askpass/screenshots.html example themes]. See the x11-ssh-askpass man page for full details.<br />
<br />
====Alternative passphrase dialogs====<br />
There are other passphrase dialog programs which can be used instead of x11-ssh-askpass. The following list provides some alternative solutions.<br />
<br />
* {{Pkg|ksshaskpass}} is available in the Official Repositories. It is dependent on {{Pkg|kdelibs}} and is suitable for the KDE Desktop Environment.<br />
<br />
* {{Pkg|openssh-askpass}} depends on the {{Pkg|qt}} libraries, and is available from the Official Repositories.<br />
<br />
===pam_ssh===<br />
The [http://pam-ssh.sourceforge.net/ pam_ssh] project exists to provide a [[Wikipedia:Pluggable authentication module|Pluggable Authentication Module]] (PAM) for SSH private keys. This module can provide single sign-on behavior for your SSH connections. On login, your SSH private key passphrase can be entered in place of, or in addition to, your traditional system password. Once you have been authenticated, the pam_ssh module spawns ssh-agent to store your decrypted private key for the duration of the session.<br />
<br />
To enable single sign-on behavior at the tty login prompt, install the unofficial {{AUR|pam_ssh}} package, available in the [[Arch User Repository]]. <br />
<br />
Edit the {{ic|/etc/pam.d/login}} configuration file to include the text highlighted in bold in the example below. The order in which these lines appear is significiant and can affect login behavior.<br />
<br />
{{Warning|Misconfiguring PAM can leave the system in a state where all users become locked out. Before making any changes, you should have an understanding of how PAM configuration works as well as a backup means of accessing the PAM configuration files, such as an Arch Live CD, in case you become locked out and need to revert any changes. An IBM developerWorks [http://www.ibm.com/developerworks/linux/library/l-pam/index.html article] is available which explains PAM configuration in further detail.}}<br />
<br />
{{hc|/etc/pam.d/login|2=<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
'''auth sufficient pam_ssh.so'''<br />
auth required pam_unix.so nullok '''use_first_pass'''<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
# use this to lockout accounts for 10 minutes after 3 failed attempts<br />
#auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
account required pam_access.so<br />
account required pam_time.so<br />
account required pam_unix.so<br />
#password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3<br />
#password required pam_unix.so sha512 shadow use_authtok<br />
session required pam_unix.so<br />
session required pam_env.so<br />
session required pam_motd.so<br />
session required pam_limits.so<br />
session optional pam_mail.so dir=/var/spool/mail standard<br />
session optional pam_lastlog.so<br />
session optional pam_loginuid.so<br />
'''session optional pam_ssh.so'''<br />
-session optional pam_ck_connector.so nox11<br />
-session optional pam_systemd.so<br />
}}<br />
<br />
In the above example, login uses pam_ssh to check the entered password against the user's SSH private key passphrase. If the password matches, the user is immediately granted access to the system. If the password does not match, control falls to the pam_unix module which provides traditional password authentication. Because the {{ic|use_first_pass}} option is set, the pam_unix module checks the previously entered password against the {{ic|/etc/passwd}} file instead of asking for a password again. In this way, pam_ssh will be transparent to users without an SSH private key.<br />
<br />
If you use a another means of logging in, such as an X11 display manager like [[SLiM]] or [[XDM]] and you would like it to provide similar functionality, you must edit its associated PAM configuration file in a similar fashion. Packages providing support for PAM typically place a default configuration file in the {{ic|/etc/pam.d/}} directory.<br />
<br />
Further details on how to use pam_ssh and a list of its options can be found in the pam_ssh man page.<br />
<br />
====Known issues with pam_ssh====<br />
Work on the pam_ssh project is infrequent and the documentation provided is sparse. You should be aware of some of its limitations which are not mentioned in the package itself.<br />
<br />
* SSH keys employing the newer option of ECDSA (elliptic curve) cryptography do not appear to be supported by pam_ssh. You must use either RSA or DSA keys.<br />
<br />
* The {{ic|ssh-agent}} process spawned by pam_ssh does not persist between user logins. If you like to keep a [[GNU Screen]] session active between logins you may notice when reattaching to your screen session that it can no longer communicate with ssh-agent. This is because the GNU Screen environment and those of its children will still reference the instance of ssh-agent which existed when GNU Screen was invoked but was subsequently killed in a previous logout. The [[#keychain|Keychain]] front-end avoids this problem by keeping the ssh-agent process alive between logins.<br />
<br />
===GNOME Keyring===<br />
If you use the [[GNOME]] desktop, the [[GNOME Keyring]] tool can be used as an SSH agent. Visit the [[GNOME Keyring]] article.<br />
<br />
==Troubleshooting==<br />
If it appears that the SSH server is ignoring your keys, ensure that you have the proper permissions set on all relevant files.<br />
<br />
For the local machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/id_ecdsa<br />
<br />
For the remote machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
Failing this, run the sshd in debug mode and monitor the output while connecting:<br />
<br />
# /usr/sbin/sshd -d<br />
<br />
==Using kdm==<br />
It appears that kdm doesn't launch the ssh-agent process directly. You need to install the package kde-agent:<br />
<br />
pacman -S kde-agent<br />
<br />
==See also==<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc.html OpenSSH key management, Part 1]<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ OpenSSH key management, Part 2]<br />
* [http://www-106.ibm.com/developerworks/library/l-keyc3/ OpenSSH key management, Part 3]<br />
* [http://kimmo.suominen.com/docs/ssh/ Getting started with SSH]<br />
* [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]</div>Philfifihttps://wiki.archlinux.org/index.php?title=Munin&diff=128920Munin2011-01-24T22:53:24Z<p>Philfifi: Configure munin email</p>
<hr />
<div>[[Category:Daemons and system services (English)]]<br />
[[Category:HOWTOs (English)]]<br />
'''''[http://munin-monitoring.org/ Munin]''' the monitoring tool surveys all your computers and remembers what it saw. It presents all the information in graphs through a web interface. Its emphasis is on plug and play capabilities. After completing a installation a high number of monitoring plugins will be playing with no more effort.''<br />
<br />
''Using Munin you can easily monitor the performance of your computers, networks, SANs, applications, weather measurements and whatever comes to mind. It makes it easy to determine "what's different today" when a performance problem crops up. It makes it easy to see how you're doing capacity-wise on any resources.''<br />
<br />
''Munin uses the excellent [http://oss.oetiker.ch/rrdtool/ RRDTool] (written by Tobi Oetiker) and the framework is written in Perl, while plugins may be written in any language. Munin has a master/node architecture in which the master connects to all the nodes at regular intervals and asks them for data. It then stores the data in RRD files, and (if needed) updates the graphs. One of the main goals has been ease of creating new plugins (graphs).'' [http://munin-monitoring.org/]<br />
<br />
Simply put, Munin allows you to make graphs about system statistics. You can check out University of Oslo's [http://munin.ping.uio.no/ Munin install] to see some examples of what it can do.<br />
<br />
== Installation ==<br />
<br />
Munin relies on a client-server model. The client is munin-node, and the server is munin (referred as to "munin-master" in the documentation).<br />
<br />
You will only need to install munin-master on a single machine, but munin-node will need to be installed on all machines you wish to monitor. This article will focus on a single-machine installation. Further documentation may be found on the [http://munin-monitoring.org/wiki/Documentation Munin documentation wiki].<br />
<br />
=== munin and munin-node ===<br />
<br />
There is currently a munin (munin-master) and a munin-node package in extra.<br />
<br />
# pacman -S munin munin-node<br />
<br />
=== Optional web server ===<br />
<br />
The following guide sets up Munin to generate static HTML and graph images and write them in a directory of your choosing. You can view these generated files locally with any web browser. If you want to view the generated files from a remote machine, then you want to install and configure one of the following web servers:<br />
<br />
*[[LAMP|Apache]]<br />
*[[Lighttpd]]<br />
*[[NginX]]<br />
<br />
Or one of the other servers found in the [[:Category:Web_Server_(English)|web server]] category.<br />
<br />
== Configuration ==<br />
<br />
=== Daemon ===<br />
<br />
Add the daemon to /etc/rc.conf:<br />
<br />
DAEMONS=(syslog-ng network netfs crond httpd '''munin-node''')<br />
<br />
=== Plugins ===<br />
<br />
Run munin-node-configure with the --suggest option to have Munin suggest plugins that it thinks will work on your installation:<br />
<br />
# munin-node-configure --suggest<br />
<br />
If there is a suggestion for a plugin you want to use, follow that suggestion and run the command again. When you are satisfied with the plugins suggested by munin-node-configure, run it with the --shell option to have the plugins configured:<br />
<br />
# munin-node-configure --shell | sh<br />
<br />
=== Directories ===<br />
<br />
Create a directory where the munin-master will write the generated HTML and graph images. The munin user must have write permission to this directory.<br />
<br />
/srv/http/munin is used below, so the generated output can be viewed at [http://localhost/munin/ http://localhost/munin/] provided that a web server is installed and running.<br />
<br />
# mkdir /srv/http/munin<br />
# chown munin:munin /srv/http/munin<br />
<br />
Uncomment the htmldir entry in /etc/munin/munin.conf and change it to the directory created in the previous step:<br />
<br />
htmldir /srv/http/munin<br />
<br />
=== Customization ===<br />
<br />
Before running munin, you might want to setup the hostname of your system. In /etc/munin/munin.conf, the default hostname is "myhostname". This can be altered to any preferred host name. The hostname will be used to group and name the .rrd files in /var/lib/munin and further, used to group the html files and graphs in your selected munin-master directory.<br />
<br />
=== Cron ===<br />
<br />
Run the following to have munin collect data and update the generated HTML and graph images every 5 minutes:<br />
<br />
# crontab /etc/munin/munin-cron-entry -u munin<br />
<br />
<br />
Configure your email server so that you can receive mails to "munin" user. If you use postfix, add this line in /etc/postfix/aliases<br />
<br />
munin: root<br />
<br />
And run the command<br />
<br />
newaliases<br />
<br />
== Testing ==<br />
<br />
Munin should be able to run now. To make sure everything works, start munin-node:<br />
<br />
#/etc/rc.d/munin-node start<br />
<br />
Then run munin-cron manually to generate the HTML and graph images:<br />
<br />
# su - munin --shell=/bin/bash<br />
$ munin-cron<br />
<br />
And finally test the interface by pointing your browser to the output directory or [http://localhost/munin/ http://localhost/munin/].<br />
<br />
{{Note|It might take a while for the graphs to have data, so be patient. Wait for about 30 minutes to an hour.}}<br />
<br />
== Plugins ==<br />
<br />
There are many Munin plugins out there just waiting to be installed. The [http://muninexchange.projects.linpro.no/ MuninExchange] is an excellent place to start looking, and if you can't find a plugin that does what you want it's easy to write your own. Have a look at [http://munin-monitoring.org/wiki/HowToWritePlugins HowToWritePlugins] at the Munin documentation wiki to learn how.<br />
<br />
=== Adding ===<br />
<br />
Basically all plugins are added in the following manner (although there are exceptions, review each plugin!):<br />
<br />
Download a plugin, then copy or move it to /usr/lib/munin/plugins<br />
<br />
# cp <plugin> /usr/lib/munin/plugins/<br />
<br />
Then link the plugin to /etc/munin/plugins:<br />
<br />
# ln -s /usr/lib/munin/plugins/<plugin> /etc/munin/plugins/<plugin><br />
<br />
{{Note|Some plugins - known as wildcard plugins - can be used with multiple devices at once by linking them with different names. These plugins end with an underscore and are linked as <plugin>_<device> to be used on <device>. See the if_ plugin for an example.}}<br />
<br />
Now test your plugin. You do not need to use the full path to the plugin, munin-run should be able to figure it out:<br />
<br />
# munin-run <plugin><br />
<br />
And restart munin-node:<br />
<br />
# /etc/rc.d/munin-node restart<br />
<br />
Finally, refresh the web page.<br />
<br />
=== Removing ===<br />
<br />
If you want to remove a plugin, simply delete the linked file in /etc/munin/plugins - there is no need to remove the plugin from /usr/lib/munin/plugins.<br />
<br />
# rm /etc/munin/plugins/<plugin></div>Philfifihttps://wiki.archlinux.org/index.php?title=Munin&diff=128908Munin2011-01-24T19:40:52Z<p>Philfifi: No need, because repeated just above</p>
<hr />
<div>[[Category:Daemons and system services (English)]]<br />
[[Category:HOWTOs (English)]]<br />
'''''[http://munin-monitoring.org/ Munin]''' the monitoring tool surveys all your computers and remembers what it saw. It presents all the information in graphs through a web interface. Its emphasis is on plug and play capabilities. After completing a installation a high number of monitoring plugins will be playing with no more effort.''<br />
<br />
''Using Munin you can easily monitor the performance of your computers, networks, SANs, applications, weather measurements and whatever comes to mind. It makes it easy to determine "what's different today" when a performance problem crops up. It makes it easy to see how you're doing capacity-wise on any resources.''<br />
<br />
''Munin uses the excellent [http://oss.oetiker.ch/rrdtool/ RRDTool] (written by Tobi Oetiker) and the framework is written in Perl, while plugins may be written in any language. Munin has a master/node architecture in which the master connects to all the nodes at regular intervals and asks them for data. It then stores the data in RRD files, and (if needed) updates the graphs. One of the main goals has been ease of creating new plugins (graphs).'' [http://munin-monitoring.org/]<br />
<br />
Simply put, Munin allows you to make graphs about system statistics. You can check out University of Oslo's [http://munin.ping.uio.no/ Munin install] to see some examples of what it can do.<br />
<br />
== Installation ==<br />
<br />
Munin relies on a client-server model. The client is munin-node, and the server is munin (referred as to "munin-master" in the documentation).<br />
<br />
You will only need to install munin-master on a single machine, but munin-node will need to be installed on all machines you wish to monitor. This article will focus on a single-machine installation. Further documentation may be found on the [http://munin-monitoring.org/wiki/Documentation Munin documentation wiki].<br />
<br />
=== munin and munin-node ===<br />
<br />
There is currently a munin (munin-master) and a munin-node package in extra.<br />
<br />
# pacman -S munin munin-node<br />
<br />
=== Optional web server ===<br />
<br />
The following guide sets up Munin to generate static HTML and graph images and write them in a directory of your choosing. You can view these generated files locally with any web browser. If you want to view the generated files from a remote machine, then you want to install and configure one of the following web servers:<br />
<br />
*[[LAMP|Apache]]<br />
*[[Lighttpd]]<br />
*[[NginX]]<br />
<br />
Or one of the other servers found in the [[:Category:Web_Server_(English)|web server]] category.<br />
<br />
== Configuration ==<br />
<br />
=== Daemon ===<br />
<br />
Add the daemon to /etc/rc.conf:<br />
<br />
DAEMONS=(syslog-ng network netfs crond httpd '''munin-node''')<br />
<br />
=== Plugins ===<br />
<br />
Run munin-node-configure with the --suggest option to have Munin suggest plugins that it thinks will work on your installation:<br />
<br />
# munin-node-configure --suggest<br />
<br />
If there is a suggestion for a plugin you want to use, follow that suggestion and run the command again. When you are satisfied with the plugins suggested by munin-node-configure, run it with the --shell option to have the plugins configured:<br />
<br />
# munin-node-configure --shell | sh<br />
<br />
=== Directories ===<br />
<br />
Create a directory where the munin-master will write the generated HTML and graph images. The munin user must have write permission to this directory.<br />
<br />
/srv/http/munin is used below, so the generated output can be viewed at [http://localhost/munin/ http://localhost/munin/] provided that a web server is installed and running.<br />
<br />
# mkdir /srv/http/munin<br />
# chown munin:munin /srv/http/munin<br />
<br />
Uncomment the htmldir entry in /etc/munin/munin.conf and change it to the directory created in the previous step:<br />
<br />
htmldir /srv/http/munin<br />
<br />
=== Customization ===<br />
<br />
Before running munin, you might want to setup the hostname of your system. In /etc/munin/munin.conf, the default hostname is "myhostname". This can be altered to any preferred host name. The hostname will be used to group and name the .rrd files in /var/lib/munin and further, used to group the html files and graphs in your selected munin-master directory.<br />
<br />
=== Cron ===<br />
<br />
Run the following to have munin collect data and update the generated HTML and graph images every 5 minutes:<br />
<br />
# crontab /etc/munin/munin-cron-entry -u munin<br />
<br />
== Testing ==<br />
<br />
Munin should be able to run now. To make sure everything works, start munin-node:<br />
<br />
#/etc/rc.d/munin-node start<br />
<br />
Then run munin-cron manually to generate the HTML and graph images:<br />
<br />
# su - munin --shell=/bin/bash<br />
$ munin-cron<br />
<br />
And finally test the interface by pointing your browser to the output directory or [http://localhost/munin/ http://localhost/munin/].<br />
<br />
{{Note|It might take a while for the graphs to have data, so be patient. Wait for about 30 minutes to an hour.}}<br />
<br />
== Plugins ==<br />
<br />
There are many Munin plugins out there just waiting to be installed. The [http://muninexchange.projects.linpro.no/ MuninExchange] is an excellent place to start looking, and if you can't find a plugin that does what you want it's easy to write your own. Have a look at [http://munin-monitoring.org/wiki/HowToWritePlugins HowToWritePlugins] at the Munin documentation wiki to learn how.<br />
<br />
=== Adding ===<br />
<br />
Basically all plugins are added in the following manner (although there are exceptions, review each plugin!):<br />
<br />
Download a plugin, then copy or move it to /usr/lib/munin/plugins<br />
<br />
# cp <plugin> /usr/lib/munin/plugins/<br />
<br />
Then link the plugin to /etc/munin/plugins:<br />
<br />
# ln -s /usr/lib/munin/plugins/<plugin> /etc/munin/plugins/<plugin><br />
<br />
{{Note|Some plugins - known as wildcard plugins - can be used with multiple devices at once by linking them with different names. These plugins end with an underscore and are linked as <plugin>_<device> to be used on <device>. See the if_ plugin for an example.}}<br />
<br />
Now test your plugin. You do not need to use the full path to the plugin, munin-run should be able to figure it out:<br />
<br />
# munin-run <plugin><br />
<br />
And restart munin-node:<br />
<br />
# /etc/rc.d/munin-node restart<br />
<br />
Finally, refresh the web page.<br />
<br />
=== Removing ===<br />
<br />
If you want to remove a plugin, simply delete the linked file in /etc/munin/plugins - there is no need to remove the plugin from /usr/lib/munin/plugins.<br />
<br />
# rm /etc/munin/plugins/<plugin></div>Philfifihttps://wiki.archlinux.org/index.php?title=MariaDB&diff=125707MariaDB2010-12-21T21:57:12Z<p>Philfifi: mysql gui tools in AUR instead of community</p>
<hr />
<div>[[Category:Daemons and system services (English)]]<br />
[[Category:Database management systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|MySQL}}<br />
[[de:MySQL]]<br />
<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 />
== Installation ==<br />
Install the mysql package:<br />
# pacman -S mysql<br />
After installing MySQL you should run the setup script as root:<br />
# /etc/rc.d/mysqld start && mysql_secure_installation<br />
<br />
Then restart MySQL:<br />
# /etc/rc.d/mysqld restart<br />
<br />
To start MySQL automatically at boot, edit /etc/rc.conf and add the mysqld daemon:<br />
DAEMONS=(... mysqld ...)<br />
<br />
== Configuration ==<br />
Once you've 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 login as root into your MySQL server:<br />
$ mysql -p -u root<br />
<br />
To start MySQL at bootup add {{Codeline|mysqld}} to the list of daemons in {{Filename|/etc/rc.conf}} or add {{Codeline|/etc/rc.d/mysqld start}} to {{Filename|/etc/rc.local}}.<br />
<br />
=== Enable remote access ===<br />
The MySQL server does not listen on the TCP port 3306 by default. To allow (remote) TCP connections, comment the following line in {{Filename|/etc/mysql/my.cnf}}:<br />
skip-networking<br />
Remember to edit {{Filename|/etc/hosts.allow}} by adding the following lines: <br />
mysqld: ALL : ALLOW<br />
mysqld-max: ALL : ALLOW<br />
<br />
== Upgrading ==<br />
Might consider to run this command after you have upgraded MySQL:<br />
# mysql_upgrade -u root -p<br />
<br />
== Troubleshooting ==<br />
=== Mysql daemon can't start ===<br />
If you see something like this:<br />
# /etc/rc.d/mysqld restart<br />
:: Stopping MySQL [FAIL] <br />
:: Starting MySQL [FAIL]<br />
and no entry in log files, you might check permission of files in directories {{Filename|/var/lib/mysql}} and {{Filename|/var/lib/mysql/mysql}}. If owner of files in this directories isn't mysql:mysql, you should do following:<br />
# chown mysql:mysql /var/lib/mysql -R<br />
If you run into permission problems despite having followed the above ensure that your {{Filename|my.cnf}} is copied to /etc/:<br />
# cp /etc/mysql/my.cnf /etc/my.cnf<br />
Now try and restart the daemon.<br />
<br />
If you get these messages in your {{Filename|/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 />
you should change permissions of {{Filename|/var/run/mysqld}} like so:<br />
# chown mysql:mysql /var/run/mysqld -R<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 to install the default tables:<br />
# mysql_install_db --user=mysql --ldata=/var/lib/mysql/<br />
<br />
=== Unable to run mysql_upgrade cause MySQL can't 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 />
=== How to Reset the Root Password ===<br />
Stop mysqld daemon<br />
# /etc/rc.d/mysqld stop<br />
# mysqld_safe --skip-grant-tables &<br />
Connect to mysql server<br />
# mysql -u root mysql<br />
Change root password:<br />
mysql> UPDATE user SET password=PASSWORD("NEW_PASSWORD") WHERE User='root';<br />
mysql> FLUSH PRIVILEGES;<br />
mysql> exit<br />
Then restart daemon:<br />
# /etc/rc.d/mysqld restart<br />
You're done<br />
<br />
=== General MySQL Connectivity ===<br />
Check /var/run/mysqld for mysql'''d'''.sock and /tmp for mysql.sock.<br />
If mysql.sock doesn't exist, create a softlink:<br />
# ln -s /var/run/mysqld/mysqld.sock /tmp/mysql.sock<br />
<br />
== More Resources ==<br />
* [[LAMP]] - Arch wiki article covering the setup of a LAMP server (Linux Apache MySQL PHP)<br />
* http://www.mysql.com/<br />
* Frontend [http://aur.archlinux.org/packages.php?ID=42212 aur/mysql-gui-tools] [http://www.archlinux.org/packages/?q=mysql-workbench community/mysql-workbench]</div>Philfifihttps://wiki.archlinux.org/index.php?title=Compiz_Fusion&diff=65573Compiz Fusion2009-03-23T11:43:07Z<p>Philfifi: add gconf config needed for me.</p>
<hr />
<div>[[Category:Eye candy (English)]]<br />
[[Category:Desktop environments (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|:Compiz Fusion}}<br />
{{i18n_entry|Ελληνικά|:Compiz Fusion (Ελληνικά)}}<br />
{{i18n_entry|Português de Brasil|:Compiz Fusion (Português)}}<br />
{{i18n_entry|简体中文|Compiz Fusion(简体中文)}}<br />
{{i18n_entry|Türkçe|:Compiz fusion (Türkçe)}}<br />
{{i18n_links_end}}<br />
<br />
= Introduction =<br />
Compiz Fusion is a project that aims to add more functionality to Compiz by extending it with more plugins, tools and libraries.<br />
<br />
= Installation =<br />
Basic installation can be done using community as repo (see below).<br />
<br />
The second way is using nesl's git packages. See [[Compiz_Fusion_Git]] for more information.<br />
<br />
== Install from Community ==<br />
Make sure the Community repository is enabled and run this command as root to install everything:<br />
# pacman -S compiz-fusion<br />
Run this if you only want gtk-based packages installed:<br />
# pacman -S compiz-fusion-gtk<br />
or this if you only want kde-based packages installed:<br />
# pacman -S compiz-fusion-kde <br />
<br />
If you want select the packages individually, here is a list:<br />
<br />
=== List of packages by group ===<br />
;Entire compiz-fusion group:<br />
:ccsm, compiz-core, compiz-fusion-plugins-extra, compiz-fusion-plugins-main, compizconfig-backend-gconf, compizconfig-backend-kconfig, emerald, emerald-themes, fusion-icon<br />
<br />
;KDE compiz-fusion group:<br />
:ccsm, compiz-fusion-plugins-extra, compiz-fusion-plugins-main, compizconfig-backend-kconfig, emerald, emerald-themes, fusion-icon<br />
<br />
;GTK compiz-fusion group:<br />
:ccsm, compiz-fusion-plugins-extra, compiz-fusion-plugins-main, compizconfig-backend-gconf, emerald, emerald-themes, fusion-icon<br />
<br />
You might want to install compiz-manager. It will allow you to have session management working. (From what I have understood.)<br />
<br />
(more TODO?)<br />
<br />
= Starting Compiz Fusion =<br />
<br />
== Manual (with "fusion-icon") ==<br />
<br />
Launch the Compiz Fusion tray icon:<br />
$ fusion-icon<br />
<br />
'''Note:''' If it fails, you may try it with dbus-launch:<br />
$ dbus-launch "fusion-icon"<br />
<br />
Right click on the icon in the panel and go to 'select window manager'. Choose "Compiz" if it isn't selected already, and you should be set.<br />
<br />
If this fails you can start compiz-fusion by using the following commands<br />
$ fusion-icon<br />
$ emerald --replace<br />
$ compiz-manager<br />
<br />
== KDE ==<br />
<br />
=== Manual (without "fusion-icon") ===<br />
<br />
Launch Compiz with the following command once installation is done :<br />
$ compiz --replace ccp &<br />
<br />
Start new settings manager:<br />
$ ccsm &<br />
<br />
Select all the plugins you like including “decoration” plugin, Add<br />
$ kde-window-decorator --replace<br />
as command string under ‘decoration’ plugin.<br />
<br />
<!-- We need some more consistency with the autostart guides. The KDE version suggests starting compiz directly while the GNOME version tells you to use fusion-icon. --><br />
<br />
=== Autostart (with "fusion-icon") ===<br />
<br />
You should add a symbolic link to the fusion-icon executable in your KDE Autostart directory (generally located on ~/.kde/Autostart):<br />
$ ln -s /usr/bin/fusion-icon ~/.kde/Autostart/fusion-icon<br />
<br />
Next time you start KDE it will load fusion-icon automatically.<br />
<br />
=== Autostart (without "fusion-icon") ===<br />
<br />
==== Method 1 - Autostart Link ====<br />
<br />
* You can ensure that Compiz Fusion will always start at login by appending a desktop entry to the KDE autostart directory. Create the file ''~/.kde/Autostart/compiz.desktop'' with the following contents:<br />
<br />
[Desktop Entry]<br />
Encoding=UTF-8<br />
Exec=compiz --replace ccp<br />
StartupNotify=false<br />
Terminal=false<br />
Type=Application<br />
X-KDE-autostart-after=kdesktop<br />
<br />
* If you want to use the optional <tt>fusion-icon</tt> application, launch ''fusion-icon''. If you log out normally with ''fusion-icon'' running, KDE should restore your session and launch ''fusion-icon'' the next time you log in if this setting is enabled. If it doesn't appear to be working, ensure you have the following line in ''~/.kde/share/config/ksmserverrc'':<br />
<br />
loginMode=restorePreviousLogout<br />
<br />
==== Method 2 - export KDEWM (avoid KWIN) ====<br />
<br />
Using this method will load Compiz-Fusion as the default window manager instead of KWin from the start. This method is faster then loading Compiz-Fusion in the ~/.kde4/Autostart/ (method 1) because it avoids loading KDE's default WM (KWin) first. This way also stops that annoying black screen flicker you might see using other methods (when kwin switches to Compiz on KDE's desktop loading screens).<br />
<br />
As root you must create a short script by doing the following in your terminal. This will allow you to load compiz with the switches because doing it directly via <code>export KDEWM="compiz --replace ccp --sm-disable"</code> doesn't seem to work.<br />
$ echo "compiz --replace ccp --sm-disable &" > /usr/bin/compiz-fusion<br />
<br />
If this doesn't work, install the "fusion-icon" package and then use this line instead:<br />
$ echo "fusion-icon &" > /usr/bin/compiz-fusion<br />
<br />
Ensure that "/usr/bin/compiz-fusion" has executable (+x) permissions.<br />
$ chmod a+x /usr/bin/compiz-fusion<br />
<br />
Edit your ~/.bashrc and add the following so KDE will load compiz (via the script you just created) instead of loading KWin.<br />
$ export KDEWM="compiz-fusion"<br />
<br />
'''Note:''' If you use /usr/local/bin directory it may not work. In that case you should export the script with the path, i.e. <code>export KDEWM="/usr/local/bin/compiz-fusion"</code>.<br />
<br />
'''Note:''' The elegant way for above mentioned method is to include:<br />
KDEWM="compiz-fusion"<br />
line in the ~/.kde4/env/compiz.sh or /usr/env/compiz.sh (system wide).<br />
<br />
==== Method 3 - Use KDE 4.2 System Settings ====<br />
<br />
Go to System Settings --> Default Applications --> Window Manager --> Use a different window manager<br />
<br />
----<br />
<br />
== GNOME ==<br />
<br />
=== Autostart (without "fusion-icon") ===<br />
<br />
Create /usr/share/applications/compiz.desktop containing the following:<br />
<br />
[Desktop Entry]<br />
Type=Application<br />
Encoding=UTF-8<br />
Name=Compiz<br />
Exec=compiz ccp<br />
NoDisplay=true<br />
# name of loadable control center module<br />
X-GNOME-WMSettingsModule=compiz<br />
# name we put on the WM spec check window<br />
X-GNOME-WMName=Compiz<br />
<br />
Set a GConf parameter: "gconftool-2 --set -t string /desktop/gnome/session/required_components/windowmanager compiz"<br />
<br />
Note: If that doesn't work try '''Exec=compiz ccp --indirect-rendering''' instead of '''Exec=compiz ccp''' in the above.<br />
<br />
=== Autostart (without "fusion-icon", Gnome prior to 2.24) ===<br />
<br />
This is a way that works if you use GDM (and I'd assume KDM too).<br />
<br />
Make a file called /usr/local/bin/compiz-start-boot with the contents:<br />
#!/bin/bash<br />
export WINDOW_MANAGER="compiz ccp"<br />
exec gnome-session<br />
<br />
and make executable (<code>chmod +x</code>). Next create the file /etc/X11/sessions/Compiz.desktop containing the following:<br />
[Desktop Entry]<br />
Version=1.0<br />
Encoding=UTF-8<br />
Name=Compiz on GNOME<br />
Exec=/usr/local/bin/compiz-start-boot<br />
Icon=<br />
Type=Application<br />
<br />
Select Compiz on Gnome as your session and you're good to go.<br />
<br />
=== Autostart (with "fusion-icon") ===<br />
<br />
To start Compiz fusion automatically when starting a session add<br />
"Compiz Fusion" (Name:)<br />
and <br />
"fusion-icon" (Command:)<br />
to the applications that start with your session. You can do this by going to:<br />
[System] -> [Preferences] -> [Sessions] -> [Startup Programs]<br />
<br />
Adding "Compiz Fusion" to the list might be a good idea too so you can switch back to Metacity if need be.<br />
<br />
Also set the following parameter, otherwise fusion-icon might not load windows decorator.<br />
gconftool-2 --type bool --set /apps/metacity/general/compositing_manager false<br />
<br />
== Xfce ==<br />
<br />
=== Xfce autostart (without "compiz-fusion") ===<br />
<br />
TO DO<br />
<br />
=== Xfce autostart (with "compiz-fusion") ===<br />
====Method 1:====<br />
<br />
This will load Xfcewm first then replace it with Compiz.<br />
<br />
Start "Autostarted Applications"<br />
<br />
Add<br />
(Name:) Compiz Fusion<br />
and <br />
(Command:) fusion-icon<br />
<br />
====Method 2:====<br />
<br />
Edit the following file (settings in this file is used in preference)<br />
nano ~/.conf/xfce4-session/xfce4-session.rc<br />
<br />
Or to make the change for all Xfce users (root access required)<br />
# nano /etc/xdg/xfce4-session/xfce4-session.rc<br />
<br />
Add the following<br />
[Failsafe Session]<br />
Client0_Command=fusion-icon<br />
<br />
Comment out Client0_Command=xfwm4 if it exists.<br />
<br />
This will cause xfce to load Compiz Fusion instead of Xfcewm when the user has no existing sessions.<br />
<br />
To prevent the default session from being overwritten you may also add<br />
[General]<br />
AutoSave=false<br />
SaveOnExit=false<br />
<br />
To remove the existing sessions<br />
rm -R ~/.cache/sessions<br />
<br />
== As a standalone WM ==<br />
<br />
Write a simple script called, say, start-fusion.sh:<br />
#!/bin/sh<br />
# add more apps here if necessary<br />
xfce4-panel&<br />
fusion-icon<br />
Make it executable and add it to ~/.xinitrc, like this:<br />
exec start-fusion.sh<br />
Feel free to use a different panel, tray, or start a whole bunch on applications with your session.<br />
See [http://bbs.archlinux.org/viewtopic.php?id=51282 forum thread] for more info.<br />
<br />
=== Add a root menu ===<br />
<br />
To add a root menu similar to that in Openbox, Fluxbox, Blackbox etc. you must install the package compiz-deskmenu from the AUR, if you have [[Yaourt]] installed, you can do this with the following:<br />
# yaourt -S compiz-deskmenu<br />
Upon a restart of Compiz-Fusion, you should be able to middle click on your desktop to launch the menu.<br />
<br />
If it does not automatically work, enter the CompizConfig Settings Manager, and in Commands tab, within the General Settings menu, ensure that there is a command to launch Compiz-Deskmenu, and the appropriate key binding is set to Control+Space.<br />
<br />
If it still does not work, enter the Viewport Switcher menu, and change "Plugin for initiate action" to core, and "Action name for initiate" to run_command0_key.<br />
<br />
== Troubleshooting ==<br />
Make sure that the environmental variable $XLIB_SKIP_ARGB_VISUALS is not set<br />
<br />
<br />
KDE 4.2 :<br />
<br />
'''-Panel/taskbar is visible when running apps in fullscreen mode:'''<br />
<br />
Enable Window Rules plugin and add under ABOVE : state=fullscreen<br />
<br />
<br />
----<br />
<br />
Also see [[Compiz_Troubleshooting]]<br />
<br />
= Additional Resources =<br />
*[[AIGLX]]<br />
*[[Xgl]]<br />
*[[Composite]] -- A Xorg extension required by composite managers<br />
*[[Compiz Fusion]] -- A composite and window manager offering a rich 3D accelerated desktop environment<br />
*[[Compiz]] -- The original composite/window manager from Novell<br />
*[[Xcompmgr]] -- A simple composite manager capable of drop shadows and primitive transparency<br />
*[[Beryl]] -- <strike>A composite/window manager forked from Compiz</strike> (since merged to become [[Compiz Fusion]])<br />
*Wikipedia: [http://en.wikipedia.org/wiki/Compositing_window_manager Compositing Window Managers]<br />
*How to set up Compiz Fusion: [http://forlong.blogage.de/article/2007/8/29/How-to-set-up-Compiz-Fusion Forlong's Blog]</div>Philfifi