https://wiki.archlinux.org/api.php?action=feedcontributions&user=Signal-11&feedformat=atomArchWiki - User contributions [en]2024-03-29T07:09:12ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Power_management/Suspend_and_hibernate&diff=530089Power management/Suspend and hibernate2018-07-16T16:50:59Z<p>Signal-11: added slight clarification on behavior of hibernate</p>
<hr />
<div>[[Category:Power management]]<br />
[[ja:サスペンドとハイバネート]]<br />
[[ru:Power management/Suspend and hibernate]]<br />
[[zh-hans:Power management/Suspend and hibernate]]<br />
{{Related articles start}}<br />
{{Related|Uswsusp}}<br />
{{Related|systemd}}<br />
{{Related|Power management}}<br />
{{Related articles end}}<br />
<br />
Currently there are three methods of suspending available: '''suspend to RAM''' (usually called just '''suspend'''), '''suspend to disk''' (usually known as '''hibernate'''), and '''hybrid suspend''' (sometimes aptly called '''suspend to both'''):<br />
<br />
* '''Suspend to RAM''' method cuts power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).<br />
<br />
* '''Suspend to disk''' method saves the machine's state into [[swap space]] and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is zero power consumption.<br />
<br />
* '''Suspend to both''' method saves the machine's state into swap space, but does not power off the machine. Instead, it invokes usual suspend to RAM. Therefore, if the battery is not depleted, the system can resume from RAM. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.<br />
<br />
There are multiple low level interfaces (backends) providing basic functionality, and some high level interfaces providing tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).<br />
<br />
== Low level interfaces ==<br />
<br />
Though these interfaces can be used directly, it is advisable to use some of [[#High level interfaces|high level interfaces]] to suspend/hibernate. Using low level interfaces directly is significantly faster than using any high level interface, since running all the pre- and post-suspend hooks takes time, but hooks can properly set hardware clock, restore wireless etc.<br />
<br />
=== kernel (swsusp) ===<br />
<br />
The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to {{ic|/sys/power/state}} is the primary mechanism to trigger this suspend.<br />
<br />
See [https://www.kernel.org/doc/Documentation/power/states.txt kernel documentation] for details.<br />
<br />
=== uswsusp ===<br />
<br />
The uswsusp ('Userspace Software Suspend') is a wrapper around the kernel's suspend-to-RAM mechanism, which performs some graphics adapter manipulations from userspace before suspending and after resuming.<br />
<br />
See main article [[Uswsusp]].<br />
<br />
== High level interfaces ==<br />
<br />
The end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/hibernate. Actually hooking them up to power buttons or menu clicks or laptop lid events is usually left to other tools. To automatically suspend/hibernate on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running [[Acpid]].<br />
<br />
=== systemd ===<br />
<br />
[[systemd]] provides native commands for suspend, hibernate and a hybrid suspend, see [[Power management#Power management with systemd]] for details. This is the default interface used in Arch Linux.<br />
<br />
See [[Power management#Sleep hooks]] for additional information on configuring suspend/hibernate hooks. Also see {{man|1|systemctl}}, {{man|8|systemd-sleep}}, and {{man|7|systemd.special}}.<br />
<br />
== Hibernation ==<br />
<br />
In order to use hibernation, you need to create a [[swap]] partition or file. You will need to point the kernel to your swap using the {{ic|1=resume=}} kernel parameter, which is configured via the boot loader. You will also need to [[#Configure the initramfs|configure the initramfs]]. This tells the kernel to attempt resuming from the specified swap in early userspace. These three steps are described in detail below.<br />
<br />
=== About swap partition/file size ===<br />
<br />
Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully. According to [https://www.kernel.org/doc/Documentation/power/interface.txt kernel documentation]:<br />
<br />
: ''{{ic|/sys/power/image_size}} controls the size of the image created by the suspend-to-disk mechanism. It can be written a string representing a non-negative integer that will be used as an upper limit of the image size, in bytes. The suspend-to-disk mechanism will do its best to ensure the image size will not exceed that number. However, if this turns out to be impossible, it will try to suspend anyway using the smallest image possible. In particular, if "0" is written to this file, the suspend image will be as small as possible. Reading from this file will display the current image size limit, which is set to 2/5 of available RAM by default.''<br />
<br />
You may either decrease the value of {{ic|/sys/power/image_size}} to make the suspend image as small as possible (for small swap partitions), or increase it to possibly speed up the hibernation process.<br />
<br />
See [[Systemd#Temporary files]] to make this change persistent.<br />
<br />
=== Required kernel parameters ===<br />
<br />
The kernel parameter {{ic|1=resume=''swap_partition''}} has to be used. Either the name the kernel assigns to the partition or its [[UUID]] can be used as {{ic|''swap_partition''}}. For example:<br />
<br />
* {{ic|1=resume=/dev/sda1}}<br />
* {{ic|1=resume=UUID=4209c845-f495-4c43-8a03-5363dd433153}}<br />
* {{ic|1=resume=/dev/archVolumeGroup/archLogicVolume}} -- example if using LVM<br />
<br />
Generally, the naming method used for the {{ic|resume}} parameter should be the same as used for the {{ic|root}} parameter.<br />
<br />
The configuration depends on the used [[boot loader]], refer to [[Kernel parameters]] for details.<br />
<br />
==== Hibernation into swap file ====<br />
<br />
{{Warning|[[Btrfs#Swap file|Btrfs]] does not support swap files. Failure to heed this warning may result in file system corruption. While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.}}<br />
<br />
Using a swap file instead of a swap partition requires an additional kernel parameter {{ic|1=resume_offset=''swap_file_offset''}}.<br />
<br />
The value of {{ic|''swap_file_offset''}} can be obtained by running {{ic|filefrag -v ''swap_file''}}, the output is in a table format and the required value is located in the first row of the {{ic|physical_offset}} column. For example:<br />
<br />
{{hc|# filefrag -v /swapfile|<nowiki><br />
Filesystem type is: ef53<br />
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)<br />
ext: logical_offset: physical_offset: length: expected: flags:<br />
0: 0.. 0: 38912.. 38912: 1: <br />
1: 1.. 22527: 38913.. 61439: 22527: unwritten<br />
2: 22528.. 53247: 899072.. 929791: 30720: 61440: unwritten<br />
...<br />
</nowiki>}}<br />
<br />
In the example the value of {{ic|''swap_file_offset''}} is the first {{ic|38912}} with the two periods.<br />
<br />
The value of {{ic|''swap_file_offset''}} can also be obtained by running {{ic|swap-offset ''swap_file''}}. The ''swap-offset'' binary is provided by package {{AUR|uswsusp-git}}.<br />
<br />
{{Note|<br />
* The {{ic|resume}} kernel parameter specifies the device of the partition that contains the swap file, not swap file itself! The parameter {{ic|resume_offset}} informs the system where the swap file starts on the resume device. Before the first hibernation a reboot is required for them to be active.<br />
* If using [[uswsusp]], then these two parameters have to be provided in {{ic|/etc/suspend.conf}} via the keys {{ic|resume device}} and {{ic|resume offset}}. No reboot is required in this case.}}<br />
<br />
{{Tip|You might want to decrease the [[Swap#Swappiness]] for your swapfile if the only purpose is to be able to hibernate and not expand RAM.}}<br />
<br />
=== Configure the initramfs ===<br />
<br />
* When an [[initramfs]] with the {{ic|base}} hook is used, which is the default, the {{ic|resume}} hook is required in {{ic|/etc/mkinitcpio.conf}}. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the {{ic|resume}} hook must go ''after'' the {{ic|udev}} hook. This example was made starting from the default hook configuration:<br />
<br />
:{{bc|1=HOOKS=(base udev autodetect keyboard modconf block filesystems '''resume''' fsck)}}<br />
<br />
:Remember to [[regenerate the initramfs]] for these changes to take effect.<br />
<br />
:{{Note|[[LVM]] users should add the {{ic|resume}} hook after {{ic|lvm2}}.}}<br />
<br />
* When an initramfs with the {{ic|systemd}} hook is used, a resume mechanism is already provided, and no further hooks need to be added.<br />
<br />
== Troubleshooting ==<br />
<br />
=== ACPI_OS_NAME ===<br />
<br />
You might want to tweak your '''DSDT table''' to make it work. See [[DSDT]] article<br />
<br />
=== VAIO Users ===<br />
<br />
Add acpi_sleep=nonvs kernel flag to your loader, and you are done!<br />
<br />
=== Suspend/hibernate doesn't work, or not consistently ===<br />
<br />
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.<br />
<br />
Also problem may rise when using hardware watchdog timer (disabled by default, see {{ic|1=RuntimeWatchdogSec=}} in {{man|5|systemd-system.conf|OPTIONS}}). When bugged watchdog timer may reset computer before system able to finish creating the hibernation image.<br />
<br />
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in [[Mkinitcpio#MODULES]] and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for [[Kernel_mode_setting#Early_KMS_start|early KMS]]. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check this [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues article] for the best practices to debug suspend/hibernate issues.<br />
<br />
For Intel graphics drivers, enabling early KMS may help to solve the blank screen issue. Refer to [[Kernel mode setting#Early KMS start]] for details.<br />
<br />
After upgrading to kernel 4.15.3, resume may fail with a static (non-blinking) cursor on a black screen. [[Blacklisting]] the module {{ic|nvidiafb}} might help. [https://bbs.archlinux.org/viewtopic.php?id=234646]<br />
<br />
=== Wake-on-LAN ===<br />
<br />
If [[Wake-on-LAN]] is active, the network interface card will consume power even if the computer is hibernated.<br />
<br />
=== Instantaneous wakeups from suspend ===<br />
<br />
For some Intel Haswell systems with the LynxPoint and LynxPoint-LP chipset, instantaneous wakeups after suspend are reported. They are linked to erroneous BIOS ACPI implementations and how the {{ic|xhci_hcd}} module interprets it during boot. As a work-around reported affected systems are added to a blacklist (named {{ic|XHCI_SPURIOUS_WAKEUP}}) by the kernel case-by-case.[https://bugzilla.kernel.org/show_bug.cgi?id=66171#c6] <br />
<br />
Instantaneous resume may happen, for example, if a USB device is plugged during suspend and ACPI wakeup triggers are enabled. A viable work-around for such a system, if it is not on the blacklist yet, is to disable the wakeup triggers. An example to disable wakeup through USB is described as follows.[https://bbs.archlinux.org/viewtopic.php?pid=1575617] <br />
<br />
To view the current configuration:<br />
<br />
{{hc|$ cat /proc/acpi/wakeup|<br />
Device S-state Status Sysfs node<br />
...<br />
EHC1 S3 *enabled pci:0000:00:1d.0<br />
EHC2 S3 *enabled pci:0000:00:1a.0<br />
XHC S3 *enabled pci:0000:00:14.0<br />
...<br />
}}<br />
<br />
The relevant devices are {{ic|EHC1}}, {{ic|EHC2}} and {{ic|XHC}} (for USB 3.0). To toggle their state you have to echo the device name to the file as root.<br />
<br />
# echo EHC1 > /proc/acpi/wakeup<br />
# echo EHC2 > /proc/acpi/wakeup<br />
# echo XHC > /proc/acpi/wakeup<br />
<br />
This should result in suspension working again. However, this settings are only temporary and would have to be set at every reboot. To automate this take a look at [[systemd#Writing unit files]]. See [https://bbs.archlinux.org/viewtopic.php?pid=1575617#p1575617 BBS thread] for a possible solution and more information.<br />
<br />
<br />
When you hibernate your system, the system should power off (after ofcourse saving the state on the disk). Sometimes, you might see the power led's still glowing. If that happens, it might be instructive to see if <br />
<br />
HibernateMode=shutdown<br />
<br />
can be seen in<br />
<br />
/etc/systemd/sleep.conf<br />
<br />
With the above configuration, if every thing else is setup correctly, on invocation of a <br />
<br />
systemctl hibernate<br />
<br />
the machine will shutdown saving state to disk as it does so.</div>Signal-11https://wiki.archlinux.org/index.php?title=OpenSSH&diff=283731OpenSSH2013-11-20T04:01:28Z<p>Signal-11: /* Speeding up SSH */</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[ar:Ssh]]<br />
[[es:Secure Shell]]<br />
[[de:SSH]]<br />
[[fr:ssh]]<br />
[[it:Secure Shell]]<br />
[[ko:Secure Shell]]<br />
[[pl:Secure Shell]]<br />
[[pt:Secure Shell]]<br />
[[ru:Secure Shell]]<br />
[[sr:Secure Shell]]<br />
[[zh-CN:Secure Shell]]<br />
'''Secure Shell''' ('''SSH''') is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; file transfer can be accomplished using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An SSH client program is typically used for establishing connections to an ''sshd'' daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, GNU/Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
(Source: [[Wikipedia:Secure Shell]])<br />
<br />
== OpenSSH ==<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
=== Installing OpenSSH ===<br />
[[pacman|Install]] {{Pkg|openssh}} from the [[official repositories]].<br />
<br />
=== Configuring SSH ===<br />
====Client====<br />
The SSH client configuration file is {{ic|/etc/ssh/ssh_config}} or {{ic|~/.ssh/config}}.<br />
<br />
It is not longer needed to explicitly set {{ic|Protocol 2}}, it is commented out in the default configuration file. That means {{ic|Protocol 1}} will not be used as long as it is not explicitly enabled. (source: http://www.openssh.org/txt/release-5.4)<br />
<br />
====Daemon====<br />
The SSH daemon configuration file can be found and edited in {{ic|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
To disable root login over SSH, change the PermitRootLogin line into this:<br />
PermitRootLogin no<br />
<br />
To add a nice welcome message edit the file {{ic|/etc/issue}} and change the Banner line into this:<br />
Banner /etc/issue<br />
<br />
{{Tip| You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}} <br />
<br />
Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts. To help select a port review the [[Wikipedia:List of TCP and UDP port numbers|list of TCP and UDP port numbers]].<br />
<br />
{{Tip|Disabling password logins entirely will greatly increase security, see [[SSH Keys]] for more information.}}<br />
<br />
=== Managing the sshd daemon ===<br />
You can start the sshd daemon with the following command:<br />
# systemctl start sshd<br />
<br />
You can enable the sshd daemon at startup with the following command:<br />
# systemctl enable sshd.service<br />
<br />
{{Warning|Systemd is an asynchronous starting process. If you bind the SSH daemon to a specific IP address {{ic|ListenAddress 192.168.1.100}} it may fail to load during boot since the default sshd.service unit file has no dependency on network interfaces being enabled. When binding to an IP address, you will need to add {{ic|After&#61;network.target}} to a custom sshd.service unit file. See [[Systemd#Editing provided unit files]].}}<br />
<br />
Or you can enable SSH Daemon socket so the daemon is started on the first incoming connection:<br />
# systemctl enable sshd.socket<br />
If you use a different port than the default 22, you have to set "ListenStream" in the unit file. Copy /lib/systemd/system/sshd.socket to /etc/systemd/system/sshd.socket to keep your unit file from being overwritten on upgrades. In /etc/systemd/system/sshd.socket change "ListenStream" the appropriate port.<br />
<br />
{{Warning|Using sshd.socket effectively negates the {{ic|ListenAddress}} setting, so using the default sshd.socket will allow connections over any address. To achieve the effect of setting {{ic|ListenAddress}}, you must create a custom unit file and modify ListenStream (ie. {{ic|ListenStream&#61;192.168.1.100:22}} is equivalent to {{ic|ListenAddress 192.168.1.100}}). However, doing so has the same drawback as setting {{ic|ListenAddress}}: the socket will fail to start if the network is not up in time.}}<br />
<br />
=== Connecting to the server ===<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
=== Protecting SSH ===<br />
Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.<br />
* Use non-standard account names and passwords<br />
* Only allow incoming SSH connections from trusted locations<br />
* Use [[fail2ban]] or [[sshguard]] to monitor for brute force attacks, and ban brute forcing IPs accordingly<br />
<br />
===== Protecting against brute force attacks =====<br />
Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations. You can protect yourself from brute force attacks by using an automated script that blocks anybody trying to brute force their way in, for example [[fail2ban]] or [[sshguard]].<br />
<br />
===== Deny root login =====<br />
It is generally considered bad practice to allow the user '''root''' to log in over SSH: The '''root''' account will exist on nearly any Linux system and grants full access to the system, once login has been achieved. Sudo provides root rights for actions requiring these and is the more secure solution, third parties would have to find a username present on the system, the matching password and the matching password for sudo to get root rights on your system. More barriers to be breached before full access to the system is reached.<br />
<br />
Configure SSH to deny remote logins with the root user by editing {{ic|/etc/ssh/sshd_config}} and look for this section:<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
''#PermitRootLogin yes''<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
#MaxSessions 10<br />
<br />
Now simply change ''#PermitRootLogin yes'' to no, and uncomment the line:<br />
PermitRootLogin no<br />
<br />
Next, restart the SSH daemon:<br />
# systemctl restart sshd<br />
<br />
You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use ''su'' - or ''sudo'' to do system administration.<br />
<br />
== Other SSH clients and servers ==<br />
Apart from OpenSSH, there are many SSH [[Wikipedia:Comparison of SSH clients|clients]] and [[Wikipedia:Comparison of SSH servers|servers]] avaliable.<br />
<br />
=== Dropbear ===<br />
[[Wikipedia:Dropbear (software)|Dropbear]] is a SSH-2 client and server. {{AUR|dropbear}} is available in the [[AUR]].<br />
<br />
The commandline ssh client is named dbclient.<br />
<br />
=== SSH alternative: Mobile Shell - responsive, survives disconnects ===<br />
From the Mosh [http://mosh.mit.edu/ website]:<br />
<br />
Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.<br />
<br />
[[pacman|Install]] {{Pkg|mosh}} from the [[official repositories]] or the latest revision {{AUR|mosh-git}} in the [[AUR]].<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted SOCKS tunnel ===<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you do not have to remember your IP-address.<br />
<br />
==== Step 1: start the connection ====<br />
You only have to execute this single command to start the connection:<br />
$ ssh -TND 4711 user@host<br />
where {{Ic|"user"}} is your username at the SSH server running at the {{Ic|"host"}}. It will ask for your password, and then you're connected! The {{Ic|"N"}} flag disables the interactive prompt, and the {{Ic|"D"}} flag specifies the local port on which to listen on (you can choose any port number if you want). The {{Ic|"T"}} flag disables pseudo-tty allocation.<br />
<br />
It's nice to add the verbose {{Ic|"-v"}} flag, because then you can verify that it's actually connected from that output.<br />
<br />
==== Step 2: configure your browser (or other programs) ====<br />
The above step is completely useless if you do not configure your web browser (or other programs) to use this newly created socks tunnel. Since the current version of SSH supports both SOCKS4 and SOCKS5, you can use either of them.<br />
<br />
* For Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':<br />
: Check the ''"Manual proxy configuration"'' radio button, and enter "localhost" in the ''"SOCKS host"'' text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:<br />
<br />
# Type about:config into the Firefox location bar.<br />
# Search for network.proxy.socks_remote_dns<br />
# Set the value to true.<br />
# Restart the browser.<br />
<br />
* For Chromium: You can set the SOCKS settings as environment variables or as command line options. I recommend to add one of the following functions to your {{ic|.bashrc}}:<br />
function secure_chromium {<br />
port=4711<br />
export SOCKS_SERVER=localhost:$port<br />
export SOCKS_VERSION=5<br />
chromium &<br />
exit<br />
}<br />
OR<br />
function secure_chromium {<br />
port=4711<br />
chromium --proxy-server="socks://localhost:$port" &<br />
exit<br />
}<br />
<br />
Now open a terminal and just do:<br />
$ secure_chromium<br />
<br />
Enjoy your secure tunnel!<br />
<br />
=== X11 forwarding ===<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client (here "client" means your (desktop) machine your X11 Server runs on, and you will run X applications on the "server").<br />
<br />
[[pacman|Install]] {{Pkg|xorg-xauth}} from the [[official repositories]] onto the server.<br />
<br />
* Enable the '''AllowTcpForwarding''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
* Enable the '''X11Forwarding''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
* Set the '''X11DisplayOffset''' option in {{ic|ssh'''d'''_config}} on the '''server''' to 10.<br />
* Enable the '''X11UseLocalhost''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
Also:<br />
* Enable the '''ForwardX11''' option in {{ic|ssh_config}} on the '''client'''.<br />
* Enable the '''ForwardX11Trusted''' if gui is drawing badly.<br />
<br />
You need to restart the ssh daemon on the server for these changes to take effect, of course.<br />
<br />
To use the forwarding, log on to your server through ssh:<br />
$ ssh -X -p port user@server-address<br />
If you receive errors trying to run graphical applications try trusted forwarding instead:<br />
$ ssh -Y -p port user@server-address<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
$ xclock<br />
<br />
<br />
If you get "Cannot open display" errors try the following command as the non root user:<br />
$ xhost +<br />
<br />
the above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:<br />
$ xhost +hostname<br />
<br />
where hostname is the name of the particular host you want to forward to. Type "man xhost" for more details.<br />
<br />
Be careful with some applications as they check for a running instance on the local machine. Firefox is an example. Either close running Firefox or use the following start parameter to start a remote instance on the local machine<br />
$ firefox -no-remote<br />
<br />
If you get "X11 forwarding request failed on channel 0" when you connect (and the server /var/log/errors.log shows "Failed to allocate internet-domain X11 display socket"), try to either<br />
* Enable the '''AddressFamily any''' option in {{ic|ssh'''d'''_config}} on the '''server''', or<br />
* Set the '''AddressFamily''' option in {{ic|ssh'''d'''_config}} on the '''server''' to inet.<br />
Setting it to inet may fix problems with Ubuntu clients on IPv4.<br />
<br />
For running X applications as other user on the SSH server you need to {{Ic|xauth add}} the authentication line taken from {{Ic|xauth list}} of the SSH logged in user.<br />
<br />
=== Forwarding other ports ===<br />
In addition to SSH's built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.<br />
<br />
Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the {{Ic|-L}} switch and it's accompanying forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -L 1000:mail.google.com:25 192.168.0.100<br />
<br />
will use SSH to login to and open a shell on 192.168.0.100, and will also create a tunnel from the local machine's TCP port 1000 to mail.google.com on port 25. Once established, connections to localhost:1000 will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from 192.168.0.100, and such data will be secure as between the local machine and 192.168.0.100, but not between 192.168.0.100, unless other measures are taken.<br />
<br />
Similarly:<br />
<br />
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100<br />
<br />
will allow connections to localhost:2000 which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility--part of the tightvnc package--which, though very useful, is explicit about its lack of security.<br />
<br />
Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the {{Ic|-R}} switch and a forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200<br />
<br />
will bring up a shell on 192.168.0.200, and connections from 192.168.0.200 to itself on port 3000 (remotely speaking, localhost:3000) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.<br />
<br />
Both local and remote forwarding can be used to provide a secure "gateway," allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g. {{Ic|<tunnel address>:<tunnel port>:<destination address>:<destination port>}}. The {{Ic|<tunnel address>}} can be any address on the machine at the start of the tunnel, {{Ic|localhost}}, {{Ic|*}} (or blank), which, respectively, allow connections via the given address, via the loopback interface, or via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the {{Ic|<tunnel address>}} is set to {{Ic|localhost}}. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the {{Ic|GatewayPorts}} option in {{Ic|sshd_config(5)}} for more information.<br />
<br />
=== Speeding up SSH ===<br />
You can make all sessions to the same host use a single connection, which will greatly speed up subsequent logins, by adding these lines under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
Host examplehost.com<br />
ControlMaster auto<br />
ControlPersist yes<br />
ControlPath ~/.ssh/socket-%r@%h:%p<br />
<br />
From the ssh_config man page <br />
{{ic | When used in conjunction with ControlMaster, specifies that the master connection should remain open in the background (waiting for future client connections) afterthe initial client connection has been closed. }}<br />
<br />
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this aspect, the best choices are arcfour and blowfish-cbc. '''Please do not do this unless you know what you are doing; arcfour has a number of known weaknesses'''. To use them, run SSH with the {{Ic|"c"}} flag, like this:<br />
$ ssh -c arcfour,blowfish-cbc user@server-address<br />
To use them permanently, add this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
Ciphers arcfour,blowfish-cbc<br />
Another option to improve speed is to enable compression with the {{Ic|"C"}} flag. A permanent solution is to add this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
Compression yes<br />
Login time can be shorten by using the {{Ic|"4"}} flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
AddressFamily inet<br />
Another way of making these changes permanent is to create an alias in {{ic|~/.bashrc}}:<br />
alias ssh='ssh -C4c arcfour,blowfish-cbc'<br />
<br />
=== Mounting a remote filesystem with SSHFS ===<br />
Please refer to the [[Sshfs]] article to use sshfs to mount a remote system - accessible via SSH - to a local folder, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). Using sshfs instead of shfs is generally preferred as a new version of shfs hasn't been released since 2004.<br />
<br />
=== Keep alive ===<br />
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to {{ic|~/.ssh/config}} or to {{ic|/etc/ssh/ssh_config}} on the client.<br />
<br />
ServerAliveInterval 120<br />
<br />
This will send a "keep alive" signal to the server every 120 seconds.<br />
<br />
Conversely, to keep incoming connections alive, you can set<br />
<br />
ClientAliveInterval 120<br />
<br />
(or some other number greater than 0) in {{ic|/etc/ssh/sshd_config}} on the server.<br />
<br />
=== Saving connection data in ssh config ===<br />
Whenever you want to connect to a ssh server, you usually have to type at least its address and the username. To save that typing work for servers you regularly connect to, you can use the personal {{ic|$HOME/.ssh/config}} or the global {{ic|/etc/ssh/ssh_config}} files as shown in the following example:<br />
<br />
{{hc|$HOME/.ssh/config|<br />
Host myserver<br />
HostName 123.123.123.123<br />
Port 12345<br />
User bob<br />
Host other_server<br />
HostName test.something.org<br />
User alice<br />
CheckHostIP no<br />
Cipher blowfish<br />
}}<br />
<br />
Now you can simply connect to the server by using the name you specified:<br />
<br />
$ ssh myserver<br />
<br />
To see a complete list of the possible options, check out ssh_config's manpage on your system or the [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config documentation] on the official website.<br />
<br />
=== Autossh - automatically restarts SSH sessions and tunnels ===<br />
When a ssh session or tunnel cannot be kept alive, because for example bad network conditions cause the sshd client to disconnect, you can use [http://www.harding.motd.ca/autossh/ Autossh] to automatically restart them. Autossh can be installed from the [[official repositories]]. <br />
<br />
Usage examples:<br />
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com<br />
Combined with [[ sshfs ]]:<br />
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example <br />
Connecting through a SOCKS-proxy set by [[ Proxy_settings ]]:<br />
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com <br />
With the {{ic|-f}} option autossh can be made to run as a background process. Running it this way however means the passprase cannot be entered interactively.<br />
<br />
The session will end once you type {{ic|exit}} in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.<br />
<br />
If you want to automatically start autossh, it is now easy to get systemd to manage this for you. For example, you could create a systemd unit file like this:<br />
<br />
[Unit]<br />
Description=AutoSSH service for port 2222<br />
After=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
<br />
Then place this in, for example, /etc/systemd/system/autossh.service. Of course, you can make this unit more complex if necessary (see the systemd documentation for details), and obviously you can use your own options for autossh.<br />
<br />
You can then enable your autossh tunnels with, e.g.:<br />
<br />
$ systemctl start autossh<br />
(or whatever you called the service file)<br />
<br />
If this works OK for you, you can make this permanent by running<br />
<br />
$ systemctl enable autossh<br />
<br />
That way autossh will start automatically at boot.<br />
<br />
It is also easy to maintain several autossh processes, to keep several tunnels alive. Just create multiple .service files with different names.<br />
<br />
== Troubleshooting ==<br />
=== SSH connection left hanging after poweroff/reboot ===<br />
SSH connection hangs after poweroff or reboot if systemd stop network before sshd. To fix that problem, comment and change the {{ic|After}} statement:<br />
{{hc|/usr/lib/systemd/system/systemd-user-sessions.service|2=<br />
#After=remote-fs.target<br />
After=network.target}}<br />
<br />
=== Connection refused or timeout problem ===<br />
<br />
==== Is your router doing port forwarding? ====<br />
<br />
SKIP THIS STEP IF YOU ARE NOT BEHIND A NAT MODEM/ROUTER (eg, a VPS or otherwise publicly addressed host). Most home and small businesses will have a NAT modem/router.<br />
<br />
The first thing is to make sure that your router knows to forward any incoming ssh connection to your machine. Your external IP is given to you by your ISP, and it is associated with any requests coming out of your router. So your router needs to know that any incoming ssh connection to your external IP needs to be forwarded to your machine running sshd.<br />
<br />
Find your internal network address.<br />
<br />
ip a<br />
<br />
Find your interface device and look for the inet field. Then access your router's configuration web interface, using your router's IP (find this on the web). Tell your router to forward it to your inet IP. Go to [http://portforward.com/] for more instructions on how to do so for your particular router.<br />
<br />
==== Is SSH running and listening? ====<br />
$ ss -tnlp<br />
<br />
If the above command do not show SSH port is open, SSH is NOT running. Check {{ic|/var/log/messages}} for errors etc.<br />
<br />
==== Are there firewall rules blocking the connection? ====<br />
<br />
[[Iptables]] may be blocking connections on port {{ic|22}}. Check this with:<br />
{{bc|# iptables -nvL}}<br />
and look for rules that might be dropping packets on the {{ic|INPUT}} chain. Then, if necessary, unblock the port with a command like: <br />
{{bc|<br />
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT<br />
}}<br />
For more help configuring firewalls, see [[firewalls]].<br />
<br />
==== Is the traffic even getting to your computer? ====<br />
Start a traffic dump on the computer you're having problems with:<br />
<br />
# tcpdump -lnn -i any port ssh and tcp-syn<br />
<br />
This should show some basic information, then wait for any matching traffic to happen before displaying it. Try your connection now. If you do not see any output when you attempt to connect, then something outside of your computer is blocking the traffic (e. g., hardware firewall, NAT router etc.).<br />
<br />
==== Your ISP or a third party blocking default port? ====<br />
{{Note|Try this step if you '''KNOW''' you aren't running any firewalls and you know you have configured the router for DMZ or have forwarded the port to your computer and it still doesn't work. Here you will find diagnostic steps and a possible solution.}}<br />
<br />
In some cases, your ISP might block the default port (SSH port 22) so whatever you try (opening ports, hardening the stack, defending against flood attacks, et al) ends up useless. To confirm this, create a server on all interfaces (0.0.0.0) and connect remotely. <br />
<br />
If you get an error message comparable to this:<br />
ssh: connect to host www.inet.hr port 22: Connection refused<br />
<br />
That means the port '''ISN'T ''' being blocked by the ISP, but the server doesn't run SSH on that port (See [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).<br />
<br />
However, if you get an error message comparable to this:<br />
ssh: connect to host 111.222.333.444 port 22: Operation timed out <br />
<br />
That means that something is rejecting your TCP traffic on port 22. Basically that port is stealth, either by your firewall or 3rd party intervetion (like an ISP blocking and/or rejecting incoming traffic on port 22). If you know you aren't running any firewall on your computer, and you know that Gremlins aren't growing in your routers and switches, then your ISP is blocking the traffic.<br />
<br />
To double check, you can run Wireshark on your server and listen to traffic on port 22. Since Wireshark is a Layer 2 Packet Sniffing utility, and TCP/UDP are Layer 3 and above (See [http://en.wikipedia.org/wiki/TCP/IP_model IP Network stack]), if you don't receive anything while connecting remotely, a third party is most likely to be blocking the traffic on that port to your server.<br />
<br />
===== Diagnosis via Wireshark =====<br />
[[pacman|Install]] Wireshark with the {{Pkg|wireshark-cli}} package, available in the [[official repositories]].<br />
<br />
And then run it using,<br />
tshark -f "tcp port 22" -i NET_IF<br />
<br />
where NET_IF is the network interface for a WAN connection (see {{ic|ip a}} to check). If you aren't receiving any packets while trying to connect remotely, you can be very sure that your ISP is blocking the incoming traffic on port 22.<br />
<br />
===== Possible solution =====<br />
The solution is just to use some other port that the ISP isn't blocking. Open the {{ic|/etc/ssh/sshd_config}} and configure the file to use different ports. For example, add:<br />
<br />
Port 22<br />
Port 1234<br />
<br />
Also make sure that other "Port" configuration lines in the file are commented out. Just commenting "Port 22" and putting "Port 1234" won't solve the issue because then sshd will only listen on port 1234. Use both lines to run the SSH server on both ports. <br />
<br />
Restart the server {{ic|systemctl restart sshd.service}} and you're almost done. You still have to configure your client(s) to use the other port instead of the default port. There are numerous solutions to that problem, but let's cover two of them here.<br />
<br />
==== Read from socket failed: connection reset by peer ====<br />
Recent versions of openssh sometimes fail with the above error message, due to a bug involving elliptic curve cryptography. In that case add the following line to {{ic|~/.ssh/config}}:<br />
<br />
HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss<br />
<br />
With openssh 5.9, the above fix doesn't work. Instead, put the following lines in {{ic|~/.ssh/config}}:<br />
<br />
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc <br />
MACs hmac-md5,hmac-sha1,hmac-ripemd160<br />
<br />
See also the [http://www.gossamer-threads.com/lists/openssh/dev/51339 discussion] on the openssh bug forum.<br />
<br />
=== "[your shell]: No such file or directory" / ssh_exchange_identification problem ===<br />
One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by {{Ic|whereis -b [your shell]}}, for instance) in {{Ic|$SHELL}}, even if the shell's binary is located in one of the {{Ic|$PATH}} entries. Another reason can be that the user is no member of the ''network'' group.<br />
<br />
==="Terminal unknown" or "Error opening terminal" error message===<br />
With ssh it is possible to receive errors like "Terminal unknown" upon logging in. Starting ncurses applications like nano fails with the message "Error opening terminal". There are two methods to this problem, a quick one using the $TERM variable and a profound one using the terminfo file.<br />
<br />
====Workaround by setting the $TERM variable====<br />
After connecting to the remote server set the $TERM variable to "xterm" with the following command.<br />
<br />
{{ic|TERM&#61;xterm}}<br />
<br />
This method is a workaround and should be used on ssh servers you do seldomly connect to, because it can have unwanted side effects. Also you have to repeat the command after every connection, or alternatively set it in ~.bashrc .<br />
====Solution using terminfo file====<br />
A profound solution is transferring the terminfo file of the terminal on your client computer to the ssh server. In this example we cover how to setup the terminfo file for the "rxvt-unicode-256color" terminal.<br />
Create the directory containing the terminfo files on the ssh server, while you are logged in to the server issue this command:<br />
<br />
{{ic| mkdir -p ~/.terminfo/r/}}<br />
<br />
Now copy the terminfo file of your terminal to the new directory. Replace ''"rxvt-unicode-256color"'' with your client's terminal in the following command and ''ssh-server'' with the relevant user and server adress.<br />
<br />
{{ic|$ scp /usr/share/terminfo/r/''rxvt-unicode-256color'' ssh-server:~/.terminfo/r/}}<br />
<br />
After logging in and out from the ssh server the problem should be fixed.<br />
<br />
== See also ==<br />
*[[SSH Keys]]<br />
*[[Pam abl]]<br />
*[[fail2ban]]<br />
*[[sshguard]]<br />
*[[Sshfs]]<br />
*[[Syslog-ng]] : To send ssh log data to another file<br />
<br />
== Links & references ==<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]<br />
*[http://www.ibm.com/developerworks/library/l-keyc/index.html OpenSSH key management, Part 1] and [http://www.ibm.com/developerworks/library/l-keyc2 Part 2] on IBM developerWorks</div>Signal-11https://wiki.archlinux.org/index.php?title=SLiM&diff=257931SLiM2013-05-20T03:32:37Z<p>Signal-11: /* Enabling SLiM */</p>
<hr />
<div>[[Category:Display managers]]<br />
[[cs:SLiM]]<br />
[[es:SLiM]]<br />
[[fr:SLiM]]<br />
[[hu:SLiM]]<br />
[[it:SLiM]]<br />
[[ja:SLiM]]<br />
[[ko:SLiM]]<br />
[[pt:SLiM]]<br />
[[ru:SLiM]]<br />
[[sk:SLiM]]<br />
[[tr:SLiM]]<br />
[[zh-CN:SLiM]]<br />
[[zh-TW:SLiM]]<br />
{{Article summary start}}<br />
{{Article summary text|Provides an overview of the Simple Login Manager.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Display Manager}}<br />
{{Article summary end}}<br />
<br />
[http://slim.berlios.de/ SLiM] is an acronym for Simple Login Manager. SLiM is simple, lightweight and easily configurable. SLiM is used by some because it does not require the dependencies of [[GNOME]] or [[KDE]] and can help make a lighter system for users that like to use lightweight desktops like [[Xfce]], [[Openbox]], and [[Fluxbox]].<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] {{pkg|slim}} from the [[official repositories]].<br />
<br />
== Configuration ==<br />
<br />
=== Enabling SLiM ===<br />
<br />
{{Note|{{pkg|slim}} no longer has ConsoleKit support, but relies on systemd-logind, and the system being booted with systemd.}}<br />
<br />
Enable the '''slim''' [[Daemons|daemon]]. With systemd, it is no longer possible to start slim using {{ic|inittab}}.<br />
This can be done via the following<br />
{{ic| systemctl enable slim.service}}<br />
<br />
=== Single environments ===<br />
<br />
To configure SLiM to load a particular environment, edit your {{ic|~/.xinitrc}} to load your desktop environment:<br />
<br />
{{bc|<br />
#!/bin/sh<br />
<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
#<br />
<br />
exec <session-command><br />
}}<br />
<br />
Replace {{ic|<session-command>}} with the appropriate session command. Some examples of different desktop start commands:<br />
<br />
{{bc|<br />
exec awesome<br />
exec dwm<br />
exec startfluxbox<br />
exec fvwm2<br />
exec gnome-session<br />
exec openbox-session<br />
exec startkde<br />
exec startlxde<br />
exec startxfce4<br />
exec enlightenment_start<br />
}}<br />
<br />
For detailed instructions on how to start the various environments, refer to the appropriate wiki pages.<br />
<br />
SLiM reads the local {{ic|~/.xinitrc}} configuration and then launches the desktop according to what is in that file. If you do not have a {{ic|~/.xinitrc}} file, you can use the skeleton file by:<br />
<br />
$ cp /etc/skel/.xinitrc ~<br />
<br />
Remember to make {{ic|~/.xinitrc}} executable:<br />
<br />
chmod +x ~/.xinitrc<br />
<br />
=== Autologin ===<br />
<br />
To make SLiM automatically login as a specified user (without having to type a password) the following lines in {{ic|/etc/slim.conf}} should be changed.<br />
# default_user simone<br />
<br />
Uncomment this line, and change "simone" to the user to be logged into automatically.<br />
<br />
# auto_login no<br />
<br />
Uncomment this line and change the 'no' to 'yes'. This enables the auto login feature.<br />
<br />
=== Zsh ===<br />
{{Note|If you don't know what is zsh and you did not install it - ignore this paragraph.}}<br />
<br />
The default login command will not initialize your environment correctly [http://www.edsel.nu/2010/06/04/slim-simple-login-manager-on-freebsd/ [source]]. Change the login_cmd line in {{ic|/etc/slim.conf}} to:<br />
<br />
#login_cmd exec /bin/sh - ~/.xinitrc %session<br />
login_cmd exec /bin/zsh -l ~/.xinitrc %session<br />
<br />
=== Multiple environments ===<br />
<br />
To be able to choose from multiple desktop environments, SLiM can be setup to log you into whichever you choose.<br />
<br />
Put a case statement similar to this one in your {{ic|~/.xinitrc}} file and edit the sessions variable in {{ic|/etc/slim.conf}} to match the names that trigger the case statement. You can cycle through sessions at login time by pressing F1. Note that this feature is experimental.<br />
<br />
{{bc|1=<br />
# Adapted from: http://svn.berlios.de/svnroot/repos/slim/trunk/xinitrc.sample<br />
<br />
case $1 in<br />
kde)<br />
exec startkde<br />
;;<br />
xfce4)<br />
exec startxfce4<br />
;;<br />
wmaker)<br />
exec wmaker<br />
;;<br />
blackbox)<br />
exec blackbox<br />
;;<br />
icewm&#124;*)<br />
icewmbg &<br />
icewmtray &<br />
exec icewm<br />
;;<br />
esac<br />
}}<br />
<br />
{{Note|<nowiki>In the latest version (1.3.5), slim does not preset any default session, so using a DEFAULT_SESSION variable will not work the way it used to. Instead put your default session as the last case and |*) to the statement (see above)</nowiki>}}<br />
<br />
=== Themes ===<br />
<br />
Install the {{Pkg|slim-themes}} package:<br />
<br />
# pacman -S slim-themes archlinux-themes-slim<br />
<br />
The {{Pkg|archlinux-themes-slim}} packages contains several different themes ([http://imageshack.us/photo/my-images/27/slimthemes.png/ slimthemes.png]). Look in the directory of {{ic|/usr/share/slim/themes}} to see the themes available. Enter the theme name on the {{ic|current_theme}} line in {{ic|/etc/slim.conf}}:<br />
<br />
#current_theme default<br />
current_theme archlinux-simplyblack<br />
<br />
To preview a theme run while an instance of the Xorg server is running by:<br />
<br />
$ slim -p /usr/share/slim/themes/<theme name><br />
<br />
To close, type "exit" in the Login line and press Enter.<br />
<br />
Additional theme packages can be found in the [[AUR]].<br />
<br />
==== Dual screen setup ====<br />
<br />
You can customize the slim theme in {{ic|/usr/share/slim/themes/<your-theme>/slim.theme}} to turn these percents values. The box itself is 450 pixels by 250 pixels:<br />
<br />
input_panel_x 50%<br />
input_panel_y 50%<br />
<br />
into pixels values:<br />
<br />
# These settings set the "archlinux-simplyblack" panel in the center of a 1440x900 screen<br />
input_panel_x 495<br />
input_panel_y 325<br />
<br />
# These settings set the "archlinux-retro" panel in the center of a 1680x1050 screen<br />
input_panel_x 615<br />
input_panel_y 400<br />
<br />
If your theme has a background picture you should use the background_style setting ('stretch', 'tile', 'center' or 'color') to get it correctly displayed. Have a look at the [http://slim.berlios.de/themes_howto.php very simple and clear official documentation about slim themes] for further details.<br />
<br />
== Other options ==<br />
<br />
A few things you might like to try.<br />
<br />
=== Changing the cursor ===<br />
<br />
If you want to change the default X cursor to a newer design, the {{AUR|slim-cursor}} package is available.<br />
<br />
After installing, edit {{ic|/etc/slim.conf}} and uncomment the line:<br />
<br />
cursor left_ptr<br />
<br />
This will give you a normal arrow instead. This setting is forwarded to {{ic|xsetroot -cursor_name}}. You can look up the possible cursor names [http://cvsweb.xfree86.org/cvsweb/*checkout*/xc/lib/X11/cursorfont.h?rev=HEAD&content-type=text/plain here] or in {{ic|/usr/share/icons/<your-cursor-theme>/cursors/}}.<br />
<br />
To change the cursor theme being used at the login screen, make a file named {{ic|/usr/share/icons/default/index.theme}} with this content:<br />
<br />
[Icon Theme]<br />
Inherits=<your-cursor-theme><br />
<br />
Replace <your-cursor-theme> with the name of the cursor theme you want to use (e.g. whiteglass).<br />
<br />
=== Match SLiM and Desktop Wallpaper ===<br />
<br />
To share a wallpaper between SLiM and your desktop, rename the used theme background, then create a link from your desktop wallpaper file to the default SLiM theme:<br />
<br />
# mv /usr/share/slim/themes/default/background.jpg{,.bck}<br />
# ln -s /path/to/mywallpaper.jpg /usr/share/slim/themes/default/background.jpg<br />
<br />
=== Shutdown, reboot, suspend, exit, launch terminal from SLiM ===<br />
<br />
You may shutdown, reboot, suspend, exit or even launch a terminal from the SLiM login screen. To do so, use the values in the username field, and the root password in the password field:<br />
<br />
* To launch a terminal, enter '''console''' as the username (defaults to xterm which must be installed separately... edit {{ic|/etc/slim.conf}} to change terminal preference)<br />
* For shutdown, enter '''halt''' as the username<br />
* For reboot, enter '''reboot''' as the username<br />
* To exit to bash, enter '''exit''' as the username<br />
* For suspend, enter '''suspend''' as the username (suspend is disabled by default, edit {{ic|/etc/slim.conf}} as root to uncomment the {{ic|suspend_cmd}} line and, if necessary modify the suspend command itself (e.g. change {{ic|/usr/sbin/suspend}} to {{ic|sudo /usr/sbin/pm-suspend}}))<br />
<br />
=== SLiM init error with rc.d daemon ===<br />
<br />
If you initialize SLiM with {{ic|/etc/rc.conf}} inside the DAEMONS array and it fails to initialize it's most likely a lock file issue. SLiM creates a lock file in {{ic|/var/lock}} on each initialization, however, in most cases the lock folder in {{ic|/var}} does not exist preventing SLiM from initializing. Check to make sure {{ic|/var/lock}} exists, if it does not you can create it by typing the following:<br />
<br />
# mkdir /var/lock/<br />
<br />
=== Power-off error with Splashy ===<br />
<br />
If you use Splashy and SLiM, sometimes you can't power-off or reboot from menu in GNOME, Xfce, LXDE or others. Check your {{ic|/etc/slim.conf}} and {{ic|/etc/splash.conf}}; set the {{ic|1=DEFAULT_TTY=7}} same as {{ic|xserver_arguments vt07}}.<br />
<br />
=== Power-off tray icon fails ===<br />
<br />
If your power off tray icon fails, it could be due to not having root privileges. To start a tray icon with root privileges, be sure to have SLiM start the program. Edit {{ic|/etc/slim.conf}} as follows:<br />
sessionstart_cmd /path/to/tray/icon/program &<br />
<br />
=== Login information with SLiM ===<br />
<br />
By default, SLiM fails to log logins to utmp and wtmp which causes who, last, etc. to misreport login information. To fix this edit your {{ic|slim.conf}} as follows:<br />
<br />
sessionstart_cmd /usr/bin/sessreg -a -l $DISPLAY %user<br />
sessionstop_cmd /usr/bin/sessreg -d -l $DISPLAY %user<br />
<br />
=== Custom SLiM Login Commands ===<br />
<br />
You can also use the sessionstart_cmd/sessionstop_cmd in {{ic|/etc/slim.conf}} to log specific infomation, such as the session, user, or theme used by slim:<br />
<br />
sessionstop_cmd /usr/bin/logger -i -t ASKAPACHE "(sessionstop_cmd: u:%user s:%session t:%theme)"<br />
sessionstart_cmd /usr/bin/logger -i -t ASKAPACHE "(sessionstart_cmd: u:%user s:%session t:%theme)"<br />
<br />
Or if you want to play a song when slim loads (and you have the beep program installed)<br />
<br />
sessionstart_cmd /usr/bin/beep -f 659 -l 460 -n -f 784 -l 340 -n -f 659 -l 230 -n -f 659 -l 110<br />
<br />
=== SLiM and Gnome Keyring ===<br />
If you are using SLiM to launch a Gnome session and have trouble accessing your keyring, for example not being automatically authenticated on login, add the following lines to {{ic|/etc/pam.d/slim}} (as discussed [https://bugs.archlinux.org/task/18637 here]).<br />
auth optional pam_gnome_keyring.so<br />
session optional pam_gnome_keyring.so auto_start<br />
<br />
You also have to add to {{ic|/etc/pam.d/passwd}}:<br />
password optional pam_gnome_keyring.so<br />
<br />
If you use a screensaver you also have to add <br />
auth optional pam_gnome_keyring.so<br />
to {{ic|/etc/pam.d/gnome-screensaver}} for example (replace {{ic|gnome-screensaver}} with {{ic|slimlock}}, {{ic|slock}}, whatever you use). If you don't do that, your keyring is locked when screen is locked by your screensaver and not unlocked again after logging back in.<br />
<br />
However, this fix alone no longer works since Gnome 2.30. Further changes are necessary as described [https://bugs.archlinux.org/task/18930 here]. Modifying the {{ic|login_cmd}} line in {{ic|/etc/slim.conf}}:<br />
login_cmd exec dbus-launch /bin/bash -login ~/.xinitrc %session >~/.xsession-errors 2>&1<br />
<br />
As of GNOME 3.4, you need to edit {{ic|<nowiki>/etc/pam.d/{slim,passwd}</nowiki>}} as mentioned above, so that {{ic|<nowiki>/etc/pam.d/slim</nowiki>}} looks like:<br />
#%PAM-1.0<br />
auth requisite pam_nologin.so<br />
auth required pam_env.so<br />
auth required pam_unix.so<br />
auth optional pam_gnome_keyring.so<br />
account required pam_unix.so<br />
session required pam_limits.so<br />
session required pam_unix.so<br />
session optional pam_gnome_keyring.so auto_start<br />
password required pam_unix.so<br />
and {{ic|<nowiki>/etc/pam.d/passwd</nowiki>}}<br />
#%PAM-1.0<br />
password required pam_unix.so sha512 shadow nullok<br />
password optional pam_gnome_keyring.so<br />
As of 2012-10-13, {{ic|<nowiki>/etc/pam.d/gnome-screensaver</nowiki>}} already contains the {{ic|<nowiki>pam_gnome_keyring.so</nowiki>}} instruction.<br />
<br />
The correct positioning of the {{ic|<nowiki>pam_gnome_keyring.so</nowiki>}} instructions were taken from [http://live.gnome.org/GnomeKeyring/Pam here].<br />
<br />
After editing the above files, you need to edit {{ic|<nowiki>/etc/inittab</nowiki>}}.<br />
<br />
The solutions mentioned here and also further information are found [http://live.gnome.org/GnomeKeyring/Pam here].<br />
<br />
If you have problems keeping the keyring unlocked for longer sessions, there is another thing that Gnome does: <br />
Look at {{ic|<nowiki>/etc/xdg/autostart/{gnome-keyring-gpg.desktop, gnome-keyring-pkcs11.desktop, gnome-keyring-secrets.desktop, gnome-keyring-ssh.desktop}</nowiki>}}. <br />
<br />
Append the following lines to .xinitrc just before you start your wm (example here is awesome wm):<br />
/usr/bin/gnome-keyring-daemon --start --components=gpg<br />
/usr/bin/gnome-keyring-daemon --start --components=pkcs11<br />
/usr/bin/gnome-keyring-daemon --start --components=secrets<br />
/usr/bin/gnome-keyring-daemon --start --components=ssh<br />
/usr/bin/awesome<br />
<br />
After login check if there is only one gnome-keyring-daemon instance running ({{ic|ps -A | grep gnome}}). If those lines are executed too early then you have 4 instances running which is not good.<br />
<br />
You also should notice that seahorse for example does not show any pkcs11 errors anymore and that your keyring is unlocked all the time and does not lock itself anymore. Finally {{pkg|gnome-keyring}} is fully functional like in Gnome. See also [https://bbs.archlinux.org/viewtopic.php?pid=1019845#p1019845 here].<br />
<br />
=== Setting DPI with SLiM ===<br />
<br />
The Xorg server generally picks up the DPI but if it doesn't you can specify it to SLiM. If you set the DPI with the argument -dpi 96 in {{ic|/etc/X11/xinit/xserverrc}} it will not work with SLiM. To fix this change your {{ic|slim.conf}} from:<br />
<br />
xserver_arguments -nolisten tcp vt07 <br />
<br />
to<br />
<br />
xserver_arguments -nolisten tcp vt07 -dpi 96<br />
<br />
=== Use a random theme ===<br />
<br />
Use the {{ic|current_theme}} variable as a comma separated list to specify a set from which to choose. Selection is random.<br />
<br />
===Move the whole session to another VT===<br />
Lets say you have commented out tty terminals 3-6 as you may not use them. (You may use screen and therefore only need one terminal)<br />
So, to move the X-Server you need to change one number in the {{ic|/etc/slim.conf}} file. Just a few lines down you should see:<br />
xserver_arguments -nolisten tcp vt07<br />
<br />
Simply change the vt07 to lets say vt03 as there is no agetty started there.<br />
<br />
=== Automatically mount your encrypted /home on login ===<br />
<br />
You can use [[Pam_mount#Slim|pam_mount]].<br />
<br />
== All Slim Options ==<br />
Here is a list of all the slim configuration options and their default values.<br />
<br />
{{Note|welcome_msg allows 2 variables '''%host''' and '''%domain'''<br>sessionstart_cmd allows '''%user''' ''(execd right before login_cmd)'' and it is also allowed in sessionstop_cmd<br>login_cmd allows '''%session''' and '''%theme'''}}<br />
<br />
{| class="wikitable collapsible collapsable collapsed"<br />
|-<br />
! Option Name || Default Value<br />
|-<br />
| default_path ||{{ic|/bin:/usr/bin:/usr/local/bin}}<br />
|-<br />
| default_xserver ||{{ic|/usr/bin/X}}<br />
|-<br />
| xserver_arguments ||{{ic|vt07 -auth /var/run/slim.auth}}<br />
|-<br />
| numlock ||<br />
|-<br />
| daemon || {{ic|yes}}<br />
|-<br />
| xauth_path ||{{ic|/usr/bin/xauth}}<br />
|-<br />
| login_cmd ||{{ic|exec /bin/bash -login ~/.xinitrc %session}}<br />
|-<br />
| halt_cmd ||{{ic|/sbin/shutdown -h now}}<br />
|-<br />
| reboot_cmd ||{{ic|/sbin/shutdown -r now}}<br />
|-<br />
| suspend_cmd ||<br />
|-<br />
| sessionstart_cmd ||<br />
|-<br />
| sessionstop_cmd ||<br />
|-<br />
| console_cmd ||{{ic|/usr/bin/xterm -C -fg white -bg black +sb -g %dx%d+%d+%d -fn %dx%d -T }}<br />
|-<br />
| screenshot_cmd ||{{ic|import -window root /slim.png}}<br />
|-<br />
| welcome_msg ||{{ic|Welcome to %host}}<br />
|-<br />
| session_msg ||{{ic|Session:}}<br />
|-<br />
| default_user ||<br />
|-<br />
| focus_password ||{{ic|no}}<br />
|-<br />
| auto_login ||{{ic|no}}<br />
|-<br />
| current_theme ||{{ic|default}}<br />
|-<br />
| lockfile ||{{ic|/var/run/slim.lock}}<br />
|-<br />
| logfile ||{{ic|/var/log/slim.log}}<br />
|-<br />
| authfile ||{{ic|/var/run/slim.auth}}<br />
|-<br />
| shutdown_msg ||{{ic|The system is halting...}}<br />
|-<br />
| reboot_msg ||{{ic|The system is rebooting...}}<br />
|-<br />
| sessions ||{{ic|wmaker,blackbox,icewm}}<br />
|-<br />
| sessiondir ||<br />
|-<br />
| hidecursor ||{{ic|false}}<br />
|-<br />
| input_panel_x ||{{ic|50%}}<br />
|-<br />
| input_panel_y ||{{ic|40%}}<br />
|-<br />
| input_name_x ||{{ic|200}}<br />
|-<br />
| input_name_y ||{{ic|154}}<br />
|-<br />
| input_pass_x ||{{ic|-1}}<br />
|-<br />
| input_pass_y ||{{ic|-1}}<br />
|-<br />
| input_font ||{{ic|1=Verdana:size=11}}<br />
|-<br />
| input_color ||{{ic|#000000}}<br />
|-<br />
| input_cursor_height ||{{ic|20}}<br />
|-<br />
| input_maxlength_name ||{{ic|20}}<br />
|-<br />
| input_maxlength_passwd ||{{ic|20}}<br />
|-<br />
| input_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| input_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| input_shadow_color ||{{ic|#FFFFFF}}<br />
|-<br />
| welcome_font ||{{ic|1=Verdana:size=14}}<br />
|-<br />
| welcome_color ||{{ic|#FFFFFF}}<br />
|-<br />
| welcome_x ||{{ic|-1}}<br />
|-<br />
| welcome_y ||{{ic|-1}}<br />
|-<br />
| welcome_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| welcome_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| welcome_shadow_color ||{{ic|#FFFFFF}}<br />
|-<br />
| intro_msg ||<br />
|-<br />
| intro_font ||{{ic|1=Verdana:size=14}}<br />
|-<br />
| intro_color ||{{ic|#FFFFFF}}<br />
|-<br />
| intro_x ||{{ic|-1}}<br />
|-<br />
| intro_y ||{{ic|-1}}<br />
|-<br />
| background_style ||{{ic|stretch}}<br />
|-<br />
| background_color ||{{ic|#CCCCCC}}<br />
|-<br />
| username_font ||{{ic|1=Verdana:size=12}}<br />
|-<br />
| username_color ||{{ic|#FFFFFF}}<br />
|-<br />
| username_x ||{{ic|-1}}<br />
|-<br />
| username_y ||{{ic|-1}}<br />
|-<br />
| username_msg ||{{ic|Please enter your username}}<br />
|-<br />
| username_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| username_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| username_shadow_color ||{{ic|#FFFFFF}}<br />
|-<br />
| password_x ||{{ic|-1}}<br />
|-<br />
| password_y ||{{ic|-1}}<br />
|-<br />
| password_msg ||{{ic|Please enter your password}}<br />
|-<br />
| msg_color ||{{ic|#FFFFFF}}<br />
|-<br />
| msg_font ||{{ic|1=Verdana:size=16:bold}}<br />
|-<br />
| msg_x ||{{ic|40}}<br />
|-<br />
| msg_y ||{{ic|40}}<br />
|-<br />
| msg_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| msg_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| msg_shadow_color ||{{ic|#FFFFFF}}<br />
|-<br />
| session_color ||{{ic|#FFFFFF}}<br />
|-<br />
| session_font ||{{ic|1=Verdana:size=16:bold}}<br />
|-<br />
| session_x ||{{ic|50%}}<br />
|-<br />
| session_y ||{{ic|90%}}<br />
|-<br />
| session_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| session_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| session_shadow_color ||{{ic|#FFFFFF}}<br />
|}<br />
== Uninstallation ==<br />
To completely remove SLiM:<br />
{{bc| # pacman -Rns slim<br />
# rm /etc/systemd/system/display-manager.service<br />
}}<br />
== See also ==<br />
<br />
* [http://slim.berlios.de/ SLiM homepage]<br />
* [http://slim.berlios.de/manual.php SLiM documentation]</div>Signal-11https://wiki.archlinux.org/index.php?title=Netcfg&diff=237815Netcfg2012-12-03T04:24:40Z<p>Signal-11: /* Configuration */</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Networking]]<br />
[[es:Netcfg]]<br />
[[fr:Netcfg]]<br />
[[it:Netcfg]]<br />
[[ja:Netcfg]]<br />
[[ro:Netcfg]]<br />
[[ru:Netcfg]]<br />
[[tr:netcfg]]<br />
[[zh-CN:Netcfg]]<br />
{{Article summary start}}<br />
{{Article summary text|A guide to configuring the network using netcfg and network profile scripts.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Networking overview}}}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary wiki|Netcfg Tips}}<br />
{{Article summary wiki|Netcfg Troubleshooting}}<br />
{{Article summary link|Netcfg network scripts repository|https://projects.archlinux.org/netcfg.git/}}<br />
{{Article summary end}}<br />
<br />
Netcfg is used to configure and manage network connections via profiles. It has pluggable support for a range of connection types, such as wireless, Ethernet and [[Wikipedia:Point-to-point_protocol|PPP]]. It is also capable of starting/stopping many-to-one connections, that is, multiple connections within the same profile, optionally with bonding. Further it is useful for users seeking a simple and robust means of managing multiple network configurations (e.g. laptop users). With the push to drop support for {{Pkg|initscripts}}/SysV, netcfg is one of several choices users have to managing their network connectivity under [[systemd]].<br />
<br />
{{Note|1={{Pkg|netcfg}} >= 2.8.9 drops deprecated {{ic|/etc/[[rc.conf]]}} compatibility. Netcfg users should configure all interfaces in {{ic|/etc/conf.d/netcfg}} instead of {{ic|/etc/rc.conf}}.}}<br />
<br />
== Preparation ==<br />
<br />
In the simplest cases, users must at least know the name of their network interface(s) (e.g. {{ic|eth0}}, {{ic|wlan0}}). If configuring a static IP address, the IP addresses of the default gateway and name server(s) must also be known.<br />
<br />
If connecting to a wireless network, have some basic information ready. For a wireless network this includes what type of security is used, the network name (ESSID), and any passphrase or encryption keys. Additionally, ensure the proper drivers and firmware are installed for the wireless device, as described in [[Wireless Setup]].<br />
<br />
== Installation ==<br />
<br />
The {{Pkg|netcfg}} package is available in the [[Official Repositories|official repositories]]. As of {{Pkg|netcfg}} version 2.5.x, optional dependencies include {{Pkg|wpa_actiond}}, which is required for automatic/roaming wireless connections, and {{Pkg|ifplugd}}, which is required for automatic Ethernet configuration. See [https://www.archlinux.org/news/487/ the announcement].<br />
<br />
Users wanting [[Bash]] completion support for netcfg, install the {{Pkg|bash-completion}} package from the official repositories.<br />
<br />
== Configuration ==<br />
<br />
Network profiles are stored in {{ic|/etc/network.d/}}. To minimize the potential for errors, copy an example configuration from {{ic|/etc/network.d/examples/}} to {{ic|/etc/network.d/mynetwork}}. The file name is the name of the network profile, and {{ic|mynetwork}} is used as an example throughout this article.<br />
<br />
Depending on the connection type and security, use one of the following examples from {{ic|/etc/network.d/examples/}} as a base.<br />
<br />
{{Warning|Be wary of examples found on the internet as they often contain deprecated options that may cause problems!}}<br />
<br />
{| class="wikitable" align="center"<br />
! Connection !! Type !! Example Profile !! Information<br />
|-<br />
| rowspan="3"| '''Wired'''<br />
| Dynamic IP || {{ic|ethernet-dhcp}} ||<br />
|-<br />
| Static IP || {{ic|ethernet-static}} ||<br />
|-<br />
| Routed || {{ic|ethernet-iproute}} || Can be checked with {{ic|route}} from the {{Pkg|net-tools}} package.<br />
|-<br />
| rowspan="3"| '''Wireless'''<br />
| WPA-Personal<br />
| {{ic|wireless-wpa}} || Uses a passphrase/pre-shared key.<br />
|-<br />
| rowspan="2"| WPA-Enterprise<br />
| {{ic|wireless-wpa-config}} || The {{Pkg|wpa_supplicant}} configuration is external.<br />
|-<br />
| {{ic|wireless-wpa-configsection}} || The {{Pkg|wpa_supplicant}} configuration is stored as a string.<br />
|}<br />
<br />
Modify the new configuration file, {{ic|/etc/network.d/mynetwork}}:<br />
<br />
* Set {{ic|INTERFACE}} to the correct wireless or Ethernet interface. This can be checked with {{ic|ip link}} and {{ic|iwconfig}}.<br />
* Ensure the {{ic|ESSID}} and {{ic|KEY}} (passphrase) are set correctly for wireless connections. Typos in these fields are common errors.<br />
** Note that WEP ''string'' keys (not ''hex'' keys) must be specified with a leading {{ic|s:}} (e.g. {{ic|1=KEY="s:''somepasskey''"}}).<br />
<br />
{{Note|If you are using netcfg inside a VPS, please see [https://wiki.archlinux.org/index.php/Virtual_Private_Server#Moving_your_VPS_from_network_configuration_in_rc.conf_to_netcfg_.28tested_with_OpenVZ.29 the appropriate page].}}<br />
<br />
{{Note|Netcfg configurations are valid Bash scripts. Any configuration involving special characters such as {{ic|$}} or {{ic|\}} needs to be quoted correctly otherwise it will be interpreted by Bash. To avoid interpretation, use single quotes or backslash escape characters where appropriate.}}<br />
<br />
{{Note|Network information (e.g. wireless passkey) will be stored in plain text format, so users may want to change the permissions on the newly created profile (e.g. {{ic|chmod 0600 /etc/network.d/mynetwork}}) to make it readable by root only.}}<br />
<br />
{{Note|For WPA-Personal, it is also possible to [[Wpa_supplicant#Classic_method:_.2Fetc.2Fwpa_supplicant.conf|encode the WPA passkey into a hexadecimal string]]. Save the new hexadecimal string into the wireless WPA profile in {{ic|/etc/network.d/mynetwork}} as the value of the {{ic|KEY}} variable (make sure this will be the only {{ic|KEY}} variable enabled), to look similar to this: {{ic|1=KEY='7b271c9a7c8a6ac07d12403a1f0792d7d92b5957ff8dfd56481ced43ec6a6515'}}. That should disable the need to reveal the passkey.}}<br />
<br />
{{<br />
Note|1=By default netcfg uses dhcpcd for configuring network interfaces. An alternate to dhcpcd is dhclient. To use dhclient, set DHCLIENT='yes' in appropriate profile configuration.<br />
}}<br />
<br />
== Manual Operation ==<br />
<br />
To connect a profile:<br />
<br />
# netcfg mynetwork<br />
<br />
To disconnect a profile:<br />
<br />
# netcfg down mynetwork<br />
<br />
If successful, users can configure netcfg to connect automatically or during boot. If the connection fails, see [[Netcfg Troubleshooting]] for solutions and for how to ask for help.<br />
<br />
Additionally, see:<br />
<br />
$ netcfg help<br />
<br />
== Automatic Operation ==<br />
<br />
=== Just one profile ===<br />
<br />
In the simplest case, only one profile will be used and is always desired to start on boot:<br />
<br />
# systemctl enable netcfg@myprofile<br />
<br />
=== Net-Profiles ===<br />
<br />
Edit the {{ic|NETWORKS}} array in {{ic|/etc/conf.d/netcfg}} to refer to the network config file {{ic|/etc/network.d/mynetwork}}.<br />
<br />
{{hc|/etc/conf.d/netcfg|2=<br />
NETWORKS=(mynetwork yournetwork)}}<br />
<br />
Start the service on startup:<br />
<br />
# systemctl enable netcfg<br />
<br />
Alternatively, the profiles that were active at last shutdown can be restored by setting the {{ic|NETWORKS}} array to {{ic|last}}.<br />
<br />
{{hc|/etc/conf.d/netcfg|2=<br />
NETWORKS=(last)}}<br />
<br />
{{Note|For {{ic|NETWORKS&#61;(last)}} to work, you will have to connect to your network manually first and then stop the daemon for Netcfg to remember the network. You can stop the Netcfg daemon by running {{ic|netcfg-daemon stop}} as root.}}<br />
<br />
Finally, {{ic|net-profiles}} can be configured to display a menu&mdash;allowing users to choose a desired profile&mdash;by setting the contents of the {{ic|NETWORKS}} array to {{ic|menu}}:<br />
<br />
{{hc|/etc/conf.d/netcfg|2=<br />
NETWORKS=(menu)}}<br />
<br />
Additionally, the {{Pkg|dialog}} package is required.<br />
<br />
{{Note|The {{ic|1=NETWORKS=(menu)}} setting cannot be used anymore when switching to systemd. See {{bug|31377}} for details.}}<br />
<br />
{{Tip|Access the menu at any time by running {{ic|netcfg-menu}} in a terminal.}}<br />
<br />
=== Net-Auto-Wireless ===<br />
<br />
This allows users to automatically connect to wireless networks with proper roaming support. To use this feature, the {{Pkg|wpa_actiond}} package is required. Note that {{ic|wireless-wpa-config}} profiles do not work with {{ic|net-auto-wireless}}. Convert them to {{ic|wireless-wpa-configsection}} or {{ic|wireless-wpa}} instead.<br />
<br />
Specify the desired wireless interface with the {{ic|WIRELESS_INTERFACE}} variable in {{ic|/etc/conf.d/netcfg}} or define a list of wireless networks that should be automatically connected with the {{ic|AUTO_PROFILES}} variable in {{ic|/etc/conf.d/netcfg}}.<br />
<br />
{{Note|If AUTO_PROFILES is not set, all wireless networks will be tried.}}<br />
<br />
Enable {{ic|net-auto-wireless.service}} so systemd manages it.<br />
<br />
# systemctl enable net-auto-wireless<br />
<br />
=== Net-Auto-Wired ===<br />
<br />
This allows users to automatically connect to wired networks. To use this feature, the {{Pkg|ifplugd}} package is required.<br />
<br />
Specify the desired wired interface with the {{ic|WIRED_INTERFACE}} variable in {{ic|/etc/conf.d/netcfg}}.<br />
<br />
Enable {{ic|net-auto-wired.service}} so systemd manages it.<br />
<br />
# systemctl enable net-auto-wired<br />
<br />
The daemon starts an {{ic|ifplugd}} process which runs {{ic|/etc/ifplugd/netcfg.action}} when the status of the wired interface changes (e.g. a cable is plugged in or unplugged). On plugging in a cable, attempts are made to start any profiles with {{ic|1=CONNECTION = "ethernet"}} or {{ic|"ethernet-iproute"}} and {{ic|1=INTERFACE = WIRED_INTERFACE}} until one of them succeeds.<br />
<br />
{{Note|DHCP profiles are tried before static ones, which could lead to undesired results in some cases. However, one can tell netcfg to prefer a particular interface by adding {{ic|1=AUTO_WIRED=1}} to the desired profile.}}<br />
<br />
{{Note|The {{ic|net-auto-wired}} daemon cannot start multiple ifplugd processes for multiple interfaces (unlike ifplugd's own {{ic|/etc/rc.d/ifplugd}} which can).}}<br />
<br />
== FAQ ==<br />
<br />
{{FAQ<br />
|question=Why doesn't netcfg do ''(some feature)''?<br />
|answer=Netcfg does not need to; it connects to networks. Netcfg is modular and re-usable. See {{ic|/usr/lib/network}} for re-usable functions for custom scripts.}}<br />
<br />
{{FAQ<br />
|question=Why doesn't netcfg behave in ''this'' way?<br />
|answer=Netcfg does not enforce any rules; it connects to networks. Netcfg does not impose any heuristics, like "disconnect from wireless if Ethernet is connected". If you want such behavior, it should be simple to write a separate tool on top of netcfg. See the question above. Alternatively, you could be creative with the use of netcfg's {{ic|POST_UP}} functionality to handle some use cases.}}<br />
<br />
{{FAQ<br />
|question=Do I need anything else if I'm using netcfg?<br />
|answer=This question usually references {{ic|/etc/hosts}} and {{ic|/etc/hostname}}, which are both still required.}}</div>Signal-11