https://wiki.archlinux.org/api.php?action=feedcontributions&user=Kay94&feedformat=atomArchWiki - User contributions [en]2024-03-28T22:28:25ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Tor&diff=512412Tor2018-03-01T18:37:19Z<p>Kay94: Removed statement about opening 443 port forwarding as solution for "0.0.0.0:443: Permission denied" which is wrong and provided actual solution.</p>
<hr />
<div>[[Category:Anonymity networks]]<br />
[[es:Tor]]<br />
[[fr:Tor]]<br />
[[ja:Tor]]<br />
[[ru:Tor]]<br />
[[zh-hans:Tor]]<br />
[[de:Tor]]<br />
[[pl:Tor]]<br />
{{Related articles start}}<br />
{{Related|GNUnet}}<br />
{{Related|I2P}}<br />
{{Related|Freenet}}<br />
{{Related articles end}}<br />
[https://www.torproject.org Tor] is an open source implementation of 2nd generation [[Wikipedia:Onion routing|onion routing]] that provides free access to an anonymous proxy network. Its primary goal is to enable [[Wikipedia:Internet anonymity|online anonymity]] by protecting against [[Wikipedia:Traffic analysis|traffic analysis]] attacks.<br />
<br />
== Introduction ==<br />
<br />
Users of the Tor network run an onion proxy on their machine. This software connects out to Tor, periodically negotiating a virtual circuit through the Tor network. Tor employs cryptography in a layered manner (hence the 'onion' analogy), ensuring perfect forward secrecy between routers. At the same time, the onion proxy software presents a SOCKS interface to its clients. SOCKS-aware applications may be pointed at Tor, which then multiplexes the traffic through a Tor virtual circuit.<br />
<br />
{{Warning|Tor by itself is ''not'' all you need to maintain your anonymity. There are several major pitfalls to watch out for (see: [https://www.torproject.org/download/download.html#warning Want Tor to really work?]).}}<br />
<br />
Through this process the onion proxy manages networking traffic for end-user anonymity. It keeps a user anonymous by encrypting traffic, sending it through other nodes of the Tor network, and decrypting it at the last node to receive your traffic before forwarding it to the server you specified. One trade off that has to be made for the anonymity Tor provides is that it can be considerably slower than a regular direct connection, due to the large amount of traffic re-routing. Additionally, although Tor provides protection against traffic analysis it cannot prevent traffic confirmation at the boundaries of the Tor network (i.e. the traffic entering and exiting the network).<br />
<br />
See [[Wikipedia:Tor (anonymity network)]] for more information.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|tor}} package.<br />
<br />
Usually, you will access Tor using Tor Browser, available as the {{AUR|tor-browser}} package or a [https://www.torproject.org/projects/torbrowser.html.en portable executable].<br />
<br />
The {{Pkg|arm}} (Anonymizing Relay Monitor) package provides a terminal status monitor for bandwidth usage, connection details and more.<br />
<br />
== Configuration ==<br />
<br />
By default Tor reads configurations from the file {{ic|/etc/tor/torrc}}. The configuration options are explained in {{man|1|tor}} and the [https://torproject.org/docs/tor-manual.html.en Tor website]. The default configuration should work fine for most Tor users.<br />
<br />
There are potential conflicts between configurations in {{ic|torrc}} and those in {{ic|tor.service}}.<br />
* In {{ic|torrc}}, {{ic|RunAsDaemon}} should, as by default, be set to {{ic|0}}, since {{ic|Type<nowiki>=</nowiki>simple}} is set in the {{ic|[Service]}} section in {{ic|tor.service}}.<br />
* In {{ic|torrc}}, {{ic|User}} should not be set unless {{ic|User<nowiki>=</nowiki>}} is set to {{ic|root}} in the {{ic|[Service]}} section in {{ic|tor.service}}.<br />
<br />
=== Relay Configuration ===<br />
<br />
The maximum file descriptor number that can be opened by Tor can be set with {{ic|LimitNOFILE}} in {{ic|tor.service}}. Fast relays may want to increase this value.<br />
<br />
If your computer is not running a webserver, and you have not set {{ic|AccountingMax}}, consider changing your {{ic|ORPort}} to {{ic|443}} and/or your {{ic|DirPort}} to {{ic|80}}. Many Tor users are stuck behind firewalls that only let them browse the web, and this change will let them reach your Tor relay. If you are already using ports {{ic|80}} and {{ic|443}}, other useful ports are {{ic|22}}, {{ic|110}}, and {{ic|143}}.[https://www.torproject.org/docs/tor-relay-debian]<br />
But since these are privileged ports, to do so Tor must be run as root, by setting {{ic|User<nowiki>=</nowiki>root}} in {{ic|tor.service}} and {{ic|User tor}} in {{ic|torrc}}.<br />
<br />
You may wish to review [https://blog.torproject.org/blog/lifecycle-of-a-new-relay Lifecycle of a New Relay] Tor documentation.<br />
<br />
== Running Tor in a Chroot ==<br />
<br />
{{Warning| Connecting with telnet to the local ControlPort seems to be broken while running Tor in a chroot}}<br />
<br />
For security purposes, it may be desirable to run Tor in a [[chroot]]. The following script will create an appropriate chroot in {{ic|/opt/torchroot}}:<br />
<br />
{{hc|~/torchroot-setup.sh|2=<nowiki><br />
#!/bin/bash<br />
export TORCHROOT=/opt/torchroot<br />
<br />
mkdir -p $TORCHROOT<br />
mkdir -p $TORCHROOT/etc/tor<br />
mkdir -p $TORCHROOT/dev<br />
mkdir -p $TORCHROOT/usr/bin<br />
mkdir -p $TORCHROOT/usr/lib<br />
mkdir -p $TORCHROOT/usr/share/tor<br />
mkdir -p $TORCHROOT/var/lib<br />
<br />
ln -s /usr/lib $TORCHROOT/lib<br />
cp /etc/hosts $TORCHROOT/etc/<br />
cp /etc/host.conf $TORCHROOT/etc/<br />
cp /etc/localtime $TORCHROOT/etc/<br />
cp /etc/nsswitch.conf $TORCHROOT/etc/<br />
cp /etc/resolv.conf $TORCHROOT/etc/<br />
cp /etc/tor/torrc $TORCHROOT/etc/tor/<br />
<br />
cp /usr/bin/tor $TORCHROOT/usr/bin/<br />
cp /usr/share/tor/geoip* $TORCHROOT/usr/share/tor/<br />
cp /lib/libnss* /lib/libnsl* /lib/ld-linux-*.so* /lib/libresolv* /lib/libgcc_s.so* $TORCHROOT/usr/lib/<br />
cp $(ldd /usr/bin/tor | awk '{print $3}'|grep --color=never "^/") $TORCHROOT/usr/lib/<br />
cp -r /var/lib/tor $TORCHROOT/var/lib/<br />
chown -R tor:tor $TORCHROOT/var/lib/tor<br />
<br />
sh -c "grep --color=never ^tor /etc/passwd > $TORCHROOT/etc/passwd"<br />
sh -c "grep --color=never ^tor /etc/group > $TORCHROOT/etc/group"<br />
<br />
mknod -m 644 $TORCHROOT/dev/random c 1 8<br />
mknod -m 644 $TORCHROOT/dev/urandom c 1 9<br />
mknod -m 666 $TORCHROOT/dev/null c 1 3<br />
<br />
if [[ "$(uname -m)" == "x86_64" ]]; then<br />
cp /usr/lib/ld-linux-x86-64.so* $TORCHROOT/usr/lib/.<br />
ln -sr /usr/lib64 $TORCHROOT/lib64<br />
ln -s $TORCHROOT/usr/lib ${TORCHROOT}/usr/lib64<br />
fi<br />
<br />
</nowiki>}}<br />
<br />
After running the script as root, Tor can be launched in the [[chroot]] with the command:<br />
<br />
# chroot --userspec=tor:tor /opt/torchroot /usr/bin/tor<br />
<br />
or if you use systemd overload the service:<br />
<br />
{{hc|/etc/systemd/system/tor.service.d/chroot.conf|2=<nowiki><br />
[Service]<br />
User=root<br />
ExecStart=<br />
ExecStart=/usr/bin/sh -c "chroot --userspec=tor:tor /opt/torchroot /usr/bin/tor -f /etc/tor/torrc"<br />
KillSignal=SIGINT<br />
</nowiki>}}<br />
<br />
== Running Tor in a systemd-nspawn container with a virtual network interface ==<br />
In this example we will create a [[systemd-nspawn]] container named {{ic|tor-exit}} with a virtual macvlan network interface.<br />
<br />
See [[Systemd-nspawn]] and [[systemd-networkd]] for full documentation.<br />
<br />
=== Host installation and configuration ===<br />
<br />
In this example the container will reside in {{ic|/srv/container}}:<br />
# mkdir /srv/container/tor-exit<br />
<br />
[[Install]] the {{Pkg|arch-install-scripts}}.<br />
<br />
Install {{Grp|base}}, {{Pkg|tor}} and {{Pkg|arm}} and deselect {{Pkg|linux}} as per [[Systemd-nspawn#Create and boot a minimal Arch Linux distribution in a container]]:<br />
# pacstrap -i -c -d /srv/container/tor-exit base tor arm<br />
<br />
Create directory if it does not exist:<br />
# mkdir /var/lib/container<br />
<br />
{{Note|Symlinks for {{ic|nspawn}} are currently broken (as of 2016-02-04; see https://github.com/systemd/systemd/issues/2001), and will give you a "too many levels of symlinks" error. As a (possibly insecure) workaround, simply pacstrap your install to the container directory instead.}}<br />
Symlink to register the container on the host, as per [[Systemd-nspawn#Enable container on boot]]:<br />
# ln -s /srv/container/tor-exit /var/lib/container/tor-exit<br />
<br />
==== Virtual network interface ====<br />
<br />
Create a Dropin directory for the container service:<br />
# mkdir /etc/systemd/system/systemd-nspawn@tor-exit.service.d<br />
<br />
{{hc|/etc/systemd/system/systemd-nspawn@tor-exit.service.d/tor-exit.conf|<nowiki><br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=guest --network-macvlan=$INTERFACE --private-network --directory=/var/lib/container/%i<br />
LimitNOFILE=32768<br />
</nowiki>}}<br />
<br />
{{ic|<nowiki>--network-macvlan=$INTERFACE --private-network</nowiki>}} automagically creates a macvlan named {{ic|mv-$INTERFACE}} inside the container, which is not visible from the host. {{ic|--private-network}} is implied by {{ic|<nowiki>--network-macvlan=</nowiki>}} according to {{man|1|systemd-nspawn}}.<br />
This is advisable for security as it will allow you to give a private IP to the container, and it won't know what your machine's IP is. This can help obscure DNS requests.<br />
<br />
{{ic|<nowiki>LimitNOFILE=32768</nowiki>}} per [[#Raise maximum number of open file descriptors]].<br />
<br />
Setup [[systemd-networkd]] according to your network in {{ic|/srv/container/tor-exit/etc/systemd/network/mv-$INTERFACE.network}}.<br />
<br />
==== Start and enable systemd-nspawn ====<br />
<br />
[[Start]] and enable {{ic|systemd-nspawn@tor-exit.service}}.<br />
<br />
=== Container configuration ===<br />
{{ic|# machinectl login tor-exit}} login to the container, see [[Systemd-nspawn#machinectl]].<br />
<br />
{{ic|# mv /srv/container/tor-exit/etc/securetty /srv/container/tor-exit/etc/securetty.bak}} if you get the error described in [[Systemd-nspawn#Troubleshooting]].<br />
<br />
==== Start and enable systemd-networkd ====<br />
<br />
[[Start]] and enable {{ic|systemd-networkd.service}}. {{ic|networkctl}} displays if {{ic|systemd-networkd}} is correctly configured.<br />
<br />
=== Configure Tor ===<br />
See [[#Running a Tor server]].<br />
{{Tip|It is easier to edit files in the container from the host with your normal editor.}}<br />
<br />
== Usage ==<br />
<br />
Start/enable {{ic|tor.service}} [[systemd#Using units|using systemd]]. Alternatively, launch it with {{ic|sudo -u tor /usr/bin/tor}}.<br />
<br />
To use a program over tor, configure it to use {{ic|127.0.0.1}} or localhost as a SOCKS5 proxy, with port {{ic|9050}} (plain tor with standard settings).<br />
To check if Tor is functioning properly visit the [https://check.torproject.org/ Tor], [http://serifos.eecs.harvard.edu/cgi-bin/ipaddr.pl?tor=1 Harvard] or [https://torcheck.xenobite.eu/ Xenobite.eu] websites.<br />
<br />
== Web browsing ==<br />
<br />
The Tor Project currently only supports web browsing with tor through the [https://aur.archlinux.org/packages/?K=tor-browser Tor Browser], which can be downloaded from the AUR. It is built with a patched version of the Firefox extended support releases. Tor can also be used with regular [[Firefox]], [[Chromium]] and other browsers.<br />
<br />
{{Warning |Tor Project strongly recommends only using the Tor browser if you want to stay anonymous [https://www.torproject.org/docs/faq.html.en#TBBOtherBrowser not recommended].}}<br />
<br />
{{Tip|For makepkg to verify the signature on the AUR source tarball download for TBB, import the [https://www.torproject.org/docs/signing-keys.html.en signing keys from the Tor Project] (currently 2E1AC68ED40814E0) as explained in [[GnuPG#Use a keyserver]].}}<br />
<br />
=== Firefox ===<br />
<br />
In ''Preferences > General > Network Proxy > Settings'' select "Manual proxy configuration" and enter SOCKS host {{ic|localhost}} with port {{ic|9050}} (SOCKS v5). To channel all DNS requests through TOR's socks proxy, also select "Proxy DNS when using SOCKS v5".<br />
<br />
{{Note|When using Firefox 55 or earlier (e.g. 52 ESR), the settings are located in ''Preferences > Advanced > Network > Settings'' instead.}}<br />
<br />
=== Chromium ===<br />
<br />
You can simply run:<br />
<br />
$ chromium --proxy-server="socks5://myproxy:8080" --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE myproxy"<br />
<br />
The {{ic|<nowiki>--proxy-server="socks5://myproxy:8080"</nowiki>}} flag tells Chrome to send all {{ic|http://}} and {{ic|https://}} URL requests through the SOCKS proxy server {{ic|"myproxy:8080"}}, using version 5 of the SOCKS protocol. The hostname for these URLs will be resolved by the proxy server, and not locally by Chrome.<br />
<br />
{{warning|Proxying of {{ic|ftp://}} URLs through a SOCKS proxy is not yet implemented[https://www.chromium.org/developers/design-documents/network-stack/socks-proxy].}}<br />
<br />
The {{ic|--proxy-server}} flag applies to URL loads only. There are other components of Chrome which may issue DNS resolves directly and hence bypass this proxy server. The most notable such component is the "DNS prefetcher". Hence if DNS prefetching is not disabled in Chrome then you will still see local DNS requests being issued by Chrome despite having specified a SOCKS v5 proxy server. Disabling DNS prefetching would solve this problem, however it is a fragile solution since once needs to be aware of all the areas in Chrome which issue raw DNS requests. To address this, the next flag, {{ic|<nowiki>--host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE myproxy"</nowiki>}}, is a catch-all to prevent Chrome from sending any DNS requests over the network. It says that all DNS resolves are to be simply mapped to the (invalid) address {{ic|~NOTFOUND}} (think of it as {{ic|0.0.0.0}}). The {{ic|"EXCLUDE"}} clause make an exception for {{ic|"myproxy"}}, because otherwise Chrome would be unable to resolve the address of the SOCKS proxy server itself, and all requests would necessarily fail with {{ic|PROXY_CONNECTION_FAILED}}.<br />
<br />
To prevent the [https://ipleak.net/#webrtcleak WebRTC leak] you can install the extension [https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia WebRTC Network Limiter].<br />
<br />
==== Debug ====<br />
<br />
The first thing to check when debugging is look at the Proxy tab on about:net-internals, and verify what the effective proxy settings are:<br />
{{ic|chrome://net-internals/#proxy}}<br />
<br />
Next, take a look at the DNS tab of {{ic|about:net-internals}} to make sure Chrome isn't issuing local DNS resolves:<br />
{{ic|chrome://net-internals/#dns}}<br />
<br />
==== Extension ====<br />
Just as with Firefox, you can setup a fast switch for example through [https://chrome.google.com/webstore/detail/dpplabbmogkhghncfbfdeeokoefdjegm Proxy SwitchySharp].<br />
<br />
Once installed enter in its configuration page. Under the tab ''Proxy Profiles'' add a new profile ''Tor'', if ticked untick the option ''Use the same proxy server for all protocols'', then add ''localhost'' as SOCKS Host, ''9050'' to the respective port and select ''SOCKS v5''.<br />
<br />
Optionally you can enable the quick switch under the ''General'' tab to be able to switch beetween normal navigation and Tor network just by left-clicking on the Proxy SwitchySharp's icon.<br />
<br />
=== Luakit ===<br />
<br />
{{warning|It will not be hard for an observer to identify you by the rare user-agent string, and there may be further issues with Flash, JavaScript or similar.}}<br />
<br />
You can simply run:<br />
<br />
$ torsocks luakit<br />
<br />
== HTTP proxy ==<br />
<br />
Tor can be used with an HTTP proxy like [[Polipo]] or [[Privoxy]], however the Tor dev team recommends using the SOCKS5 library since browsers directly support it.<br />
<br />
=== Firefox ===<br />
<br />
The [https://addons.mozilla.org/en-us/firefox/addon/foxyproxy-standard/ FoxyProxy] add-on allows you to specify multiple proxies for different URLs or for all your browsing. After restarting Firefox manually set Firefox to port {{ic|8118}} on {{ic|localhost}}, which is where [[Polipo]] or [[Privoxy]] are running. These settings can be access under ''Add > Standard proxy type''. Select a proxy label (e.g Tor) and enter the port and host into the ''HTTP Proxy'' and ''SSL Proxy'' fields. To check if Tor is functioning properly visit the [https://check.torproject.org/ Tor Check] website and toggle Tor.<br />
<br />
=== Polipo ===<br />
<br />
The Tor Project has created a custom [https://gitweb.torproject.org/torbrowser.git/plain/build-scripts/config/polipo.conf?id=1ffcd9dafb9dd76c3a29dd686e05a71a95599fb5 Polipo configuration file] to prevent potential problems with Polipo as well to provide better anonymity.<br />
<br />
Keep in mind that Polipo is not required if you can use a SOCKS 5 proxy, which Tor starts automatically on port 9050. If you want to use [[Chromium]] with Tor, you do not need the Polipo package (see: [[#Chromium]]).<br />
<br />
=== Privoxy ===<br />
<br />
You can also use this setup in other applications like messaging (e.g. Jabber, IRC). Applications that support HTTP proxies you can connect to Privoxy (i.e. {{ic|127.0.0.1:8118}}). To use SOCKS proxy directly, you can point your application at Tor (i.e. {{ic|127.0.0.1:9050}}). A problem with this method though is that applications doing DNS resolves by themselves may leak information. Consider using Socks4A (e.g. with Privoxy) instead.<br />
<br />
== Instant messaging ==<br />
<br />
In order to use an IM client with tor, we do not need an http proxy like [[polipo]]/[[privoxy]]. We will be using tor's daemon directly which listens to port 9050 by default.<br />
<br />
=== Pidgin ===<br />
<br />
You can set up Pidgin to use Tor globally, or per account. To use Tor globally, go to Tools -> Preferences -> Proxy. To use Tor for specific accounts, go to ''Accounts > Manage Accounts'', select the desired account, click Modify, then go to the Proxy tab. The proxy settings are as follows:<br />
<br />
Proxy type SOCKS5<br />
Host 127.0.0.1<br />
Port 9150<br />
<br />
Note that [https://trac.torproject.org/projects/tor/ticket/8135 some time in 2013] the Port has changed from 9050 to 9150 if you use the Tor Browser Bundle. Try the other value if you receive a "Connection refused" message.<br />
<br />
== Irssi ==<br />
<br />
{{Out of date|{{ic|cap_sasl.pl}} is broken with ''perl'' 5.20; SSL does also not work with {{ic|torsocks}}}}<br />
<br />
Freenode recommends connecting to {{ic|.onion}} directly. It also requires charybdis and ircd-seven's SASL mechanism for identifying to nickserv during connection; see [[Irssi#Authenticating with SASL]]. Start irssi:<br />
<br />
$ torsocks irssi<br />
<br />
Set your identification to nickserv, which will be read when connecting. Supported mechanisms are ECDSA-NIST256P-CHALLENGE (see [https://github.com/atheme/ecdsatool/blob/master/cap_sasl.pl ecdsatool]) and PLAIN. DH-BLOWFISH is [https://freenode.net/sasl/sasl-irssi.shtml no longer supported].<br />
<br />
/sasl set ''network'' ''username'' ''password'' ''mechanism''<br />
<br />
Disable CTCP and DCC and set a different hostname to prevent information disclosure: [https://encrypteverything.ca/IRC_Anonymity_Guide]<br />
<br />
/ignore * CTCPS<br />
/ignore * DCC<br />
/set hostname ''fake_host''<br />
<br />
Connect to Freenode:<br />
<br />
/connect -network ''network'' frxleqtzgvwkv7oz.onion<br />
<br />
For more information check [http://freenode.net/irc_servers.shtml#tor Accessing freenode Via Tor], [http://freenode.net/sasl/README.txt SASL README] or [https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IrcSilc IRC/SILC Wiki article].<br />
<br />
== Pacman ==<br />
Pacman download operations (repository DBs, packages, and public keys) can be done using the Tor network.<br />
<br />
Advantages:<br />
* Attackers that can monitor your Internet connection and that specifically targets your machine cannot watch the updates anymore and, because of that, they cannot deduce the packages you have installed, how up to date they are, when or how frequently you update them. An attacker can still learn what software and the versions you use by other means, for instance watching the packets from your http server or probing the machine will show that you have an http server installed and its version.<br />
* If the mirror is not an onion, a malicious exit nodes you are going through can watch the updates, and may decide to attack you, however they probably cannot know who they are attacking.<br />
* Attackers trying to make your machine believe that there are no new updates to prevent it from getting security fixes will have a harder time doing it since they cannot target your machine specifically.<br />
<br />
Disadvantages:<br />
* Longer updates times due to longer latency and lower throughput. This can be a big security risk if/when the updates needs to be done as fast as possible, especially on machines directly connected to the Internet. That is the case when there is a huge security flaw, and that the flaws are fast to probe, easy to exploit, and that attackers have already started targeting as many systems as they can before the systems are updated.<br />
<br />
Reliability with Tor:<br />
* You don't need a working DNS anymore.<br />
* You depend on the Tor network and the exit nodes not blocking the updates.<br />
* You depend on the Tor daemon to work properly. The Tor daemon may not work if there is no more disk space available to it. "Reserved blocks gid:" in ext4, quotas, or other means can fix that.<br />
* If you are in a country where Tor is blocked, or that there are almost or no Tor users at all, you should use bridges.<br />
<br />
Note on gpg:<br />
On stock arch, pacman only trust keys which are either signed by you (That can be done with pacman-key --lsign-key) or signed by 2 of 5 Arch master keys. If a malicious exit node replaces packages with ones signed by its key, pacman will not let the user install the package. {{Warning| This might not be true for other distributions derived from ARCH, for non-official repositories and for AUR}}<br />
<br />
{{hc|/etc/pacman.conf|<br />
...<br />
<nowiki>XferCommand = /usr/bin/curl --socks5-hostname localhost:9050 -C - -f %u > %o</nowiki><br />
...}}<br />
<br />
== Running a Tor server ==<br />
<br />
The Tor network is reliant on people contributing bandwidth and setting up services. There are several ways to contribute to the network.<br />
<br />
=== Running a Tor bridge ===<br />
<br />
A Tor bridge is a Tor relay that is not listed in the public Tor directory, thus making it possible for people to connect to the Tor network when governments or ISPs block all public Tor relays.<br />
<br />
==== Configuration ====<br />
<br />
According to https://www.torproject.org/docs/bridges , make your {{ic|torrc}} be just these four lines (Default: {{ic|/etc/tor/torrc}}, or {{ic|$HOME/.torrc}} if that file is not found)<br />
:<br />
<br />
SocksPort 0<br />
ORPort 443<br />
BridgeRelay 1<br />
Exitpolicy reject *:*<br />
<br />
==== Troubleshooting ====<br />
<br />
If you get "Could not bind to 0.0.0.0:443: Permission denied" errors on startup, you can either pick a higher ORPort (e.g. 8080), or grant the process (/usr/bin/tor in this case) the right to open ports lower than 1000 by doing the following:<br />
<br />
setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/tor<br />
sudo -u tor /usr/bin/tor -f /etc/tor/torrc<br />
<br />
Refer to [https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443 superuser.com] for further explanations.<br />
<br />
=== Running a Tor relay ===<br />
<br />
This means that your machine will act as an entry node or forwarding relay and, unlike a bridge, it will be listed in the public Tor directory. Your IP address will be publicly visible in the Tor directory but the relay will only forward to other relays or Tor exit nodes, not directly to the internet.<br />
<br />
==== Configuration ====<br />
<br />
You should at least share 20KiB/s:<br />
<br />
Nickname ''tornickname''<br />
ORPort 9001 # This TCP-Port has to be opened/forwarded in your Firewall<br />
BandwidthRate 20 KB # Throttle traffic to 20KB/s<br />
BandwidthBurst 50 KB # But allow bursts up to 50KB/s<br />
<br />
Disallow exits from your relay:<br />
<br />
ExitPolicy reject *:*<br />
<br />
=== Running a Tor exit node ===<br />
<br />
Any requests from a Tor user to the regular internet obviously need to exit the network somewhere, and exit nodes provide this vital service. To the accessed host, the request will appear as having originated from your machine. This means that running an exit node is generally considered more legally onerous than running other forms of Tor relays. Before becoming an exit relay, you may want to read [https://blog.torproject.org/running-exit-node Tips for Running an Exit Node With Minimal Harassment].<br />
<br />
==== Configuration ====<br />
<br />
Using the torrc, you can configure which services you wish to allow through your exit node.<br />
Allow all traffic:<br />
<br />
ExitPolicy accept *:*<br />
<br />
Allow only irc ports 6660-6667 to exit from node:<br />
<br />
ExitPolicy accept *:6660-6667,reject *:* # Allow irc ports but no more<br />
<br />
By default, Tor will block certain ports. You can use the torrc to overide this.<br />
<br />
ExitPolicy accept *:119 # Accept nntp as well as default exit policy<br />
<br />
==== +100Mbps Exit Relay configuration example ====<br />
<br />
If you run a fast exit relay (+100Mbps) with {{ic|ORPort 443}} and {{ic|DirPort 80}} (as recommended in [http://www.torproject.org/docs/tor-relay-debian.html.en#after Configuring a Tor relay on Debian/Ubuntu]) the following configuration changes might serve as inspiration to setup Tor alongside [[iptables]] firewall, [[Haveged]] to increase system entropy and [[pdnsd]] as DNS cache. It is important to ''first'' read [http://www.torproject.org/docs/tor-relay-debian.html.en#after Configuring a Tor relay on Debian/Ubuntu]. <br />
<br />
{{Note|See [[#Running Tor in a systemd-nspawn container with a virtual network interface]] for instructions to install Tor in a {{ic|systemd-nspawn}} container. [[Haveged]] should be installed on the container host.}}<br />
<br />
===== Tor =====<br />
====== Raise maximum number of open file descriptors ======<br />
To handle more than 8192 connections {{ic|LimitNOFILE}} can be raised to 32768 as per [https://www.torproject.org/docs/faq.html.en#PackagedTor Tor FAQ].<br />
<br />
{{hc|/etc/systemd/system/tor.service.d/increase-file-limits.conf|<nowiki><br />
[Service]<br />
LimitNOFILE=32768<br />
</nowiki>}}<br />
<br />
To succesfully raise {{ic|nofile}} limit, you may also have to append the following:<br />
<br />
{{hc|/etc/security/limits.conf|<nowiki><br />
...<br />
tor soft nofile 32768<br />
tor hard nofile 32768<br />
@tor soft nofile 32768<br />
@tor hard nofile 32768<br />
</nowiki>}}<br />
<br />
Check if the {{ic|nofile}} (filedescriptor) limit is successfully raised with {{ic|# sudo -u tor 'ulimit -Hn'}} or {{ic|# sudo -u tor bash}} and {{ic|# ulimit -Hn}}.<br />
<br />
====== Start tor.service as root to bind Tor to privileged ports ======<br />
To bind Tor to privileged ports the service must be started as root. Please specify {{ic|User tor}} option in {{ic|/etc/tor/torrc}}.<br />
<br />
{{hc|/etc/systemd/system/tor.service.d/start-as-root.conf|<nowiki><br />
[Service]<br />
User=root<br />
</nowiki>}}<br />
<br />
====== Tor configuration ======<br />
To listen on Port 80 and 443 the service need to be started as {{ic|root}} as described in [[#Start tor.service as root to bind Tor to privileged ports]].<br />
Use the {{ic|User tor}} option in {{ic|/etc/tor/torrc}} to properly reduce Tor’s privileges.<br />
<br />
{{hc|/etc/tor/torrc|<nowiki><br />
SocksPort 0 ## Pure relay configuration without local socks proxy<br />
<br />
Log notice stdout ## Default Tor behavior<br />
<br />
ControlPort 9051 ## For arm connection<br />
CookieAuthentication 1 ## For arm connection<br />
<br />
ORPort 443 ## Service must be started as root<br />
<br />
Address $IP ## IP or FQDN<br />
Nickname $NICKNAME ## Nickname displayed in </nowiki>[https://onionoo.torproject.org/ Onionoo]<nowiki><br />
<br />
RelayBandwidthRate 500 Mbits ## bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits<br />
RelayBandwidthBurst 1000 MBits ## bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits<br />
<br />
ContactInfo $E-MAIL - $BTC-ADDRESS ## See </nowiki>[https://oniontip.com/ OnionTip]<nowiki><br />
<br />
DirPort 80 ## Service must be started as root<br />
DirPortFrontPage /etc/tor/tor-exit-notice.html ## Original: </nowiki>[https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html]<nowiki><br />
<br />
MyFamily $($KEYID),$($KEYID)... ## Remember $ in front of keyid(s) ;)<br />
<br />
ExitPolicy reject XXX.XXX.XXX.XXX/XX:* ## Block domain of public IP in addition to std. exit policy<br />
<br />
User tor ## Return to tor user after service started as root to listen on privileged ports<br />
<br />
DisableDebuggerAttachment 0 ## For arm connection<br />
<br />
### Performance related options ###<br />
AvoidDiskWrites 1 ## Reduce wear on SSD<br />
DisableAllSwap 1 ## Service must be started as root<br />
HardwareAccel 1 ## Look for OpenSSL hardware cryptographic support<br />
NumCPUs 2 ## Only start two threads<br />
</nowiki>}}<br />
<br />
This configuration is based on the [https://www.torproject.org/docs/tor-manual.html.en Tor Manual]. <br />
<br />
Tor opens a socks proxy on port 9050 by default -- even if you do not configure one. Set {{ic|SocksPort 0}} if you plan to run Tor only as a relay, and not make any local application connections yourself.<br />
<br />
{{ic|Log notice stdout}} changes logging to stdout, which is also the Tor default.<br />
{{ic|ControlPort 9051}}, {{ic|CookieAuthentication 1}} and {{ic|DisableDebuggerAttachment 0}} enables {{Pkg|arm}} to connect to Tor and display connections.<br />
<br />
{{ic|ORPort 443}} and {{ic|DirPort 80}} lets Tor listen on port 443 and 80 and {{ic|DirPortFrontPage}} displays the [https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html tor-exit-notice.html] on port 80.<br />
<br />
{{ic|ExitPolicy reject XXX.XXX.XXX.XXX/XX:*}} should reflect your public IP and netmask, which can be obtained with the command {{ic|# ip addr}}, so exit connections cannot connect to the host or neighboring machines public IP and circumvent firewalls.<br />
<br />
{{ic|AvoidDiskWrites 1}} reduces disk writes and wear on SSD.<br />
{{ic|DisableAllSwap 1}} "will attempt to lock all current and future memory pages, so that memory cannot be paged out". <br />
<br />
If {{ic|<nowiki># cat /proc/cpuinfo | grep aes</nowiki>}} returns that your CPU supports AES instructions and {{ic|<nowiki># lsmod | grep aes</nowiki>}} returns that the module is loaded, you can specify {{ic|HardwareAccel 1}} which tries "to use built-in (static) crypto hardware acceleration when available", see [http://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration http://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration].<br />
<br />
{{ic|ORPort 443}}, {{ic|DirPort 80}} and {{ic|DisableAllSwap 1}} require that you start the Tor service as {{ic|root}} as described in [[#Start tor.service as root to bind Tor to privileged ports]].<br />
Use the {{ic|User tor}} option to properly reduce Tor’s privileges.<br />
<br />
===== arm =====<br />
If {{ic|ControlPort 9051}} and {{ic|CookieAuthentication 1}} is specified in {{ic|/etc/tor/torrc}}, {{Pkg|arm}} can be started with {{ic|sudo -u tor arm}}.<br />
If you want to watch Tor connections in {{Pkg|arm}} {{ic|DisableDebuggerAttachment 0}} must also be specified.<br />
<br />
===== iptables =====<br />
Setup and learn to use [[iptables]]. Instead of being a [[Simple stateful firewall]] where connection tracking would have to track thousands of connections on a tor exit relay this firewall configuration is stateless.<br />
<br />
{{hc|/etc/iptables/iptables.rules|<nowiki><br />
*raw<br />
-A PREROUTING -j NOTRACK<br />
-A OUTPUT -j NOTRACK<br />
COMMIT<br />
<br />
*filter<br />
:INPUT DROP [0:0]<br />
:FORWARD DROP [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
-A INPUT -p tcp ! --syn -j ACCEPT<br />
-A INPUT -p udp -j ACCEPT<br />
-A INPUT -p icmp -j ACCEPT<br />
-A INPUT -p tcp --dport 443 -j ACCEPT<br />
-A INPUT -p tcp --dport 80 -j ACCEPT<br />
-A INPUT -i lo -j ACCEPT<br />
COMMIT<br />
</nowiki>}}<br />
<br />
{{ic|-A PREROUTING -j NOTRACK}} and {{ic|-A OUTPUT -j NOTRACK}} disables connection tracking in the {{ic|raw}} table.<br />
<br />
{{ic|:INPUT DROP [0:0]}} is the default {{ic|INPUT}} target and drops input traffic we do not specifically {{ic|ACCEPT}}.<br />
<br />
{{ic|:FORWARD DROP [0:0]}} is the default {{ic|FORWARD}} target and only relevant if the host is a normal router, not when the host is an onion router.<br />
<br />
{{ic|:OUTPUT ACCEPT [0:0]}} is the default {{ic|OUTPUT}} target and allows all outgoing connections.<br />
<br />
{{ic|-A INPUT -p tcp ! --syn -j ACCEPT}} allow already established incoming TCP connections per the rules below and TCP connections established from the exit node.<br />
<br />
{{ic|-A INPUT -p udp -j ACCEPT}} allow all incoming UDP connections because we do not use connection tracking.<br />
<br />
{{ic|-A INPUT -p icmp -j ACCEPT}} allow [[wikipedia:Internet_Control_Message_Protocol|ICMP]].<br />
<br />
{{ic|-A INPUT -p tcp --dport 443 -j ACCEPT}} allow incoming connections to the {{ic|ORPort}}.<br />
<br />
{{ic|-A INPUT -p tcp --dport 80 -j ACCEPT}} allow incoming connections to the {{ic|DirPort}}.<br />
<br />
{{ic|-A INPUT -i lo -j ACCEPT}} allows all connections on the loopback interface.<br />
<br />
===== Haveged =====<br />
See [[Haveged]] to decide if your system generates enough entropy to handle a lot of OpenSSL connections, see [http://www.issihosts.com/haveged/ haveged - A simple entropy daemon] and [http://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged how-to-setup-additional-entropy-for-cloud-servers-using-haveged] for documentation.<br />
<br />
===== pdnsd =====<br />
<br />
{{Warning|This configuration assumes your network DNS resolver is trusted (uncensored).}}<br />
<br />
You can use [[pdnsd]] to cache DNS queries locally, so the exit relay can resolve DNS faster and the exit relay does not forward all DNS queries to an external DNS recursor.<br />
<br />
{{hc|/etc/pdnsd.conf|<nowiki><br />
...<br />
perm_cache=102400 ## (Default value)*100 = 1MB * 100 = 100MB<br />
...<br />
server {<br />
label= "resolvconf";<br />
file = "/etc/pdnsd-resolv.conf"; ## Preferably do not use /etc/resolv.conf<br />
timeout=4; ## Server timeout, this may be much shorter than the global timeout option.<br />
uptest=query; ## Test availability using empty DNS queries. <br />
query_test_name="."; ## To be used if remote servers ignore empty queries.<br />
interval=10m; ## Test every 10 minutes.<br />
purge_cache=off; ## Ignore TTL.<br />
edns_query=yes; ## Use EDNS for outgoing queries to allow UDP messages larger than 512 bytes. May cause trouble with some legacy systems.<br />
preset=off; ## Assume server is down before uptest.<br />
}<br />
...<br />
</nowiki>}}<br />
<br />
This configuration stub shows how to cache queries to your normal DNS recursor locally and increase pdnsd cache size to 100MB.<br />
<br />
====== Uncensored DNS ======<br />
<br />
If your local DNS recursor is in some way censored or interferes with DNS queries, see [[Resolv.conf#Alternative DNS servers]] for alternatives and add them in a seperate server-section in {{ic|/etc/pdnsd.conf}} as per [[Pdnsd#DNS servers]].<br />
<br />
== TorDNS ==<br />
<br />
The Tor 0.2.x series provides a built-in DNS forwarder. To enable it add the following lines to the Tor configuration file and restart the daemon:<br />
<br />
{{hc|/etc/tor/torrc|<br />
DNSPort 9053<br />
AutomapHostsOnResolve 1<br />
AutomapHostsSuffixes .exit,.onion<br />
}}<br />
<br />
This will allow Tor to accept DNS requests (listening on port 9053 in this example) like a regular DNS server, and resolve the domain via the Tor network. A downside is that it is only able to resolve DNS queries for A-records; MX and NS queries are never answered. For more information see this [https://techstdout.boum.org/TorDns/ Debian-based introduction].<br />
<br />
DNS queries can also be performed through a command line interface by using {{Ic|<nowiki>tor-resolve</nowiki>}}. For example:<br />
<br />
{{bc|<br />
$ tor-resolve archlinux.org<br />
66.211.214.131<br />
}}<br />
<br />
=== Using TorDNS for all DNS queries ===<br />
<br />
It is possible to configure your system, if so desired, to use TorDNS for ''all'' queries your system makes, regardless of whether or not you eventually use Tor to connect to your final destination. To do this, configure your system to use 127.0.0.1 as its DNS server and edit the 'DNSPort' line in {{ic|/etc/tor/torrc}} to show:<br />
<br />
DNSPort 53<br />
<br />
Alternatively, you can use a local caching DNS server, such as [[dnsmasq]] or [[pdnsd]], which will also compensate for TorDNS being a little slower than traditional DNS servers. The following instructions will show how to set up ''dnsmasq'' for this purpose.<br />
<br />
Change the tor setting to listen for the DNS request in port 9053 and install {{Pkg|dnsmasq}}.<br />
<br />
Modify its configuration file so that it contains:<br />
<br />
{{hc|/etc/dnsmasq.conf|<br />
no-resolv<br />
port&#61;53<br />
server&#61;127.0.0.1#9053<br />
listen-address&#61;127.0.0.1<br />
}}<br />
<br />
These configurations set dnsmasq to listen only for requests from the local computer, and to use TorDNS at its sole upstream provider. It is now neccessary to edit {{ic|/etc/resolv.conf}} so that your system will query only the dnsmasq server.<br />
<br />
{{hc|/etc/resolv.conf|<br />
nameserver 127.0.0.1<br />
}}<br />
<br />
Start the '''dnsmasq''' daemon.<br />
<br />
Finally if you use ''dhcpd'' you would need to change its settings to that it does not alter the resolv configuration file. Just add this line in the configuration file:<br />
<br />
{{hc|/etc/dhcpcd.conf|<br />
nohook resolv.conf<br />
}}<br />
<br />
If you already have an ''nohook'' line, just add '''resolv.conf''' separated with a comma.<br />
<br />
== Torsocks ==<br />
<br />
'''torsocks''' will allow you use an application via the Tor network without the need to make configuration changes to the application involved. From the man page:<br />
<br />
''torsocks is a wrapper between the torsocks library and the application in order to make every Internet communication go through the Tor network.''<br />
<br />
Usage example:<br />
<br />
$ torsocks elinks checkip.dyndns.org<br />
<nowiki>$ torsocks wget -qO- https://check.torproject.org/ | grep -i congratulations</nowiki><br />
<br />
== Transparent Torification ==<br />
<br />
In some cases it is more secure and often easier to transparently torify an entire system instead of configuring individual applications to use Tor's socks port, not to mention preventing DNS leaks. Transparent torification can be done with [[iptables]] in such a way that all outbound packets are redirected through Tor's ''TransPort'', except the Tor traffic itself. Once in place, applications do not need to be configured to use Tor, though Tor's ''SocksPort'' will still work. This also works for DNS via Tor's ''DNSPort'', but realize that Tor only supports TCP, thus UDP packets other than DNS cannot be sent through Tor and therefore must be blocked entirely to prevent leaks. Using iptables to transparently torify a system affords comparatively strong leak protection, but it is not a substitute for virtualized torification applications such as Whonix, or TorVM [https://www.whonix.org/wiki/Comparison_with_Others]. Transparent torification also will not protect against fingerprinting attacks on its own, so it is recommended to use it in conjunction with the Tor Browser (search the AUR for the version you want: https://aur.archlinux.org/packages/?K=tor-browser) or to use an amnesic solution like [http://tails.boum.org/ Tails] instead. Applications can still learn your computer's hostname, MAC address, serial number, timezone, etc. and those with root privileges can disable the firewall entirely. In other words, transparent torification with iptables protects against accidental connections and DNS leaks by misconfigured software, it is not sufficient to protect against malware or software with serious security vulnerabilities.<br />
<br />
To enable transparent torification, use the following file for {{ic|iptables-restore}} and {{ic|ip6tables-restore}} (internally used by [[systemd]]'s {{ic|iptables.service}} and {{ic|ip6tables.service}}).<br />
<br />
{{Note|<br />
This file uses the nat table to force outgoing connections through the TransPort or DNSPort, and blocks anything it cannot torrify.<br />
<br />
* Now using {{ic|--ipv6}} and {{ic|--ipv4}} for protocol specific changes. {{ic|iptables-restore}} and {{ic|ip6tables-restore}} can now use the same file.<br />
* Where --ipv6 or --ipv4 is explicitly defined, {{ic|ip*tables-restore}} will ignore the rule if it is not for the correct protocol.<br />
* {{ic|ip6tables}} does not support {{ic|--reject-with}}. Make sure your torrc contains the following lines:<br />
<br />
SocksPort 9050<br />
DNSPort 5353<br />
TransPort 9040<br />
<br />
See {{man|8|iptables}}.<br />
}}<br />
<br />
{{Note|<br />
<br />
If you get this error: {{ic|iptables-restore: unable to initialize table 'nat'}}, you have to load the appropriate kernel modules:<br />
<br />
# modprobe ip_tables iptable_nat ip_conntrack iptable-filter ipt_state<br />
<br />
}}<br />
<br />
{{hc|/etc/iptables/iptables.rules|<br />
<br />
*nat<br />
:PREROUTING ACCEPT [6:2126]<br />
:INPUT ACCEPT [0:0]<br />
:OUTPUT ACCEPT [17:6239]<br />
:POSTROUTING ACCEPT [6:408]<br />
<br />
-A PREROUTING ! -i lo -p udp -m udp --dport 53 -j REDIRECT --to-ports 5353<br />
-A PREROUTING ! -i lo -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040<br />
-A OUTPUT -o lo -j RETURN<br />
--ipv4 -A OUTPUT -d 192.168.0.0/16 -j RETURN<br />
-A OUTPUT -m owner --uid-owner "tor" -j RETURN<br />
-A OUTPUT -p udp -m udp --dport 53 -j REDIRECT --to-ports 5353<br />
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040<br />
COMMIT<br />
<br />
*filter<br />
:INPUT DROP [0:0]<br />
:FORWARD DROP [0:0]<br />
:OUTPUT DROP [0:0]<br />
<br />
-A INPUT -i lo -j ACCEPT<br />
-A INPUT -p icmp -j ACCEPT<br />
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT<br />
--ipv4 -A INPUT -p tcp -j REJECT --reject-with tcp-reset<br />
--ipv4 -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable<br />
--ipv4 -A INPUT -j REJECT --reject-with icmp-proto-unreachable<br />
--ipv6 -A INPUT -j REJECT<br />
--ipv4 -A OUTPUT -d 127.0.0.0/8 -j ACCEPT<br />
--ipv4 -A OUTPUT -d 192.168.0.0/16 -j ACCEPT<br />
--ipv6 -A OUTPUT -d ::1/8 -j ACCEPT<br />
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT<br />
-A OUTPUT -m owner --uid-owner "tor" -j ACCEPT<br />
--ipv4 -A OUTPUT -j REJECT --reject-with icmp-port-unreachable<br />
--ipv6 -A OUTPUT -j REJECT<br />
COMMIT<br />
}}<br />
<br />
This file also works for ip6tables-restore, so you may symlink it:<br />
<br />
# ln -s /etc/iptables/iptables.rules /etc/iptables/ip6tables.rules<br />
<br />
Then make sure Tor is running, and [[start/enable]] the {{ic|iptables}} and {{ic|ip6tables}} systemd units.<br />
<br />
You may want to add {{ic|1=Requires=iptables.service}} and {{ic|1=Requires=ip6tables.service}} to whatever systemd unit logs your user in (most likely a [[display manager]]), to prevent any user processes from being started before the firewall up. See [[systemd]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Problem with user value ===<br />
<br />
If the '''tor''' daemon failed to start, then run the following command as root (or use sudo)<br />
<br />
# tor<br />
<br />
If you get the following error<br />
<br />
May 23 00:27:24.624 [warn] Error setting groups to gid 43: "Operation not permitted".<br />
May 23 00:27:24.624 [warn] If you set the "User" option, you must start Tor as root.<br />
May 23 00:27:24.624 [warn] Failed to parse/validate config: Problem with User value. See logs for details.<br />
May 23 00:27:24.624 [err] Reading config failed--see warnings above.<br />
<br />
Then it means that the problem is with the User value, which likely means that one or more files or directories in your {{ic|/var/lib/tor}} directory is not owned by tor. This can be determined by using the following find command:<br />
<br />
find /var/lib/tor/ ! -user tor<br />
<br />
Any files or directories listed in the output from this command needs to have its ownership changed. This can be done individually for each file like so:<br />
<br />
chown tor:tor /var/lib/tor/filename<br />
<br />
Or to change everything listed by the above find example, modify the command to this:<br />
<br />
find /var/lib/tor/ ! -user tor -exec chown tor:tor {} \;<br />
<br />
Tor should now start up correctly.<br />
<br />
Still if you cannot start the tor service, run the service using root (this will switch back to the tor user). To do this, change the user name in the {{ic|/etc/tor/torrc}} file:<br />
<br />
User tor<br />
<br />
Now modify the systemd's tor service file {{ic|/usr/lib/systemd/system/tor.service}} as follows<br />
<br />
[Service]<br />
User=root<br />
Group=root<br />
Type=simple<br />
<br />
The process will be run as tor user. For this purpose change user and group ID to tor and also make it writable:<br />
<br />
# chown -R tor:tor /var/lib/tor/<br />
# chmod -R 755 /var/lib/tor<br />
<br />
Now save changes:<br />
<br />
# systemctl --system daemon-reload<br />
<br />
Then [[start]] {{ic|tor.service}}.<br />
<br />
== See also ==<br />
<br />
* [https://www.torproject.org/docs/tor-doc-unix.html.en Running the Tor client on Linux/BSD/Unix]<br />
* [https://trac.torproject.org/projects/tor/wiki#Unixish Unix-based Tor Articles]<br />
* [https://trac.torproject.org/projects/tor/wiki/doc/SupportPrograms Software commonly integrated with Tor]<br />
* [https://www.torproject.org/docs/tor-hidden-service.html.en How to set up a Tor ''Hidden Service'']<br />
* [https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports List of tor pluggable transports for obfuscating tor's traffic]</div>Kay94https://wiki.archlinux.org/index.php?title=Proxy_server&diff=485386Proxy server2017-08-14T20:08:14Z<p>Kay94: /* Environment variables */ Removed own typo.</p>
<hr />
<div>[[Category:Proxy servers]]<br />
[[Category:Network configuration]]<br />
[[es:Proxy settings]]<br />
[[ja:プロキシ設定]]<br />
{{Related articles start}}<br />
{{Related|HTTP tunneling}}<br />
{{Related articles end}}<br />
A proxy is "an interface for a service, especially for one that is remote, resource-intensive, or otherwise difficult to use directly". Source: [http://en.wiktionary.org/wiki/proxy Proxy - Wiktionary].<br />
<br />
==Environment variables==<br />
Some programs, such as [[wget]] and (used by [[pacman]]) ''curl'', use environment variables of the form "protocol_proxy" to determine the proxy for a given protocol (e.g. HTTP, FTP, ...).<br />
<br />
Below is an example on how to set these variables in a shell:<br />
<br />
<nowiki><br />
export http_proxy=http://10.203.0.1:5187/<br />
export https_proxy=$http_proxy<br />
export ftp_proxy=$http_proxy<br />
export rsync_proxy=$http_proxy<br />
export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"</nowiki><br />
Some programs look for the all caps version of the environment variables.<br />
<br />
If the proxy environment variables are to be made available to all users and all applications, the above mentioned export commands may be added to a script, say "proxy.sh" inside /etc/profile.d/. The script has to be then made executable. This method is helpful while using a Desktop Environment like [[Xfce]] which does not provide an option for proxy configuration. For example, [[Chromium]] browser will make use of the variables set using this method while running XFCE. <br />
<br />
Alternatively, there's a tool named [https://github.com/himanshub16/ProxyMan ProxyMan] which claims to configure system-wide proxy settings easily. It also handles proxy configurations of other software like [git], [npm], Dropbox, etc. The project is inspired from Alan Pope's idea of making a script.<br />
<br />
Alternatively you can automate the toggling of the variables by adding a function to your .bashrc (thanks to Alan Pope for original script idea)<br />
<nowiki><br />
function proxy_on() {<br />
export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"<br />
<br />
if (( $# > 0 )); then<br />
valid=$(echo $@ | sed -n 's/\([0-9]\{1,3\}.\)\{4\}:\([0-9]\+\)/&/p')<br />
if [[ $valid != $@ ]]; then<br />
>&2 echo "Invalid address"<br />
return 1<br />
fi<br />
<br />
export http_proxy="http://$1/" \<br />
https_proxy=$http_proxy \<br />
ftp_proxy=$http_proxy \<br />
rsync_proxy=$http_proxy<br />
echo "Proxy environment variable set."<br />
return 0<br />
fi<br />
<br />
echo -n "username: "; read username<br />
if [[ $username != "" ]]; then<br />
echo -n "password: "<br />
read -es password<br />
local pre="$username:$password@"<br />
fi<br />
<br />
echo -n "server: "; read server<br />
echo -n "port: "; read port<br />
export http_proxy="http://$pre$server:$port/" \<br />
https_proxy=$http_proxy \<br />
ftp_proxy=$http_proxy \<br />
rsync_proxy=$http_proxy \<br />
HTTP_PROXY=$http_proxy \<br />
HTTPS_PROXY=$http_proxy \<br />
FTP_PROXY=$http_proxy \ <br />
RSYNC_PROXY=$http_proxy<br />
}<br />
<br />
function proxy_off(){<br />
unset http_proxy https_proxy ftp_proxy rsync_proxy \<br />
HTTP_PROXY HTTPS_PROXY FTP_PROXY RSYNC_PROXY<br />
echo -e "Proxy environment variable removed."<br />
}<br />
</nowiki><br />
<br />
Omit username or password if they are not needed.<br />
<br />
As an alternative, you may want to use the following script.<br />
Change the strings "YourUserName", "ProxyServerAddress:Port", "LocalAddress" and "LocalDomain" to match your own data,<br />
then edit your {{ic|~/.bashrc}} to include the edited functions.<br />
Any new bash window will have the new functions. In existing bash windows, type {{ic|source ~/.bashrc}}.<br />
You may prefer to put function definitions in a separate file like {{ic|functions}} then add {{ic|source functions}} to {{ic|.bashrc}} instead of putting everything in {{ic|.bashrc}}.<br />
You may also want to change the name "myProxy" into something short and easy to write.<br />
<br />
<nowiki><br />
#!/bin/bash<br />
<br />
assignProxy(){<br />
PROXY_ENV="http_proxy ftp_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY FTP_PROXY ALL_PROXY"<br />
for envar in $PROXY_ENV<br />
do<br />
export $envar=$1<br />
done<br />
for envar in "no_proxy NO_PROXY"<br />
do<br />
export $envar=$2<br />
done<br />
}<br />
<br />
clrProxy(){<br />
PROXY_ENV="http_proxy ftp_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY FTP_PROXY ALL_PROXY"<br />
for envar in $PROXY_ENV<br />
do<br />
unset $envar<br />
done<br />
}<br />
<br />
myProxy(){<br />
user=YourUserName<br />
read -p "Password: " -s pass && echo -e " "<br />
proxy_value="http://$user:$pass@ProxyServerAddress:Port"<br />
no_proxy_value="localhost,127.0.0.1,LocalAddress,LocalDomain.com"<br />
assignProxy $proxy_value $no_proxy_value<br />
}<br />
</nowiki><br />
<br />
===Keep proxy through sudo===<br />
<br />
If the proxy environment variables are set for the user only (say, from manual commands or .bashrc) they will get lost when running commands with [[sudo]] (or when programs use sudo internally).<br />
<br />
A way to prevent that is to add the following line to the sudo configuration file (accessible with visudo) :<br />
<br />
<nowiki>Defaults env_keep += "http_proxy https_proxy ftp_proxy"</nowiki><br />
<br />
You may also add any other environment variable, like rsync_proxy, or no_proxy.<br />
<br />
===Automation with network managers===<br />
*[[NetworkManager]] cannot change the environment variables.<br />
*[[netctl]] could set-up these environment variables but they would not be seen by other applications as they are not child of netctl.<br />
<br />
==About libproxy==<br />
[http://code.google.com/p/libproxy/ libproxy] (which is available in the extra repository) is an abstraction library which should be used by all applications that want to access a network resource. It still is in development but could lead to a unified and automated handling of proxies in GNU/Linux if widely adopted.<br />
<br />
The role of libproxy is to read the proxy settings form different sources and make them available to applications which use the library. The interesting part with libproxy is that it offers an implementation of the [[wikipedia:Web_Proxy_Autodiscovery_Protocol|Web Proxy Autodiscovery Protocol]] and an implementation of [[wikipedia:Proxy_auto-config|Proxy Auto-Config]] that goes with it.<br />
<br />
The {{Ic|/usr/bin/proxy}} binary takes URL(s) as argument(s) and returns the proxy/proxies that could be used to fetch this/these network resource(s).<br />
{{Note|1=the version 0.4.11 does not support http_proxy='wpad:' because {{ic|1={ pkg-config 'mozjs185 >= 1.8.5'; } }} fails .}}<br />
<br />
As of 06/04/2009 libproxy is required by libsoup. It is then indirectly used by the {{Pkg|midori}} browser.<br />
<br />
== Web Proxy Options ==<br />
* [[Squid]] is a very popular caching/optimizing proxy<br />
* [[Privoxy]] is an anonymizing and ad-blocking proxy<br />
* For a simple proxy, ssh with port forwarding can be used<br />
<br />
=== Simple Proxy with SSH ===<br />
Connect to a server (HOST) on which you have an account (USER) as follows<br />
ssh -D PORT USER@HOST<br />
For PORT, choose some number which is not an IANA registered port. This specifies that traffic on the local PORT will be forwarded to the remote HOST. ssh will act as a [[Wikipedia:SOCKS|SOCKS]] server. Software supporting SOCKS proxy servers can simply be configured to connect to PORT on localhost.<br />
<br />
==Using a SOCKS proxy==<br />
There are two cases:<br />
*the application you want to use handles [[Wikipedia:SOCKS#SOCKS5|SOCKS5]] proxies (for example [[Firefox]]), then you just have to configure it to use the proxy.<br />
*the application you want to use does not handle SOCKS proxies, then you can try to use {{Pkg|tsocks}} or {{Pkg|proxychains-ng}}.<br />
<br />
In Firefox, you can use the SOCKS proxy in the menu Preferences > Network > Settings. Choose "Manual Proxy Configuration", and set the SOCKS Host (and only this one, make sure the other fields, such as HTTP Proxy or SSL Proxy are left empty). For example, if a SOCKS5 proxy is running on localhost port 8080, put "127.0.0.1" in the SOCKS Host field, "8080" in the Port field, and validate.<br />
<br />
If using ''proxychains-ng'', the configuration takes place in {{ic|/etc/proxychains.conf}}. You may have to uncomment the last line (set by default to use [[Tor]]), and replace it with the parameters of the SOCKS proxy. For example, if you are using the same SOCKS5 proxy as above, you will have to replace the last line by:<br />
socks5 127.0.0.1 8080<br />
<br />
Then, ''proxychains-ng'' can be launched with <br />
proxychains <program><br />
Where <program> can be any program already installed on your system (e.g. xterm, gnome-terminal, etc).<br />
<br />
If using ''tsocks'', the configuration takes place in {{ic|/etc/tsocks.conf}}. See {{ic|man 5 tsocks.conf}} for the options. An example minimum configuration looks like this:<br />
{{hc|/etc/tsocks.conf|2=<br />
server = 127.0.0.1<br />
server_port = 8080<br />
server_type = 5}}<br />
<br />
=== curl and pacman ===<br />
You may set the {{ic|all_proxy}} environment variable to let curl and pacman (which uses curl) use your socks5 proxy:<br />
{{bc|1=$ export all_proxy="socks5://your.proxy:1080"}}<br />
<br />
==Proxy settings on GNOME3==<br />
Some programs like [[Chromium]] prefer to use the settings stored by gnome. These settings can be modified through the gnome-control-center front end and also through gsettings.<br />
<br />
gsettings set org.gnome.system.proxy mode 'manual' <br />
gsettings set org.gnome.system.proxy.http host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.http port 8080<br />
gsettings set org.gnome.system.proxy.ftp host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.ftp port 8080<br />
gsettings set org.gnome.system.proxy.https host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.https port 8080<br />
gsettings set org.gnome.system.proxy ignore-hosts "['localhost', '127.0.0.0/8', '10.0.0.0/8', '192.168.0.0/16', '172.16.0.0/12' , '*.localdomain.com' ]"<br />
<br />
This configuration can also be set to automatically execute when [[NetworkManager#Proxy_settings|Network Manager]] connects to specific networks , by using the package {{AUR|proxydriver}} from the [[AUR]]<br />
<br />
== Microsoft NTLM proxy ==<br />
<br />
In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft security protocols which provides authentication, integrity, and confidentiality to users. <br />
<br />
{{AUR|cntlm}} from the [[AUR]] stands between your applications and the NTLM proxy, adding NTLM authentication on-the-fly. You can specify several "parent" proxies and Cntlm will try one after another until one works. All authenticated connections are cached and reused to achieve high efficiency.<br />
<br />
(NTLM PROXY IP:PORT + CREDENTIALS + OTHER INFO) -----> '''(127.0.0.1:PORT)'''<br />
<br />
=== Configuration ===<br />
<br />
Change settings in {{ic|/etc/cntlm.conf}} as needed, except for the password. Then run:<br />
<br />
$ cntlm -H<br />
<br />
This will generate encrypted password hashes according to your proxy hostname, username and password.<br />
<br />
{{Warning|{{Pkg|ettercap}} can easily sniff your password over LAN when using plain-text passwords instead of encrypted hashes.}}<br />
<br />
Edit {{ic|/etc/cntlm.conf}} again and include all three generated hashes, then [[enable]] {{ic|cntlm.service}}.<br />
<br />
To test settings, run:<br />
<br />
$ cntlm -v<br />
<br />
=== Usage ===<br />
<br />
Use {{ic|127.0.0.1:<port>}} or {{ic|localhost:<port>}} as a proxy adress. {{ic|<port>}} matches the {{ic|Listen}} parameter in {{ic|/etc/cntlm.conf}}, which by default is {{ic|3128}}.</div>Kay94https://wiki.archlinux.org/index.php?title=Proxy_server&diff=485385Proxy server2017-08-14T20:00:00Z<p>Kay94: /* Environment variables */ Removed the dupliacte calls to unset and export (both do take multiple arguments). Kept newlines in most cases.</p>
<hr />
<div>[[Category:Proxy servers]]<br />
[[Category:Network configuration]]<br />
[[es:Proxy settings]]<br />
[[ja:プロキシ設定]]<br />
{{Related articles start}}<br />
{{Related|HTTP tunneling}}<br />
{{Related articles end}}<br />
A proxy is "an interface for a service, especially for one that is remote, resource-intensive, or otherwise difficult to use directly". Source: [http://en.wiktionary.org/wiki/proxy Proxy - Wiktionary].<br />
<br />
==Environment variables==<br />
Some programs, such as [[wget]] and (used by [[pacman]]) ''curl'', use environment variables of the form "protocol_proxy" to determine the proxy for a given protocol (e.g. HTTP, FTP, ...).<br />
<br />
Below is an example on how to set these variables in a shell:<br />
<br />
<nowiki><br />
export http_proxy=http://10.203.0.1:5187/<br />
export https_proxy=$http_proxy<br />
export ftp_proxy=$http_proxy<br />
export rsync_proxy=$http_proxy<br />
export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"</nowiki><br />
Some programs look for the all caps version of the environment variables.<br />
<br />
If the proxy environment variables are to be made available to all users and all applications, the above mentioned export commands may be added to a script, say "proxy.sh" inside /etc/profile.d/. The script has to be then made executable. This method is helpful while using a Desktop Environment like [[Xfce]] which does not provide an option for proxy configuration. For example, [[Chromium]] browser will make use of the variables set using this method while running XFCE. <br />
<br />
Alternatively, there's a tool named [https://github.com/himanshub16/ProxyMan ProxyMan] which claims to configure system-wide proxy settings easily. It also handles proxy configurations of other software like [git], [npm], Dropbox, etc. The project is inspired from Alan Pope's idea of making a script.<br />
<br />
Alternatively you can automate the toggling of the variables by adding a function to your .bashrc (thanks to Alan Pope for original script idea)<br />
<nowiki><br />
function proxy_on() {<br />
export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"<br />
<br />
if (( $# > 0 )); then<br />
valid=$(echo $@ | sed -n 's/\([0-9]\{1,3\}.\)\{4\}:\([0-9]\+\)/&/p')<br />
if [[ $valid != $@ ]]; then<br />
>&2 echo "Invalid address"<br />
return 1<br />
fi<br />
<br />
export http_proxy="http://$1/" \<br />
https_proxy=$http_proxy \<br />
ftp_proxy=$http_proxy \<br />
rsync_proxy=$http_proxy \<br />
echo "Proxy environment variable set."<br />
return 0<br />
fi<br />
<br />
echo -n "username: "; read username<br />
if [[ $username != "" ]]; then<br />
echo -n "password: "<br />
read -es password<br />
local pre="$username:$password@"<br />
fi<br />
<br />
echo -n "server: "; read server<br />
echo -n "port: "; read port<br />
export http_proxy="http://$pre$server:$port/" \<br />
https_proxy=$http_proxy \<br />
ftp_proxy=$http_proxy \<br />
rsync_proxy=$http_proxy \<br />
HTTP_PROXY=$http_proxy \<br />
HTTPS_PROXY=$http_proxy \<br />
FTP_PROXY=$http_proxy \ <br />
RSYNC_PROXY=$http_proxy \<br />
}<br />
<br />
function proxy_off(){<br />
unset http_proxy https_proxy ftp_proxy rsync_proxy \<br />
HTTP_PROXY HTTPS_PROXY FTP_PROXY RSYNC_PROXY<br />
echo -e "Proxy environment variable removed."<br />
}<br />
</nowiki><br />
<br />
Omit username or password if they are not needed.<br />
<br />
As an alternative, you may want to use the following script.<br />
Change the strings "YourUserName", "ProxyServerAddress:Port", "LocalAddress" and "LocalDomain" to match your own data,<br />
then edit your {{ic|~/.bashrc}} to include the edited functions.<br />
Any new bash window will have the new functions. In existing bash windows, type {{ic|source ~/.bashrc}}.<br />
You may prefer to put function definitions in a separate file like {{ic|functions}} then add {{ic|source functions}} to {{ic|.bashrc}} instead of putting everything in {{ic|.bashrc}}.<br />
You may also want to change the name "myProxy" into something short and easy to write.<br />
<br />
<nowiki><br />
#!/bin/bash<br />
<br />
assignProxy(){<br />
PROXY_ENV="http_proxy ftp_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY FTP_PROXY ALL_PROXY"<br />
for envar in $PROXY_ENV<br />
do<br />
export $envar=$1<br />
done<br />
for envar in "no_proxy NO_PROXY"<br />
do<br />
export $envar=$2<br />
done<br />
}<br />
<br />
clrProxy(){<br />
PROXY_ENV="http_proxy ftp_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY FTP_PROXY ALL_PROXY"<br />
for envar in $PROXY_ENV<br />
do<br />
unset $envar<br />
done<br />
}<br />
<br />
myProxy(){<br />
user=YourUserName<br />
read -p "Password: " -s pass && echo -e " "<br />
proxy_value="http://$user:$pass@ProxyServerAddress:Port"<br />
no_proxy_value="localhost,127.0.0.1,LocalAddress,LocalDomain.com"<br />
assignProxy $proxy_value $no_proxy_value<br />
}<br />
</nowiki><br />
<br />
===Keep proxy through sudo===<br />
<br />
If the proxy environment variables are set for the user only (say, from manual commands or .bashrc) they will get lost when running commands with [[sudo]] (or when programs use sudo internally).<br />
<br />
A way to prevent that is to add the following line to the sudo configuration file (accessible with visudo) :<br />
<br />
<nowiki>Defaults env_keep += "http_proxy https_proxy ftp_proxy"</nowiki><br />
<br />
You may also add any other environment variable, like rsync_proxy, or no_proxy.<br />
<br />
===Automation with network managers===<br />
*[[NetworkManager]] cannot change the environment variables.<br />
*[[netctl]] could set-up these environment variables but they would not be seen by other applications as they are not child of netctl.<br />
<br />
==About libproxy==<br />
[http://code.google.com/p/libproxy/ libproxy] (which is available in the extra repository) is an abstraction library which should be used by all applications that want to access a network resource. It still is in development but could lead to a unified and automated handling of proxies in GNU/Linux if widely adopted.<br />
<br />
The role of libproxy is to read the proxy settings form different sources and make them available to applications which use the library. The interesting part with libproxy is that it offers an implementation of the [[wikipedia:Web_Proxy_Autodiscovery_Protocol|Web Proxy Autodiscovery Protocol]] and an implementation of [[wikipedia:Proxy_auto-config|Proxy Auto-Config]] that goes with it.<br />
<br />
The {{Ic|/usr/bin/proxy}} binary takes URL(s) as argument(s) and returns the proxy/proxies that could be used to fetch this/these network resource(s).<br />
{{Note|1=the version 0.4.11 does not support http_proxy='wpad:' because {{ic|1={ pkg-config 'mozjs185 >= 1.8.5'; } }} fails .}}<br />
<br />
As of 06/04/2009 libproxy is required by libsoup. It is then indirectly used by the {{Pkg|midori}} browser.<br />
<br />
== Web Proxy Options ==<br />
* [[Squid]] is a very popular caching/optimizing proxy<br />
* [[Privoxy]] is an anonymizing and ad-blocking proxy<br />
* For a simple proxy, ssh with port forwarding can be used<br />
<br />
=== Simple Proxy with SSH ===<br />
Connect to a server (HOST) on which you have an account (USER) as follows<br />
ssh -D PORT USER@HOST<br />
For PORT, choose some number which is not an IANA registered port. This specifies that traffic on the local PORT will be forwarded to the remote HOST. ssh will act as a [[Wikipedia:SOCKS|SOCKS]] server. Software supporting SOCKS proxy servers can simply be configured to connect to PORT on localhost.<br />
<br />
==Using a SOCKS proxy==<br />
There are two cases:<br />
*the application you want to use handles [[Wikipedia:SOCKS#SOCKS5|SOCKS5]] proxies (for example [[Firefox]]), then you just have to configure it to use the proxy.<br />
*the application you want to use does not handle SOCKS proxies, then you can try to use {{Pkg|tsocks}} or {{Pkg|proxychains-ng}}.<br />
<br />
In Firefox, you can use the SOCKS proxy in the menu Preferences > Network > Settings. Choose "Manual Proxy Configuration", and set the SOCKS Host (and only this one, make sure the other fields, such as HTTP Proxy or SSL Proxy are left empty). For example, if a SOCKS5 proxy is running on localhost port 8080, put "127.0.0.1" in the SOCKS Host field, "8080" in the Port field, and validate.<br />
<br />
If using ''proxychains-ng'', the configuration takes place in {{ic|/etc/proxychains.conf}}. You may have to uncomment the last line (set by default to use [[Tor]]), and replace it with the parameters of the SOCKS proxy. For example, if you are using the same SOCKS5 proxy as above, you will have to replace the last line by:<br />
socks5 127.0.0.1 8080<br />
<br />
Then, ''proxychains-ng'' can be launched with <br />
proxychains <program><br />
Where <program> can be any program already installed on your system (e.g. xterm, gnome-terminal, etc).<br />
<br />
If using ''tsocks'', the configuration takes place in {{ic|/etc/tsocks.conf}}. See {{ic|man 5 tsocks.conf}} for the options. An example minimum configuration looks like this:<br />
{{hc|/etc/tsocks.conf|2=<br />
server = 127.0.0.1<br />
server_port = 8080<br />
server_type = 5}}<br />
<br />
=== curl and pacman ===<br />
You may set the {{ic|all_proxy}} environment variable to let curl and pacman (which uses curl) use your socks5 proxy:<br />
{{bc|1=$ export all_proxy="socks5://your.proxy:1080"}}<br />
<br />
==Proxy settings on GNOME3==<br />
Some programs like [[Chromium]] prefer to use the settings stored by gnome. These settings can be modified through the gnome-control-center front end and also through gsettings.<br />
<br />
gsettings set org.gnome.system.proxy mode 'manual' <br />
gsettings set org.gnome.system.proxy.http host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.http port 8080<br />
gsettings set org.gnome.system.proxy.ftp host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.ftp port 8080<br />
gsettings set org.gnome.system.proxy.https host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.https port 8080<br />
gsettings set org.gnome.system.proxy ignore-hosts "['localhost', '127.0.0.0/8', '10.0.0.0/8', '192.168.0.0/16', '172.16.0.0/12' , '*.localdomain.com' ]"<br />
<br />
This configuration can also be set to automatically execute when [[NetworkManager#Proxy_settings|Network Manager]] connects to specific networks , by using the package {{AUR|proxydriver}} from the [[AUR]]<br />
<br />
== Microsoft NTLM proxy ==<br />
<br />
In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft security protocols which provides authentication, integrity, and confidentiality to users. <br />
<br />
{{AUR|cntlm}} from the [[AUR]] stands between your applications and the NTLM proxy, adding NTLM authentication on-the-fly. You can specify several "parent" proxies and Cntlm will try one after another until one works. All authenticated connections are cached and reused to achieve high efficiency.<br />
<br />
(NTLM PROXY IP:PORT + CREDENTIALS + OTHER INFO) -----> '''(127.0.0.1:PORT)'''<br />
<br />
=== Configuration ===<br />
<br />
Change settings in {{ic|/etc/cntlm.conf}} as needed, except for the password. Then run:<br />
<br />
$ cntlm -H<br />
<br />
This will generate encrypted password hashes according to your proxy hostname, username and password.<br />
<br />
{{Warning|{{Pkg|ettercap}} can easily sniff your password over LAN when using plain-text passwords instead of encrypted hashes.}}<br />
<br />
Edit {{ic|/etc/cntlm.conf}} again and include all three generated hashes, then [[enable]] {{ic|cntlm.service}}.<br />
<br />
To test settings, run:<br />
<br />
$ cntlm -v<br />
<br />
=== Usage ===<br />
<br />
Use {{ic|127.0.0.1:<port>}} or {{ic|localhost:<port>}} as a proxy adress. {{ic|<port>}} matches the {{ic|Listen}} parameter in {{ic|/etc/cntlm.conf}}, which by default is {{ic|3128}}.</div>Kay94https://wiki.archlinux.org/index.php?title=Proxy_server&diff=485384Proxy server2017-08-14T19:51:32Z<p>Kay94: /* Environment variables */ unset does more than just setting a variable to "", corrected this in clrProxy(). don't care the duplicate of PROXY_ENV, as its quite obvious.</p>
<hr />
<div>[[Category:Proxy servers]]<br />
[[Category:Network configuration]]<br />
[[es:Proxy settings]]<br />
[[ja:プロキシ設定]]<br />
{{Related articles start}}<br />
{{Related|HTTP tunneling}}<br />
{{Related articles end}}<br />
A proxy is "an interface for a service, especially for one that is remote, resource-intensive, or otherwise difficult to use directly". Source: [http://en.wiktionary.org/wiki/proxy Proxy - Wiktionary].<br />
<br />
==Environment variables==<br />
Some programs, such as [[wget]] and (used by [[pacman]]) ''curl'', use environment variables of the form "protocol_proxy" to determine the proxy for a given protocol (e.g. HTTP, FTP, ...).<br />
<br />
Below is an example on how to set these variables in a shell:<br />
<br />
<nowiki><br />
export http_proxy=http://10.203.0.1:5187/<br />
export https_proxy=$http_proxy<br />
export ftp_proxy=$http_proxy<br />
export rsync_proxy=$http_proxy<br />
export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"</nowiki><br />
Some programs look for the all caps version of the environment variables.<br />
<br />
If the proxy environment variables are to be made available to all users and all applications, the above mentioned export commands may be added to a script, say "proxy.sh" inside /etc/profile.d/. The script has to be then made executable. This method is helpful while using a Desktop Environment like [[Xfce]] which does not provide an option for proxy configuration. For example, [[Chromium]] browser will make use of the variables set using this method while running XFCE. <br />
<br />
Alternatively, there's a tool named [https://github.com/himanshub16/ProxyMan ProxyMan] which claims to configure system-wide proxy settings easily. It also handles proxy configurations of other software like [git], [npm], Dropbox, etc. The project is inspired from Alan Pope's idea of making a script.<br />
<br />
Alternatively you can automate the toggling of the variables by adding a function to your .bashrc (thanks to Alan Pope for original script idea)<br />
<nowiki><br />
function proxy_on() {<br />
export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"<br />
<br />
if (( $# > 0 )); then<br />
valid=$(echo $@ | sed -n 's/\([0-9]\{1,3\}.\)\{4\}:\([0-9]\+\)/&/p')<br />
if [[ $valid != $@ ]]; then<br />
>&2 echo "Invalid address"<br />
return 1<br />
fi<br />
<br />
export http_proxy="http://$1/"<br />
export https_proxy=$http_proxy<br />
export ftp_proxy=$http_proxy<br />
export rsync_proxy=$http_proxy<br />
echo "Proxy environment variable set."<br />
return 0<br />
fi<br />
<br />
echo -n "username: "; read username<br />
if [[ $username != "" ]]; then<br />
echo -n "password: "<br />
read -es password<br />
local pre="$username:$password@"<br />
fi<br />
<br />
echo -n "server: "; read server<br />
echo -n "port: "; read port<br />
export http_proxy="http://$pre$server:$port/"<br />
export https_proxy=$http_proxy<br />
export ftp_proxy=$http_proxy<br />
export rsync_proxy=$http_proxy<br />
export HTTP_PROXY=$http_proxy<br />
export HTTPS_PROXY=$http_proxy<br />
export FTP_PROXY=$http_proxy<br />
export RSYNC_PROXY=$http_proxy<br />
}<br />
<br />
function proxy_off(){<br />
unset http_proxy<br />
unset https_proxy<br />
unset ftp_proxy<br />
unset rsync_proxy<br />
unset HTTP_PROXY<br />
unset HTTPS_PROXY<br />
unset FTP_PROXY<br />
unset RSYNC_PROXY<br />
echo -e "Proxy environment variable removed."<br />
}<br />
</nowiki><br />
<br />
Omit username or password if they are not needed.<br />
<br />
As an alternative, you may want to use the following script.<br />
Change the strings "YourUserName", "ProxyServerAddress:Port", "LocalAddress" and "LocalDomain" to match your own data,<br />
then edit your {{ic|~/.bashrc}} to include the edited functions.<br />
Any new bash window will have the new functions. In existing bash windows, type {{ic|source ~/.bashrc}}.<br />
You may prefer to put function definitions in a separate file like {{ic|functions}} then add {{ic|source functions}} to {{ic|.bashrc}} instead of putting everything in {{ic|.bashrc}}.<br />
You may also want to change the name "myProxy" into something short and easy to write.<br />
<br />
<nowiki><br />
#!/bin/bash<br />
<br />
assignProxy(){<br />
PROXY_ENV="http_proxy ftp_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY FTP_PROXY ALL_PROXY"<br />
for envar in $PROXY_ENV<br />
do<br />
export $envar=$1<br />
done<br />
for envar in "no_proxy NO_PROXY"<br />
do<br />
export $envar=$2<br />
done<br />
}<br />
<br />
clrProxy(){<br />
PROXY_ENV="http_proxy ftp_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY FTP_PROXY ALL_PROXY"<br />
for envar in $PROXY_ENV<br />
do<br />
unset $envar<br />
done<br />
}<br />
<br />
myProxy(){<br />
user=YourUserName<br />
read -p "Password: " -s pass && echo -e " "<br />
proxy_value="http://$user:$pass@ProxyServerAddress:Port"<br />
no_proxy_value="localhost,127.0.0.1,LocalAddress,LocalDomain.com"<br />
assignProxy $proxy_value $no_proxy_value<br />
}<br />
</nowiki><br />
<br />
===Keep proxy through sudo===<br />
<br />
If the proxy environment variables are set for the user only (say, from manual commands or .bashrc) they will get lost when running commands with [[sudo]] (or when programs use sudo internally).<br />
<br />
A way to prevent that is to add the following line to the sudo configuration file (accessible with visudo) :<br />
<br />
<nowiki>Defaults env_keep += "http_proxy https_proxy ftp_proxy"</nowiki><br />
<br />
You may also add any other environment variable, like rsync_proxy, or no_proxy.<br />
<br />
===Automation with network managers===<br />
*[[NetworkManager]] cannot change the environment variables.<br />
*[[netctl]] could set-up these environment variables but they would not be seen by other applications as they are not child of netctl.<br />
<br />
==About libproxy==<br />
[http://code.google.com/p/libproxy/ libproxy] (which is available in the extra repository) is an abstraction library which should be used by all applications that want to access a network resource. It still is in development but could lead to a unified and automated handling of proxies in GNU/Linux if widely adopted.<br />
<br />
The role of libproxy is to read the proxy settings form different sources and make them available to applications which use the library. The interesting part with libproxy is that it offers an implementation of the [[wikipedia:Web_Proxy_Autodiscovery_Protocol|Web Proxy Autodiscovery Protocol]] and an implementation of [[wikipedia:Proxy_auto-config|Proxy Auto-Config]] that goes with it.<br />
<br />
The {{Ic|/usr/bin/proxy}} binary takes URL(s) as argument(s) and returns the proxy/proxies that could be used to fetch this/these network resource(s).<br />
{{Note|1=the version 0.4.11 does not support http_proxy='wpad:' because {{ic|1={ pkg-config 'mozjs185 >= 1.8.5'; } }} fails .}}<br />
<br />
As of 06/04/2009 libproxy is required by libsoup. It is then indirectly used by the {{Pkg|midori}} browser.<br />
<br />
== Web Proxy Options ==<br />
* [[Squid]] is a very popular caching/optimizing proxy<br />
* [[Privoxy]] is an anonymizing and ad-blocking proxy<br />
* For a simple proxy, ssh with port forwarding can be used<br />
<br />
=== Simple Proxy with SSH ===<br />
Connect to a server (HOST) on which you have an account (USER) as follows<br />
ssh -D PORT USER@HOST<br />
For PORT, choose some number which is not an IANA registered port. This specifies that traffic on the local PORT will be forwarded to the remote HOST. ssh will act as a [[Wikipedia:SOCKS|SOCKS]] server. Software supporting SOCKS proxy servers can simply be configured to connect to PORT on localhost.<br />
<br />
==Using a SOCKS proxy==<br />
There are two cases:<br />
*the application you want to use handles [[Wikipedia:SOCKS#SOCKS5|SOCKS5]] proxies (for example [[Firefox]]), then you just have to configure it to use the proxy.<br />
*the application you want to use does not handle SOCKS proxies, then you can try to use {{Pkg|tsocks}} or {{Pkg|proxychains-ng}}.<br />
<br />
In Firefox, you can use the SOCKS proxy in the menu Preferences > Network > Settings. Choose "Manual Proxy Configuration", and set the SOCKS Host (and only this one, make sure the other fields, such as HTTP Proxy or SSL Proxy are left empty). For example, if a SOCKS5 proxy is running on localhost port 8080, put "127.0.0.1" in the SOCKS Host field, "8080" in the Port field, and validate.<br />
<br />
If using ''proxychains-ng'', the configuration takes place in {{ic|/etc/proxychains.conf}}. You may have to uncomment the last line (set by default to use [[Tor]]), and replace it with the parameters of the SOCKS proxy. For example, if you are using the same SOCKS5 proxy as above, you will have to replace the last line by:<br />
socks5 127.0.0.1 8080<br />
<br />
Then, ''proxychains-ng'' can be launched with <br />
proxychains <program><br />
Where <program> can be any program already installed on your system (e.g. xterm, gnome-terminal, etc).<br />
<br />
If using ''tsocks'', the configuration takes place in {{ic|/etc/tsocks.conf}}. See {{ic|man 5 tsocks.conf}} for the options. An example minimum configuration looks like this:<br />
{{hc|/etc/tsocks.conf|2=<br />
server = 127.0.0.1<br />
server_port = 8080<br />
server_type = 5}}<br />
<br />
=== curl and pacman ===<br />
You may set the {{ic|all_proxy}} environment variable to let curl and pacman (which uses curl) use your socks5 proxy:<br />
{{bc|1=$ export all_proxy="socks5://your.proxy:1080"}}<br />
<br />
==Proxy settings on GNOME3==<br />
Some programs like [[Chromium]] prefer to use the settings stored by gnome. These settings can be modified through the gnome-control-center front end and also through gsettings.<br />
<br />
gsettings set org.gnome.system.proxy mode 'manual' <br />
gsettings set org.gnome.system.proxy.http host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.http port 8080<br />
gsettings set org.gnome.system.proxy.ftp host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.ftp port 8080<br />
gsettings set org.gnome.system.proxy.https host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.https port 8080<br />
gsettings set org.gnome.system.proxy ignore-hosts "['localhost', '127.0.0.0/8', '10.0.0.0/8', '192.168.0.0/16', '172.16.0.0/12' , '*.localdomain.com' ]"<br />
<br />
This configuration can also be set to automatically execute when [[NetworkManager#Proxy_settings|Network Manager]] connects to specific networks , by using the package {{AUR|proxydriver}} from the [[AUR]]<br />
<br />
== Microsoft NTLM proxy ==<br />
<br />
In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft security protocols which provides authentication, integrity, and confidentiality to users. <br />
<br />
{{AUR|cntlm}} from the [[AUR]] stands between your applications and the NTLM proxy, adding NTLM authentication on-the-fly. You can specify several "parent" proxies and Cntlm will try one after another until one works. All authenticated connections are cached and reused to achieve high efficiency.<br />
<br />
(NTLM PROXY IP:PORT + CREDENTIALS + OTHER INFO) -----> '''(127.0.0.1:PORT)'''<br />
<br />
=== Configuration ===<br />
<br />
Change settings in {{ic|/etc/cntlm.conf}} as needed, except for the password. Then run:<br />
<br />
$ cntlm -H<br />
<br />
This will generate encrypted password hashes according to your proxy hostname, username and password.<br />
<br />
{{Warning|{{Pkg|ettercap}} can easily sniff your password over LAN when using plain-text passwords instead of encrypted hashes.}}<br />
<br />
Edit {{ic|/etc/cntlm.conf}} again and include all three generated hashes, then [[enable]] {{ic|cntlm.service}}.<br />
<br />
To test settings, run:<br />
<br />
$ cntlm -v<br />
<br />
=== Usage ===<br />
<br />
Use {{ic|127.0.0.1:<port>}} or {{ic|localhost:<port>}} as a proxy adress. {{ic|<port>}} matches the {{ic|Listen}} parameter in {{ic|/etc/cntlm.conf}}, which by default is {{ic|3128}}.</div>Kay94https://wiki.archlinux.org/index.php?title=Proxy_server&diff=485383Proxy server2017-08-14T19:40:48Z<p>Kay94: /* Environment variables */ add missing unset-statements in function proxy_off()</p>
<hr />
<div>[[Category:Proxy servers]]<br />
[[Category:Network configuration]]<br />
[[es:Proxy settings]]<br />
[[ja:プロキシ設定]]<br />
{{Related articles start}}<br />
{{Related|HTTP tunneling}}<br />
{{Related articles end}}<br />
A proxy is "an interface for a service, especially for one that is remote, resource-intensive, or otherwise difficult to use directly". Source: [http://en.wiktionary.org/wiki/proxy Proxy - Wiktionary].<br />
<br />
==Environment variables==<br />
Some programs, such as [[wget]] and (used by [[pacman]]) ''curl'', use environment variables of the form "protocol_proxy" to determine the proxy for a given protocol (e.g. HTTP, FTP, ...).<br />
<br />
Below is an example on how to set these variables in a shell:<br />
<br />
<nowiki><br />
export http_proxy=http://10.203.0.1:5187/<br />
export https_proxy=$http_proxy<br />
export ftp_proxy=$http_proxy<br />
export rsync_proxy=$http_proxy<br />
export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"</nowiki><br />
Some programs look for the all caps version of the environment variables.<br />
<br />
If the proxy environment variables are to be made available to all users and all applications, the above mentioned export commands may be added to a script, say "proxy.sh" inside /etc/profile.d/. The script has to be then made executable. This method is helpful while using a Desktop Environment like [[Xfce]] which does not provide an option for proxy configuration. For example, [[Chromium]] browser will make use of the variables set using this method while running XFCE. <br />
<br />
Alternatively, there's a tool named [https://github.com/himanshub16/ProxyMan ProxyMan] which claims to configure system-wide proxy settings easily. It also handles proxy configurations of other software like [git], [npm], Dropbox, etc. The project is inspired from Alan Pope's idea of making a script.<br />
<br />
Alternatively you can automate the toggling of the variables by adding a function to your .bashrc (thanks to Alan Pope for original script idea)<br />
<nowiki><br />
function proxy_on() {<br />
export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"<br />
<br />
if (( $# > 0 )); then<br />
valid=$(echo $@ | sed -n 's/\([0-9]\{1,3\}.\)\{4\}:\([0-9]\+\)/&/p')<br />
if [[ $valid != $@ ]]; then<br />
>&2 echo "Invalid address"<br />
return 1<br />
fi<br />
<br />
export http_proxy="http://$1/"<br />
export https_proxy=$http_proxy<br />
export ftp_proxy=$http_proxy<br />
export rsync_proxy=$http_proxy<br />
echo "Proxy environment variable set."<br />
return 0<br />
fi<br />
<br />
echo -n "username: "; read username<br />
if [[ $username != "" ]]; then<br />
echo -n "password: "<br />
read -es password<br />
local pre="$username:$password@"<br />
fi<br />
<br />
echo -n "server: "; read server<br />
echo -n "port: "; read port<br />
export http_proxy="http://$pre$server:$port/"<br />
export https_proxy=$http_proxy<br />
export ftp_proxy=$http_proxy<br />
export rsync_proxy=$http_proxy<br />
export HTTP_PROXY=$http_proxy<br />
export HTTPS_PROXY=$http_proxy<br />
export FTP_PROXY=$http_proxy<br />
export RSYNC_PROXY=$http_proxy<br />
}<br />
<br />
function proxy_off(){<br />
unset http_proxy<br />
unset https_proxy<br />
unset ftp_proxy<br />
unset rsync_proxy<br />
unset HTTP_PROXY<br />
unset HTTPS_PROXY<br />
unset FTP_PROXY<br />
unset RSYNC_PROXY<br />
echo -e "Proxy environment variable removed."<br />
}<br />
</nowiki><br />
<br />
Omit username or password if they are not needed.<br />
<br />
As an alternative, you may want to use the following script.<br />
Change the strings "YourUserName", "ProxyServerAddress:Port", "LocalAddress" and "LocalDomain" to match your own data,<br />
then edit your {{ic|~/.bashrc}} to include the edited functions.<br />
Any new bash window will have the new functions. In existing bash windows, type {{ic|source ~/.bashrc}}.<br />
You may prefer to put function definitions in a separate file like {{ic|functions}} then add {{ic|source functions}} to {{ic|.bashrc}} instead of putting everything in {{ic|.bashrc}}.<br />
You may also want to change the name "myProxy" into something short and easy to write.<br />
<br />
<nowiki><br />
#!/bin/bash<br />
<br />
assignProxy(){<br />
PROXY_ENV="http_proxy ftp_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY FTP_PROXY ALL_PROXY"<br />
for envar in $PROXY_ENV<br />
do<br />
export $envar=$1<br />
done<br />
for envar in "no_proxy NO_PROXY"<br />
do<br />
export $envar=$2<br />
done<br />
}<br />
<br />
clrProxy(){<br />
assignProxy "" # This is what 'unset' does.<br />
}<br />
<br />
myProxy(){<br />
user=YourUserName<br />
read -p "Password: " -s pass && echo -e " "<br />
proxy_value="http://$user:$pass@ProxyServerAddress:Port"<br />
no_proxy_value="localhost,127.0.0.1,LocalAddress,LocalDomain.com"<br />
assignProxy $proxy_value $no_proxy_value<br />
}<br />
</nowiki><br />
<br />
===Keep proxy through sudo===<br />
<br />
If the proxy environment variables are set for the user only (say, from manual commands or .bashrc) they will get lost when running commands with [[sudo]] (or when programs use sudo internally).<br />
<br />
A way to prevent that is to add the following line to the sudo configuration file (accessible with visudo) :<br />
<br />
<nowiki>Defaults env_keep += "http_proxy https_proxy ftp_proxy"</nowiki><br />
<br />
You may also add any other environment variable, like rsync_proxy, or no_proxy.<br />
<br />
===Automation with network managers===<br />
*[[NetworkManager]] cannot change the environment variables.<br />
*[[netctl]] could set-up these environment variables but they would not be seen by other applications as they are not child of netctl.<br />
<br />
==About libproxy==<br />
[http://code.google.com/p/libproxy/ libproxy] (which is available in the extra repository) is an abstraction library which should be used by all applications that want to access a network resource. It still is in development but could lead to a unified and automated handling of proxies in GNU/Linux if widely adopted.<br />
<br />
The role of libproxy is to read the proxy settings form different sources and make them available to applications which use the library. The interesting part with libproxy is that it offers an implementation of the [[wikipedia:Web_Proxy_Autodiscovery_Protocol|Web Proxy Autodiscovery Protocol]] and an implementation of [[wikipedia:Proxy_auto-config|Proxy Auto-Config]] that goes with it.<br />
<br />
The {{Ic|/usr/bin/proxy}} binary takes URL(s) as argument(s) and returns the proxy/proxies that could be used to fetch this/these network resource(s).<br />
{{Note|1=the version 0.4.11 does not support http_proxy='wpad:' because {{ic|1={ pkg-config 'mozjs185 >= 1.8.5'; } }} fails .}}<br />
<br />
As of 06/04/2009 libproxy is required by libsoup. It is then indirectly used by the {{Pkg|midori}} browser.<br />
<br />
== Web Proxy Options ==<br />
* [[Squid]] is a very popular caching/optimizing proxy<br />
* [[Privoxy]] is an anonymizing and ad-blocking proxy<br />
* For a simple proxy, ssh with port forwarding can be used<br />
<br />
=== Simple Proxy with SSH ===<br />
Connect to a server (HOST) on which you have an account (USER) as follows<br />
ssh -D PORT USER@HOST<br />
For PORT, choose some number which is not an IANA registered port. This specifies that traffic on the local PORT will be forwarded to the remote HOST. ssh will act as a [[Wikipedia:SOCKS|SOCKS]] server. Software supporting SOCKS proxy servers can simply be configured to connect to PORT on localhost.<br />
<br />
==Using a SOCKS proxy==<br />
There are two cases:<br />
*the application you want to use handles [[Wikipedia:SOCKS#SOCKS5|SOCKS5]] proxies (for example [[Firefox]]), then you just have to configure it to use the proxy.<br />
*the application you want to use does not handle SOCKS proxies, then you can try to use {{Pkg|tsocks}} or {{Pkg|proxychains-ng}}.<br />
<br />
In Firefox, you can use the SOCKS proxy in the menu Preferences > Network > Settings. Choose "Manual Proxy Configuration", and set the SOCKS Host (and only this one, make sure the other fields, such as HTTP Proxy or SSL Proxy are left empty). For example, if a SOCKS5 proxy is running on localhost port 8080, put "127.0.0.1" in the SOCKS Host field, "8080" in the Port field, and validate.<br />
<br />
If using ''proxychains-ng'', the configuration takes place in {{ic|/etc/proxychains.conf}}. You may have to uncomment the last line (set by default to use [[Tor]]), and replace it with the parameters of the SOCKS proxy. For example, if you are using the same SOCKS5 proxy as above, you will have to replace the last line by:<br />
socks5 127.0.0.1 8080<br />
<br />
Then, ''proxychains-ng'' can be launched with <br />
proxychains <program><br />
Where <program> can be any program already installed on your system (e.g. xterm, gnome-terminal, etc).<br />
<br />
If using ''tsocks'', the configuration takes place in {{ic|/etc/tsocks.conf}}. See {{ic|man 5 tsocks.conf}} for the options. An example minimum configuration looks like this:<br />
{{hc|/etc/tsocks.conf|2=<br />
server = 127.0.0.1<br />
server_port = 8080<br />
server_type = 5}}<br />
<br />
=== curl and pacman ===<br />
You may set the {{ic|all_proxy}} environment variable to let curl and pacman (which uses curl) use your socks5 proxy:<br />
{{bc|1=$ export all_proxy="socks5://your.proxy:1080"}}<br />
<br />
==Proxy settings on GNOME3==<br />
Some programs like [[Chromium]] prefer to use the settings stored by gnome. These settings can be modified through the gnome-control-center front end and also through gsettings.<br />
<br />
gsettings set org.gnome.system.proxy mode 'manual' <br />
gsettings set org.gnome.system.proxy.http host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.http port 8080<br />
gsettings set org.gnome.system.proxy.ftp host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.ftp port 8080<br />
gsettings set org.gnome.system.proxy.https host 'proxy.localdomain.com'<br />
gsettings set org.gnome.system.proxy.https port 8080<br />
gsettings set org.gnome.system.proxy ignore-hosts "['localhost', '127.0.0.0/8', '10.0.0.0/8', '192.168.0.0/16', '172.16.0.0/12' , '*.localdomain.com' ]"<br />
<br />
This configuration can also be set to automatically execute when [[NetworkManager#Proxy_settings|Network Manager]] connects to specific networks , by using the package {{AUR|proxydriver}} from the [[AUR]]<br />
<br />
== Microsoft NTLM proxy ==<br />
<br />
In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft security protocols which provides authentication, integrity, and confidentiality to users. <br />
<br />
{{AUR|cntlm}} from the [[AUR]] stands between your applications and the NTLM proxy, adding NTLM authentication on-the-fly. You can specify several "parent" proxies and Cntlm will try one after another until one works. All authenticated connections are cached and reused to achieve high efficiency.<br />
<br />
(NTLM PROXY IP:PORT + CREDENTIALS + OTHER INFO) -----> '''(127.0.0.1:PORT)'''<br />
<br />
=== Configuration ===<br />
<br />
Change settings in {{ic|/etc/cntlm.conf}} as needed, except for the password. Then run:<br />
<br />
$ cntlm -H<br />
<br />
This will generate encrypted password hashes according to your proxy hostname, username and password.<br />
<br />
{{Warning|{{Pkg|ettercap}} can easily sniff your password over LAN when using plain-text passwords instead of encrypted hashes.}}<br />
<br />
Edit {{ic|/etc/cntlm.conf}} again and include all three generated hashes, then [[enable]] {{ic|cntlm.service}}.<br />
<br />
To test settings, run:<br />
<br />
$ cntlm -v<br />
<br />
=== Usage ===<br />
<br />
Use {{ic|127.0.0.1:<port>}} or {{ic|localhost:<port>}} as a proxy adress. {{ic|<port>}} matches the {{ic|Listen}} parameter in {{ic|/etc/cntlm.conf}}, which by default is {{ic|3128}}.</div>Kay94https://wiki.archlinux.org/index.php?title=File_systems&diff=484415File systems2017-08-07T19:22:00Z<p>Kay94: /* FUSE-based file systems */ added clarfication, that adbfs-git can't be used to mount an sd-card from an android device plugged into a card reader (adb is a connection between device and computer via usb).</p>
<hr />
<div>[[Category:File systems]]<br />
[[es:File systems]]<br />
[[hu:File systems]]<br />
[[it:File systems]]<br />
[[ja:ファイルシステム]]<br />
[[pl:File systems]]<br />
[[ru:File systems]]<br />
[[zh-hans:File systems]]<br />
{{Related articles start}}<br />
{{Related|Core utilities#lsblk}}<br />
{{Related|File permissions and attributes}}<br />
{{Related|fsck}}<br />
{{Related|fstab}}<br />
{{Related|List of applications/Internet#Distributed file systems}}<br />
{{Related|List of applications#Mount tools}}<br />
{{Related|Optical disc drive}}<br />
{{Related|Partitioning}}<br />
{{Related|NFS}}<br />
{{Related|NTFS-3G}}<br />
{{Related|FAT}}<br />
{{Related|QEMU#Mounting a partition inside a raw disk image}}<br />
{{Related|Samba}}<br />
{{Related|tmpfs}}<br />
{{Related|udev}}<br />
{{Related|udisks}}<br />
{{Related|umask}}<br />
{{Related|USB storage devices}}<br />
<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:File system|Wikipedia]]:<br />
:In computing, a file system (or filesystem) is used to control how data is stored and retrieved. Without a file system, information placed in a storage medium would be one large body of data with no way to tell where one piece of information stops and the next begins. By separating the data into pieces and giving each piece a name, the information is easily isolated and identified.<br />
:Taking its name from the way paper-based information systems are named, each group of data is called a "file". The structure and logic rules used to manage the groups of information and their names is called a "file system".<br />
<br />
Individual drive partitions can be setup using one of the many different available filesystems. Each has its own advantages, disadvantages, and unique idiosyncrasies. A brief overview of supported filesystems follows; the links are to Wikipedia pages that provide much more information.<br />
<br />
== Types of file systems ==<br />
<br />
See {{man|5|filesystems}} for a general overview, and [[Wikipedia:Comparison of file systems]] for a detailed feature comparison. File systems supported by the kernel are listed in {{ic|/proc/filesystems}}.<br />
<br />
{| class="wikitable sortable"<br />
! File system<br />
! Creation command<br />
! Userspace utilities<br />
! [[Archiso]] [https://git.archlinux.org/archiso.git/tree/configs/releng/packages.both]<br />
! Kernel documentation [https://www.kernel.org/doc/Documentation/filesystems/]<br />
! Notes<br />
|-<br />
| [[Btrfs]]<br />
| {{man|8|mkfs.btrfs}}<br />
| {{Pkg|btrfs-progs}}<br />
| {{Yes}}<br />
| [https://www.kernel.org/doc/Documentation/filesystems/btrfs.txt btrfs.txt]<br />
| [https://btrfs.wiki.kernel.org/index.php/Status Stability status]<br />
|-<br />
| [[VFAT]]<br />
| {{man|8|mkfs.vfat|url=https://linux.die.net/man/8/mkfs.vfat}}<br />
| {{Pkg|dosfstools}}<br />
| {{Yes}}<br />
| [https://www.kernel.org/doc/Documentation/filesystems/vfat.txt vfat.txt]<br />
|<br />
|-<br />
| [[w:exFAT|exFAT]]<br />
| {{man|8|mkfs.exfat|url=}}<br />
| {{Pkg|exfat-utils}}<br />
| {{Y|Optional}}<br />
| N/A (FUSE-based)<br />
|<br />
|-<br />
| [[F2FS]]<br />
| {{man|8|mkfs.f2fs|url=}}<br />
| {{Pkg|f2fs-tools}}<br />
| {{Yes}}<br />
| [https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt f2fs.txt]<br />
<br />
| Flash-based devices<br />
|-<br />
| [[ext3]]<br />
| {{man|8|mke2fs}}<br />
| {{Pkg|e2fsprogs}}<br />
| {{Yes}} ({{Grp|base}})<br />
| [https://www.kernel.org/doc/Documentation/filesystems/ext3.txt ext3.txt]<br />
|<br />
|-<br />
| [[ext4]]<br />
| {{man|8|mke2fs}}<br />
| {{Pkg|e2fsprogs}}<br />
| {{Yes}} ({{Grp|base}})<br />
| [https://www.kernel.org/doc/Documentation/filesystems/ext4.txt ext4.txt]<br />
|<br />
|-<br />
| [[w:Hierarchical_File_System|HFS]]<br />
| {{man|8|mkfs.hfsplus|url=}}<br />
| {{Pkg|hfsprogs}}<br />
| {{Y|Optional}}<br />
| [https://www.kernel.org/doc/Documentation/filesystems/hfs.txt hfs.txt]<br />
| [[w:macOS|macOS]] file system<br />
|-<br />
| [[JFS]]<br />
| {{man|8|mkfs.jfs|url=}}<br />
| {{Pkg|jfsutils}}<br />
| {{Yes}} ({{Grp|base}})<br />
| [https://www.kernel.org/doc/Documentation/filesystems/jfs.txt jfs.txt]<br />
|<br />
|-<br />
| [[Wikipedia:NILFS|NILFS2]]<br />
| {{man|8|mkfs.nilfs2|url=}}<br />
| {{Pkg|nilfs-utils}}<br />
| {{Yes}}<br />
| [https://www.kernel.org/doc/Documentation/filesystems/nilfs2.txt nilfs2.txt]<br />
|<br />
|-<br />
| [[NTFS]]<br />
| {{man|8|mkfs.ntfs|url=https://linux.die.net/man/8/mkfs.ntfs}}<br />
| {{Pkg|ntfs-3g}}<br />
| {{Yes}}<br />
| N/A (FUSE-based)<br />
| [[w:Microsoft_Windows|Windows]] file system<br />
|-<br />
| [[Reiser4]]<br />
| {{man|8|mkfs.reiser4|url=}}<br />
| {{AUR|reiser4progs}}<br />
| {{No}}<br />
|<br />
|<br />
|-<br />
| [[w:ReiserFS|ReiserFS]]<br />
| {{man|8|mkfs.reiserfs|url=}}<br />
| {{Pkg|reiserfsprogs}}<br />
| {{Yes}} ({{Grp|base}})<br />
|<br />
|<br />
|-<br />
| [[XFS]]<br />
| {{man|8|mkfs.xfs}}<br />
| {{Pkg|xfsprogs}}<br />
| {{Yes}} ({{Grp|base}})<br />
|<br />
[https://www.kernel.org/doc/Documentation/filesystems/xfs.txt xfs.txt]<br><br />
[https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt xfs-delayed-logging-design.txt]<br><br />
[https://www.kernel.org/doc/Documentation/filesystems/xfs-self-describing-metadata.txt xfs-self-describing-metadata.txt]<br />
|<br />
|-<br />
| [[ZFS]]<br />
| <br />
| {{AUR|zfs-linux}}<br />
| {{No}}<br />
| N/A ([[w:OpenZFS|OpenZFS]] port)<br />
|<br />
|}<br />
<br />
{{Note|The kernel has its own NTFS driver (see [https://www.kernel.org/doc/Documentation/filesystems/ntfs.txt ntfs.txt]), but it has limited support for writing files.}}<br />
<br />
=== Journaling ===<br />
<br />
All the above filesystems with the exception of ext2, FAT16/32, Btrfs and ZFS, use [[Wikipedia:Journaling_file_system|journaling]]. Journaling provides fault-resilience by logging changes before they are committed to the filesystem. In the event of a system crash or power failure, such file systems are faster to bring back online and less likely to become corrupted. The logging takes place in a dedicated area of the filesystem.<br />
<br />
Not all journaling techniques are the same. Ext3 and ext4 offer data-mode journaling, which logs both data and meta-data, as well as possibility to journal only meta-data changes. Data-mode journaling comes with a speed penalty and is not enabled by default. In the same vein, [[Reiser4]] offers so-called [https://reiser4.wiki.kernel.org/index.php/Reiser4_transaction_models "transaction models"], which include pure journaling (equivalent to ext4's data-mode journaling), pure Copy-on-Write approach (equivalent to btrfs' default) and a combined approach which heuristically alternates between the two former.<br />
<br />
{{Note|Reiser4 does not provide an equivalent to ext4's default journaling behavior (meta-data only).}}<br />
<br />
The other filesystems provide ordered-mode journaling, which only logs meta-data. While all journaling will return a filesystem to a valid state after a crash, data-mode journaling offers the greatest protection against corruption and data loss. There is a compromise in system performance, however, because data-mode journaling does two write operations: first to the journal and then to the disk. The trade-off between system speed and data safety should be considered when choosing the filesystem type.<br />
<br />
Filesystems based on copy-on-write, such as Btrfs and ZFS, have no need to use traditional journal to protect metadata, because they are never updated in-place. Although Btrfs still has a journal-like log tree, it is only used to speed-up fdatasync/fsync.<br />
<br />
=== FUSE-based file systems ===<br />
<br />
[[Wikipedia:Filesystem in Userspace|Filesystem in Userspace]] (FUSE) is a mechanism for Unix-like operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in ''user space'', while the FUSE kernel module provides only a "bridge" to the actual kernel interfaces.<br />
<br />
Some FUSE-based file systems:<br />
<br />
* {{App|adbfs-git|Mount an Android device filesystem (not suitable for a device's SD-card in a cardreader).|http://collectskin.com/adbfs/|{{AUR|adbfs-git}}}}<br />
* {{App|[[EncFS]]|EncFS is a userspace stackable cryptographic file-system.|https://vgough.github.io/encfs/|{{Pkg|encfs}}}}<br />
* {{App|fuseiso|Mount an ISO as a regular user.|http://sourceforge.net/projects/fuseiso/|{{Pkg|fuseiso}}}}<br />
* {{App|[[gitfs]]|gitfs is a FUSE file system that fully integrates with git.|https://www.presslabs.com/gitfs/|{{Aur|gitfs}}}}<br />
* {{App|xbfuse-git|Mount an Xbox (360) ISO.|http://multimedia.cx/xbfuse/|{{AUR|xbfuse-git}}}}<br />
* {{App|xmlfs|Represent an XML file as a directory structure for easy access.|https://github.com/halhen/xmlfs|{{AUR|xmlfs}}}}<br />
* {{App|vdfuse|Mounting VirtualBox disk images (VDI/VMDK/VHD).|https://github.com/muflone/virtualbox-includes|{{AUR|vdfuse}}}}<br />
<br />
See [[Wikipedia:Filesystem in Userspace#Example uses]] for more.<br />
<br />
=== Stackable file systems ===<br />
<br />
* {{App|aufs|Advanced Multi-layered Unification Filesystem, a FUSE based union filesystem, a complete rewrite of Unionfs, was rejected from Linux mainline and instead OverlayFS was merged into the Linux Kernel.|http://aufs.sourceforge.net|{{AUR|aufs}}}}<br />
<br />
* {{App|[[eCryptfs]]|The Enterprise Cryptographic Filesystem is a package of disk encryption software for Linux. It is implemented as a POSIX-compliant filesystem-level encryption layer, aiming to offer functionality similar to that of GnuPG at the operating system level.|http://ecryptfs.org|{{Pkg|ecryptfs-utils}}}}<br />
<br />
* {{App|mergerfs|a FUSE based union filesystem.|https://github.com/trapexit/mergerfs|{{AUR|mergerfs}}}}<br />
<br />
* {{App|mhddfs|Multi-HDD FUSE filesystem, a FUSE based union filesystem.|http://mhddfs.uvw.ru|{{AUR|mhddfs}}}}<br />
<br />
* {{App|[[overlayfs]]|OverlayFS is a filesystem service for Linux which implements a union mount for other file systems.|https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt|{{Pkg|linux}}}}<br />
<br />
* {{App|Unionfs|Unionfs is a filesystem service for Linux, FreeBSD and NetBSD which implements a union mount for other file systems.|http://unionfs.filesystems.org/}}<br />
<br />
* {{App|unionfs-fuse|A user space Unionfs implementation.|https://github.com/rpodgorny/unionfs-fuse|{{Pkg|unionfs-fuse}}}}<br />
<br />
=== Read-only file systems ===<br />
<br />
* {{App|[[Wikipedia: SquashFS|SquashFS]]|SquashFS is a compressed read only filesystem. SquashFS compresses files, inodes and directories, and supports block sizes up to 1 MB for greater compression.|http://squashfs.sourceforge.net/|{{Pkg|squashfs-tools}}}}<br />
<br />
=== Clustered file systems ===<br />
<br />
* {{App|[[Ceph]]|Unified, distributed storage system designed for excellent performance, reliability and scalability.|https://ceph.com/|{{pkg|ceph}}}}<br />
* {{App|[[Glusterfs]]|Cluster file system capable of scaling to several peta-bytes.|https://www.gluster.org/|{{Pkg|glusterfs}}}}<br />
* {{App|[[IPFS]]|A peer-to-peer hypermedia protocol to make the web faster, safer, and more open. IPFS aims replace HTTP and build a better web for all of us. Uses blocks to store parts of a file, each network node stores only content it is interested, provides deduplication, distribution, scalable system limited only by users. (currently in aplha)|https://ipfs.io/|{{Pkg|go-ipfs}}}}<br />
* {{App|[[Wikipedia: MooseFS|MooseFS]]|MooseFS is a fault tolerant, highly available and high performance scale-out network distributed file system.|https://www.gluster.org/|{{Pkg|moosefs}}}}<br />
* {{App|[[OpenAFS]]|Open source implementation of the AFS distributed file system|http://www.openafs.org|{{AUR|openafs}}}}<br />
* {{App|[[Wikipedia: OrangeFS|OrangeFS]]|OrangeFS is a scale-out network file system designed for transparently accessing multi-server-based disk storage, in parallel. Has optimized MPI-IO support for parallel and distributed applications. Simplifies the use of parallel storage not only for Linux clients, but also for Windows, Hadoop, and WebDAV. POSIX-compatible. Part of Linux kernel since version 4.6. |http://www.orangefs.org/}}<br />
* {{App|Sheepdog|Distributed object storage system for volume and container services and manages the disks and nodes intelligently.|https://sheepdog.github.io/sheepdog/}}<br />
* {{App|[[Wikipedia:Tahoe-LAFS|Tahoe-LAFS]]|Tahoe Least-Authority Filesystem is a free and open, secure, decentralized, fault-tolerant, peer-to-peer distributed data store and distributed file system.<br />
|https://tahoe-lafs.org/|{{AUR|tahoe-lafs}}}}<br />
<br />
== Identify existing file systems ==<br />
<br />
To identify existing file systems, you can use [[lsblk]]:<br />
<br />
{{hc|1=$ lsblk -f|2=<br />
NAME FSTYPE LABEL UUID MOUNTPOINT<br />
sdb <br />
└─sdb1 vfat Transcend 4A3C-A9E9 <br />
}}<br />
<br />
An existing file system, if present, will be shown in the {{ic|FSTYPE}} column. If [[mount]]ed, it will appear in the {{ic|MOUNTPOINT}} column.<br />
<br />
== Create a file system ==<br />
<br />
File systems are usually created on a [[partition]], inside logical containers such as [[LVM]], [[RAID]] and [[dm-crypt]], or on a regular file (see [[w:Loop device]]). This section describes the partition case.<br />
<br />
{{Note|1=File systems can be written directly to a disk, known as a [https://msdn.microsoft.com/en-us/library/windows/hardware/dn640535(v=vs.85).aspx#gpt_faq_superfloppy superfloppy] or ''partitionless disk''. Certain limitations are involved with this method, particularly if [[Arch boot process|booting]] from such a drive. See [[Btrfs#Partitionless Btrfs disk]] for an example.}}<br />
<br />
{{Warning|<br />
* After creating a new filesystem, data previously stored on this partition can unlikely be recovered. '''Create a backup of any data you want to keep'''.<br />
*The purpose of a given partition may restrict the choice of file system. For example, an [[EFI System Partition]] must contain a FAT32 ({{ic|mkfs.vfat}}) file system, and the file system containing the {{ic|/boot}} directory must be supported by the [[boot loader]].<br />
}}<br />
<br />
Before continuing, [[lsblk|identify the device]] where the file system will be created and whether or not it is mounted. For example:<br />
<br />
{{hc|$ lsblk -f|<br />
NAME FSTYPE LABEL UUID MOUNTPOINT<br />
sda<br />
├─sda1 C4DA-2C4D <br />
├─sda2 ext4 5b1564b2-2e2c-452c-bcfa-d1f572ae99f2 /mnt<br />
└─sda3 56adc99b-a61e-46af-aab7-a6d07e504652 <br />
}}<br />
<br />
Mounted file systems '''must''' be [[#Umount a file system|unmounted]] before proceeding. In the above example an existing filesystem is on {{ic|/dev/sda2}} and is mounted at {{ic|/mnt}}. It would be unmounted with:<br />
<br />
# umount /dev/sda2<br />
<br />
To find just mounted file systems, see [[#List mounted file systems]].<br />
<br />
To create a new file system, use {{man|8|mkfs}}. See [[#Types of file systems]] for the exact type, as well as userspace utilities you may wish to install for a particular file system.<br />
<br />
For example, to create a new file system of type [[ext4]] (common for Linux data partitions) on {{ic|/dev/sda1}}, run:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Tip|<br />
* Use the {{ic|-L}} flag of ''mkfs.ext4'' to specify a [[Persistent_block_device_naming#by-label|file system label]]. ''e2label'' can be used to change the label on an existing file system.<br />
* File systems may be ''resized'' after creation, with certain limitations. For example, an [[XFS]] filesystem's size can be increased, but it cannot reduced. See [[w:Comparison_of_file_systems#Resize_capabilities|Resize capabilities]] and the respective file system documentation for details.}}<br />
<br />
The new file system can now be mounted to a directory of choice.<br />
<br />
== Mount a filesystem ==<br />
<br />
To manually mount filesystem located on a device (e.g., a partition) to a directory, use {{man|8|mount}}. This example mounts {{ic|/dev/sda1}} to {{ic|/mnt}}.<br />
<br />
# mount /dev/sda1 /mnt<br />
<br />
This attaches the filesystem on {{ic|/dev/sda1}} at the directory {{ic|/mnt}}, making the contents of the filesystem visible. Any data that existed at {{ic|/mnt}} before this action is made invisible until the device is unmounted.<br />
<br />
[[fstab]] contains information on how devices should be automatically mounted if present. See the [[fstab]] article for more information on how to modify this behavior.<br />
<br />
If a device is specified in {{ic|/etc/fstab}} and only the device or mount point is given on the command line, that information will be used in mounting. For example, if {{ic|/etc/fstab}} contains a line indicating that {{ic|/dev/sda1}} should be mounted to {{ic|/mnt}}, then the following will automatically mount the device to that location:<br />
<br />
# mount /dev/sda1<br />
<br />
Or<br />
<br />
# mount /mnt<br />
<br />
''mount'' contains several options, many of which depend on the file system specified.<br />
The options can be changed, either by:<br />
* using flags on the command line with ''mount''<br />
* editing [[fstab]]<br />
* creating [[udev]] rules<br />
* [[Arch Build System|compiling the kernel yourself]]<br />
* or using filesystem-specific mount scripts (located at {{ic|/usr/bin/mount.*}}).<br />
<br />
See these related articles and the article of the filesystem of interest for more information.<br />
<br />
=== List mounted file systems ===<br />
<br />
To list all mounted file systems, use {{man|8|findmnt}}:<br />
<br />
$ findmnt<br />
<br />
''findmnt'' takes a variety of arguments which can filter the output and show additional information. For example, it can take a device or mount point as an argument to show only information on what is specified:<br />
<br />
$ findmnt /dev/sda1<br />
<br />
''findmnt'' gathers information from {{ic|/etc/fstab}}, {{ic|/etc/mtab}}, and {{ic|/proc/self/mounts}}.<br />
<br />
=== Umount a file system ===<br />
<br />
To unmount a file system use {{man|8|umount}}. Either the device containing the file system (e.g., {{ic|/dev/sda1}}) or the mount point (e.g., {{ic|/mnt}}) can be specified:<br />
<br />
# umount /dev/sda1<br />
<br />
Or<br />
<br />
# umount /mnt<br />
<br />
== See also ==<br />
<br />
* {{man|5|filesystems}}<br />
* [https://www.kernel.org/doc/Documentation/filesystems/ Documentation of file systems supported by linux]<br />
* [[Wikipedia:File systems]]<br />
* [[Wikipedia:Mount (Unix)]]</div>Kay94https://wiki.archlinux.org/index.php?title=User_talk:Edh&diff=483423User talk:Edh2017-07-31T08:03:19Z<p>Kay94: /* sudo/visudo */ final?</p>
<hr />
<div>{| style="border:1px solid #8888aa; background-color:#f7f8ff; padding:5px; font-size:95%;" align=center width=90% id=toc0<br />
|align="center" rowspan="2"| <br />
<font face="Times New Roman, serif" color="#000080" size="+2">W<small>ELCOME TO MY TALK PAGE!</small></font><br><small> <span class="plainlinks">'''[{{fullurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit&section=new}} <span style="color: #002BB8;">Leave me a message</span>]</span>''' · '''[[Wikipedia:Signatures|Please sign and date your posts]] by typing four tildes (<code><nowiki>~~~~</nowiki></code>).'''</small><br />
|}<br />
<br />
== <s>sudo/visudo</s> ==<br />
Hi,<br />
I saw your edit in sudo. How about pointing out the command "EDITOR=nano visudo" has to be run as root in the text (not in the code as I did), just with a "(as root)"? Maybe I'm stupid, but believe me, I was literally sitting at my computer half an our to make the given code somehow run with different approaches with sudo, which all didn't work and I so far have never read that '#' is meaning root. I mean, of course I believe you in that, it's just sometimes hard to get to know those small facts as a newbie when reading a wiki article. :) Regards<br />
[[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:11, 29 July 2017 (UTC)kay94<br />
<br />
: It is quite common for shell documentation to follow this schema of prefixing root commands with {{ic|#}} and the standard user prompt with {{ic|$}}. I do admit that this might be hard to even notice at first. However the warning message when running a root command as non-root user is usually very revealing. In the discussed case the error message should yield something similar to "''visudo: /etc/sudoers: '''Permission''' denied''" which should already have given you the hint to check whether you do run this as the 'correct' user.<br />
<br />
: I am sorry to hear that this worsen your experience setting up [[sudo]]. However I still think it is better to not specifically mention the user under which the command is supposed to run. The core question becomes why would it be necessary to state it here and not elsewhere? Clearly it nonsensical to specify it every time. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:11, 29 July 2017 (UTC)<br />
<br />
: I guess it will not help you much now, but just for completeness sake: Here is a link to the corresponding section of the [[Help:Style#Command line text|command formatting article]] in the ArchWiki. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:32, 29 July 2017 (UTC)<br />
<br />
::Thanks Edh, if I can step in quickly, I suggest Kay94 to read [[Help:Reading#Regular user or root]] and the rest of that article :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:45, 30 July 2017 (UTC)<br />
<br />
::: Hi, thank you very much for your reactions! I can see your points. Anyway, in this particular case, I think it might be helpful to specify "(as root)" additionally, because when I do "$ EDITOR=nano visudo" of course it tells me about missing privileges. So I did "$ EDITOR=nano sudo visudo" and "$ EDITOR=nano" "$ sudo visudo", which both didn't work, I ended up in vi both times (VISUAL is set to nano, too, btw). Sure I missunderstand something there about proper usage of visudo, but I think this will happen to other people too. Regards -- [[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:58, 30 July 2017 (UTC) kay94<br />
<br />
:::: First of all you misinterpreted how your shell (probably {{ic|bash}}) handles variables and how {{ic|sudo}} passes them on. To me it seems your problem mostly boils down to bad luck :P If you would have tried {{ic|<nowiki>sudo EDITOR=nano visudo</nowiki>}} it would have worked flawlessly. This case might look more complicated at first, but simply prefixing the command with {{ic|sudo}} after getting a permissions error would have resolved this. Since placing {{ic|sudo}} in front of the command resolves almost all confusions of {{ic|$}} and {{ic|#}} (including this one), I would think of this as a fairly usual case, which does not need any further explanation within the article. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 17:12, 30 July 2017 (UTC)<br />
<br />
::::: Haha, okay! Bad luck sounds right. ^^ "sudo EDITOR=nano visudo" really worked (bash). At least this made me look a bit into vim (not vi though) and it's not that bad acutally. I'm not sure if I get your last sentence right: Do you aggree it would be helpful to place a sudo in this case, as it removes all confusion? If so, you and I had a democratic 2/3 majority in this discussion, if not, I'm alone resulting in 1/3 and the article better stay as it is. -- [[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 20:31, 30 July 2017 (UTC) kay94<br />
<br />
:::::: The intention of my last sentence was to emphasize that the case discussed in this thread is not special and hence does not require deviating from the above mentioned [[Help:Style#Command line text]]. Sticking {{ic|sudo}} in front of a command if you get errors related to insufficient permissions is probably what most users will do automatically and needs not to be explicitly stated in the article. In reference to your conclusion it seems to stand 1/3 then ;P (Btw. the ArchWiki does not necessarily need to work like a democracy, e.g. some wiki pages are completely off limits for ''normal'' editors :D). I hope you do not feel to strongly about the issue and are fine with things staying the way they are. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 21:21, 30 July 2017 (UTC)<br />
<br />
::::::: Okay, sure! I'm cool, thank you for the patience. [[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 08:03, 31 July 2017 (UTC)kay94<br />
<br />
== <s>Update reference to libinput-gestures</s> ==<br />
<br />
Hi,<br />
<br />
I see you added your libinput-gestures-git to the Arch Wiki page on libinput. Do you mind if I update that to to point to libinput-gestures?<br />
<br />
[[User:Bulletmark|Bulletmark]] ([[User talk:Bulletmark|talk]]) 00:23, 19 August 2016 (UTC)<br />
<br />
: Sure, go ahead. It is always preferred to point to the stable release. I edited the wiki prior to the creation of your package. It was was not meant to be permanent. Though obviously your package deserves the spotlight here, it is very kind of you to ask. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 07:02, 19 August 2016 (UTC)</div>Kay94https://wiki.archlinux.org/index.php?title=User_talk:Edh&diff=483411User talk:Edh2017-07-30T20:31:39Z<p>Kay94: /* sudo/visudo */</p>
<hr />
<div>{| style="border:1px solid #8888aa; background-color:#f7f8ff; padding:5px; font-size:95%;" align=center width=90% id=toc0<br />
|align="center" rowspan="2"| <br />
<font face="Times New Roman, serif" color="#000080" size="+2">W<small>ELCOME TO MY TALK PAGE!</small></font><br><small> <span class="plainlinks">'''[{{fullurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit&section=new}} <span style="color: #002BB8;">Leave me a message</span>]</span>''' · '''[[Wikipedia:Signatures|Please sign and date your posts]] by typing four tildes (<code><nowiki>~~~~</nowiki></code>).'''</small><br />
|}<br />
<br />
== sudo/visudo ==<br />
Hi,<br />
I saw your edit in sudo. How about pointing out the command "EDITOR=nano visudo" has to be run as root in the text (not in the code as I did), just with a "(as root)"? Maybe I'm stupid, but believe me, I was literally sitting at my computer half an our to make the given code somehow run with different approaches with sudo, which all didn't work and I so far have never read that '#' is meaning root. I mean, of course I believe you in that, it's just sometimes hard to get to know those small facts as a newbie when reading a wiki article. :) Regards<br />
[[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:11, 29 July 2017 (UTC)kay94<br />
<br />
: It is quite common for shell documentation to follow this schema of prefixing root commands with {{ic|#}} and the standard user prompt with {{ic|$}}. I do admit that this might be hard to even notice at first. However the warning message when running a root command as non-root user is usually very revealing. In the discussed case the error message should yield something similar to "''visudo: /etc/sudoers: '''Permission''' denied''" which should already have given you the hint to check whether you do run this as the 'correct' user.<br />
<br />
: I am sorry to hear that this worsen your experience setting up [[sudo]]. However I still think it is better to not specifically mention the user under which the command is supposed to run. The core question becomes why would it be necessary to state it here and not elsewhere? Clearly it nonsensical to specify it every time. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:11, 29 July 2017 (UTC)<br />
<br />
: I guess it will not help you much now, but just for completeness sake: Here is a link to the corresponding section of the [[Help:Style#Command line text|command formatting article]] in the ArchWiki. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:32, 29 July 2017 (UTC)<br />
<br />
::Thanks Edh, if I can step in quickly, I suggest Kay94 to read [[Help:Reading#Regular user or root]] and the rest of that article :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:45, 30 July 2017 (UTC)<br />
<br />
::: Hi, thank you very much for your reactions! I can see your points. Anyway, in this particular case, I think it might be helpful to specify "(as root)" additionally, because when I do "$ EDITOR=nano visudo" of course it tells me about missing privileges. So I did "$ EDITOR=nano sudo visudo" and "$ EDITOR=nano" "$ sudo visudo", which both didn't work, I ended up in vi both times (VISUAL is set to nano, too, btw). Sure I missunderstand something there about proper usage of visudo, but I think this will happen to other people too. Regards -- [[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:58, 30 July 2017 (UTC) kay94<br />
<br />
:::: First of all you misinterpreted how your shell (probably {{ic|bash}}) handles variables and how {{ic|sudo}} passes them on. To me it seems your problem mostly boils down to bad luck :P If you would have tried {{ic|<nowiki>sudo EDITOR=nano visudo</nowiki>}} it would have worked flawlessly. This case might look more complicated at first, but simply prefixing the command with {{ic|sudo}} after getting a permissions error would have resolved this. Since placing {{ic|sudo}} in front of the command resolves almost all confusions of {{ic|$}} and {{ic|#}} (including this one), I would think of this as a fairly usual case, which does not need any further explanation within the article. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 17:12, 30 July 2017 (UTC)<br />
<br />
::::: Haha, okay! Bad luck sounds right. ^^ "sudo EDITOR=nano visudo" really worked (bash). At least this made me look a bit into vim (not vi though) and it's not that bad acutally. I'm not sure if I get your last sentence right: Do you aggree it would be helpful to place a sudo in this case, as it removes all confusion? If so, you and I had a democratic 2/3 majority in this discussion, if not, I'm alone resulting in 1/3 and the article better stay as it is. -- [[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 20:31, 30 July 2017 (UTC) kay94<br />
<br />
== <s>Update reference to libinput-gestures</s> ==<br />
<br />
Hi,<br />
<br />
I see you added your libinput-gestures-git to the Arch Wiki page on libinput. Do you mind if I update that to to point to libinput-gestures?<br />
<br />
[[User:Bulletmark|Bulletmark]] ([[User talk:Bulletmark|talk]]) 00:23, 19 August 2016 (UTC)<br />
<br />
: Sure, go ahead. It is always preferred to point to the stable release. I edited the wiki prior to the creation of your package. It was was not meant to be permanent. Though obviously your package deserves the spotlight here, it is very kind of you to ask. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 07:02, 19 August 2016 (UTC)</div>Kay94https://wiki.archlinux.org/index.php?title=User_talk:Edh&diff=483410User talk:Edh2017-07-30T20:22:53Z<p>Kay94: /* sudo/visudo */ reply</p>
<hr />
<div>{| style="border:1px solid #8888aa; background-color:#f7f8ff; padding:5px; font-size:95%;" align=center width=90% id=toc0<br />
|align="center" rowspan="2"| <br />
<font face="Times New Roman, serif" color="#000080" size="+2">W<small>ELCOME TO MY TALK PAGE!</small></font><br><small> <span class="plainlinks">'''[{{fullurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit&section=new}} <span style="color: #002BB8;">Leave me a message</span>]</span>''' · '''[[Wikipedia:Signatures|Please sign and date your posts]] by typing four tildes (<code><nowiki>~~~~</nowiki></code>).'''</small><br />
|}<br />
<br />
== sudo/visudo ==<br />
Hi,<br />
I saw your edit in sudo. How about pointing out the command "EDITOR=nano visudo" has to be run as root in the text (not in the code as I did), just with a "(as root)"? Maybe I'm stupid, but believe me, I was literally sitting at my computer half an our to make the given code somehow run with different approaches with sudo, which all didn't work and I so far have never read that '#' is meaning root. I mean, of course I believe you in that, it's just sometimes hard to get to know those small facts as a newbie when reading a wiki article. :) Regards<br />
[[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:11, 29 July 2017 (UTC)kay94<br />
<br />
: It is quite common for shell documentation to follow this schema of prefixing root commands with {{ic|#}} and the standard user prompt with {{ic|$}}. I do admit that this might be hard to even notice at first. However the warning message when running a root command as non-root user is usually very revealing. In the discussed case the error message should yield something similar to "''visudo: /etc/sudoers: '''Permission''' denied''" which should already have given you the hint to check whether you do run this as the 'correct' user.<br />
<br />
: I am sorry to hear that this worsen your experience setting up [[sudo]]. However I still think it is better to not specifically mention the user under which the command is supposed to run. The core question becomes why would it be necessary to state it here and not elsewhere? Clearly it nonsensical to specify it every time. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:11, 29 July 2017 (UTC)<br />
<br />
: I guess it will not help you much now, but just for completeness sake: Here is a link to the corresponding section of the [[Help:Style#Command line text|command formatting article]] in the ArchWiki. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:32, 29 July 2017 (UTC)<br />
<br />
::Thanks Edh, if I can step in quickly, I suggest Kay94 to read [[Help:Reading#Regular user or root]] and the rest of that article :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:45, 30 July 2017 (UTC)<br />
<br />
::: Hi, thank you very much for your reactions! I can see your points. Anyway, in this particular case, I think it might be helpful to specify "(as root)" additionally, because when I do "$ EDITOR=nano visudo" of course it tells me about missing privileges. So I did "$ EDITOR=nano sudo visudo" and "$ EDITOR=nano" "$ sudo visudo", which both didn't work, I ended up in vi both times (VISUAL is set to nano, too, btw). Sure I missunderstand something there about proper usage of visudo, but I think this will happen to other people too. Regards -- [[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:58, 30 July 2017 (UTC) kay94<br />
<br />
:::: First of all you misinterpreted how your shell (probably {{ic|bash}}) handles variables and how {{ic|sudo}} passes them on. To me it seems your problem mostly boils down to bad luck :P If you would have tried {{ic|<nowiki>sudo EDITOR=nano visudo</nowiki>}} it would have worked flawlessly. This case might look more complicated at first, but simply prefixing the command with {{ic|sudo}} after getting a permissions error would have resolved this. Since placing {{ic|sudo}} in front of the command resolves almost all confusions of {{ic|$}} and {{ic|#}} (including this one), I would think of this as a fairly usual case, which does not need any further explanation within the article. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 17:12, 30 July 2017 (UTC)<br />
<br />
::::: Haha, okay! Bad luck sounds right. ^^ "sudo EDITOR=nano visudo" really worked (bash). At least this made me look a bit into vim (not vi though) and it's not that bad acutally. I'm not sure if I get your last sentence right: Do you aggree it would be helpful to place a sudo in this case, as it removes all confusion? If so, you and I had a democratic 2/3 majority in this discussion, if not, I'm alone resulting in 1/3 and the article better stay as it is.<br />
<br />
== <s>Update reference to libinput-gestures</s> ==<br />
<br />
Hi,<br />
<br />
I see you added your libinput-gestures-git to the Arch Wiki page on libinput. Do you mind if I update that to to point to libinput-gestures?<br />
<br />
[[User:Bulletmark|Bulletmark]] ([[User talk:Bulletmark|talk]]) 00:23, 19 August 2016 (UTC)<br />
<br />
: Sure, go ahead. It is always preferred to point to the stable release. I edited the wiki prior to the creation of your package. It was was not meant to be permanent. Though obviously your package deserves the spotlight here, it is very kind of you to ask. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 07:02, 19 August 2016 (UTC)</div>Kay94https://wiki.archlinux.org/index.php?title=Tmux&diff=483391Tmux2017-07-30T12:24:35Z<p>Kay94: /* Troubleshooting */ Added "Bashrc not sourced"</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Terminal emulators]]<br />
[[es:Tmux]]<br />
[[ja:Tmux]]<br />
[[ru:Tmux]]<br />
[[tr:Tmux]]<br />
[[zh-hans:Tmux]]<br />
{{Related articles start}}<br />
{{Related|dtach}}<br />
{{Related|GNU Screen}}<br />
{{Related articles end}}<br />
<br />
[http://tmux.github.io/ tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
tmux is an ISC-licensed alternative to [[GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [https://github.com/tmux/tmux/wiki/FAQ tmux FAQ page].<br />
<br />
== Installation ==<br />
[[Install]] the {{Pkg|tmux}} package.<br />
Optionally, install {{Aur|tmux-bash-completion}} to provide bash completion functions for tmux.<br />
<br />
== Configuration ==<br />
A user-specific configuration file should be located at {{ic|~/.tmux.conf}}, while a global configuration file should be located at {{ic|/etc/tmux.conf}}.<br />
<br />
=== Key bindings ===<br />
<br />
By default, command key bindings are prefixed by {{Ic|Ctrl-b}}. For example, to vertically split a window type {{Ic|Ctrl-b+%}}.<br />
<br />
After splitting a window into multiple panes, a pane can be resized by the hitting prefix key (e.g. {{Ic|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{ic|tmux.conf}}. For example, the default prefix binding of {{Ic|Ctrl-b}} can be changed to {{Ic|Ctrl-a}} by adding the following commands in your configuration file:<br />
<br />
{{bc|<br />
unbind C-b<br />
set -g prefix C-a<br />
bind C-a send-prefix<br />
}}<br />
<br />
{{Tip|Quote special characters to use them as prefix. You may also use {{ic|Alt}} (called Meta) instead of {{ic|Ctrl}}. For example: {{ic|set -g prefix m-'\'}}}}<br />
<br />
Additional ways to move between windows include the following:<br />
<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
tmux has a find-window option & key binding to ease navigation of many windows:<br />
<br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
==== Copy Mode ====<br />
<br />
A tmux window may be in one of several modes. The default permits direct access to the terminal attached to the window; the other is copy mode. Once in copy mode you can navigate the buffer including scrolling the history. Use vi or emacs-style key bindings in copy mode. The default is emacs, unless VISUAL or EDITOR contains ‘vi’<br />
<br />
To enter copy mode do the following:<br />
<br />
Ctrl-b [<br />
<br />
You can navigate the buffer as you would in your default editor.<br />
<br />
To quit copy mode, use one of the following keybindings:<br />
<br />
vi mode:<br />
q<br />
emacs mode:<br />
Esc<br />
<br />
=== Browsing URLs ===<br />
To browse URLs inside tmux you must have {{AUR|urlview}} installed and configured.<br />
<br />
Inside a new terminal:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e urlview /tmp/tmux-buffer"<br />
<br />
Or inside a new tmux window (no new terminal needed):<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; new-window -n "urlview" '$SHELL -c "urlview < /tmp/tmux-buffer"'<br />
<br />
=== Setting the correct term ===<br />
==== 256 colors ====<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. As of [https://raw.githubusercontent.com/tmux/tmux/master/CHANGES tmux 2.1], this is now ''tmux'', or ''tmux-256color''. You can do this in {{ic|tmux.conf}}:<br />
<br />
set -g default-terminal "tmux-256color" <br />
<br />
Other, older alternatives, include ''screen'', or ''screen-256color'':<br />
<br />
set -g default-terminal "screen-256color"<br />
<br />
Also, if tmux messes up, you can force tmux to assume that the terminal support 256 colors, by adding this in your .bashrc:<br />
<br />
alias tmux="tmux -2"<br />
<br />
==== 24-bit color ====<br />
tmux supports 24-bit color as of version 2.2 ([https://github.com/tmux/tmux/commit/427b8204268af5548d09b830e101c59daa095df9]). If your terminal supports 24-bit color (see this [https://gist.github.com/XVilka/8346728 gist]), add your terminal to the {{ic|terminal-overrides}} setting. For example, if you use [[Termite]], you would add:<br />
<br />
set -ga terminal-overrides ",xterm-termite:Tc"<br />
<br />
For other terminals, replace {{ic|xterm-termite}} with the relevant terminal type (stored in {{ic|$TERM}}). See the tmux(1) man page for details about the {{ic|Tc}} terminfo extension.<br />
<br />
==== xterm-keys ====<br />
To enable xterm-keys in your {{ic|tmux.conf}}, you have to add the following line<br />
<br />
set-option -g xterm-keys on<br />
<br />
If you enable xterm-keys in your {{ic|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{ic|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
=== Other Settings ===<br />
To limit the scrollback buffer to 10000 lines:<br />
set -g history-limit 10000<br />
<br />
Terminal emulator settings can be overridden with<br />
set -ga terminal-overrides ',xterm*:smcup@:rmcup@'<br />
set -ga terminal-override ',rxvt-uni*:XT:Ms=\E]52;%p1%s;%p2%s\007'<br />
<br />
Mouse can be toggled with<br />
bind-key m set-option -g mouse on \; display 'Mouse: ON'<br />
bind-key M set-option -g mouse off \; display 'Mouse: OFF'<br />
<br />
=== Autostart with systemd ===<br />
<br />
There are some notable advantages to starting a tmux server at startup.<br />
Notably, when you start a new tmux session, having the service already running reduces any delays in the startup.<br />
<br />
Furthermore, any customization attached to your tmux session will be retained and your tmux session can be made to persist even if you have never logged in, if you have some reason to do that (like a heavily scripted tmux configuration or shared user tmux sessions).<br />
<br />
The service below starts ''tmux'' for the specified user (i.e. start with {{ic|tmux@''username''.service}}):<br />
<br />
{{hc|/etc/systemd/system/tmux@.service|<nowiki><br />
[Unit]<br />
Description=Start tmux in detached session<br />
<br />
[Service]<br />
Type=forking<br />
User=%I<br />
ExecStart=/usr/bin/tmux new-session -s %u -d<br />
ExecStop=/usr/bin/tmux kill-session -t %u<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Tip|You may want to add {{ic|1=WorkingDirectory=''custom_path''}} to customize working directory.}}<br />
<br />
Alternatively, you can place this file within your [[systemd/User]] directory (without {{ic|1=User=%I}}), for example {{ic|~/.config/systemd/user/tmux.service}}. This way the tmux service will start when you log in, unless you also enable [[systemd/User#Automatic start-up of systemd user instances]].<br />
<br />
== Session initialization ==<br />
You can have tmux open a session with preloaded windows by including those details in your {{ic|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{ic|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
== Troubleshooting ==<br />
<br />
=== Bashrc not sourced ===<br />
<br />
If using bash as system shell and starting tmux, one might notice, that per default the {{ic|~/.bashrc}} file has not been sourced (executed). Custom aliases or a custom prompt formatting are not available, additionally the history of the current tmux session won't be saved to the bash-history ({{ic|~/.bash_history}}) and the bash-history is inaccessible with arrow keys. To temporarily change this for the current session, do the following:<br />
<br />
$ source ~/.bashrc<br />
<br />
To permantently change this (sourcing {{ic|~/.bashrc}} at every startup of tmux), do the following in your home directory:<br />
<br />
$ echo "case \$- in *i*) . ~/.bashrc;; esac" >> .bash_profile<br />
<br />
=== Scrolling issues ===<br />
<br />
If you have issues scrolling with Shift-Page Up/Down in your terminal, the following will remove the smcup and rmcup capabilities for any term that reports itself as anything beginning with {{ic|xterm}}:<br />
<br />
set -ga terminal-overrides ',xterm*:smcup@:rmcup@'<br />
<br />
This tricks the terminal emulator into thinking tmux is a full screen application like pico or mutt[http://superuser.com/questions/310251/use-terminal-scrollbar-with-tmux], which will make the scrollback be recorded properly. Beware however, it will get a bit messed up when switching between windows/panes. Consider using tmux's native scrollback instead.<br />
<br />
=== Mouse scrolling ===<br />
<br />
{{Note|This interferes with selection buffer copying and pasting. To copy/paste to/from the selection buffer hold the shift key.}}<br />
<br />
If you want to scroll with your mouse wheel, ensure mode-mouse is on in .tmux.conf<br />
set -g mouse on<br />
<br />
You can set scroll History with:<br />
set -g history-limit 30000<br />
<br />
For mouse wheel scrolling as from tmux 2.1 try adding one or both of these to ~/.tmux.conf<br />
bind -T root WheelUpPane if-shell -F -t = "#{alternate_on}" "send-keys -M" "select-pane -t =; copy-mode -e; send-keys -M"<br />
bind -T root WheelDownPane if-shell -F -t = "#{alternate_on}" "send-keys -M" "select-pane -t =; send-keys -M"<br />
<br />
Though the above will only scroll one line at a time, add this solution to scroll an entire page instead<br />
bind -t vi-copy WheelUpPane page-up<br />
bind -t vi-copy WheelDownPane page-down<br />
bind -t emacs-copy WheelUpPane page-up<br />
bind -t emacs-copy WheelDownPane page-down<br />
<br />
=== Terminal emulator does not support UTF-8 mouse events ===<br />
<br />
When the terminal emulator does not support the UTF-8 mouse events and the {{ic|mouse on}} tmux option is set, left-clicking inside the terminal window might paste strings like {{ic|[M#}} or {{ic|[Ma}} into the promt.<br />
<br />
To solve this issue set:<br />
<br />
set -g mouse-utf8 off<br />
<br />
=== Shift+F6 not working in Midnight Commander ===<br />
<br />
See [[Midnight Commander#Broken shortcuts]].<br />
<br />
== X clipboard integration ==<br />
<br />
{{Tip|The tmux plugin [https://github.com/tmux-plugins/tmux-yank tmux-yank] provides similar functionality.}}<br />
<br />
It is possible to copy tmux selection to X clipboard (and to X primary/secondary selection) and in reverse direction. The following tmux config file snippet effectively integrates X clipboard/selection with the current tmux selection using the program {{Pkg|xsel}}:<br />
<br />
# Emacs style<br />
bind-key -T copy-mode y send-key -X copy-pipe-and-cancel "xsel -i -p && xsel -o -p | xsel -i -b"<br />
bind-key C-y run "xsel -o | tmux load-buffer - ; tmux paste-buffer"<br />
<br />
# Vim style<br />
bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel "xsel -i -p && xsel -o -p | xsel -i -b"<br />
bind-key p run "xsel -o | tmux load-buffer - ; tmux paste-buffer"<br />
<br />
{{pkg|xclip}} could also be used for that purpose, unlike xsel it works better on printing raw bitstream that doesn't fit the current locale. Nevertheless, it is neater to use <code>xsel</code> instead of <code>xclip</code>, because xclip does not close STDOUT after it has read from tmux's buffer. As such, tmux doesn't know that the copy task has completed, and continues to wait for xclip's termination, thereby rendering tmux unresponsive. A workaround is to redirect <code>STDOUT</code> of <code>xclip</code> to <code>/dev/null</code>, like in the following:<br />
<br />
# Vim style<br />
bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel "xclip -i -sel clip > /dev/null"<br />
bind-key p run "xclip -o -sel clip | tmux load-buffer - ; tmux paste-buffer"<br />
<br />
=== Urxvt middle click ===<br />
<br />
{{Note|To use this, you need to enable mouse support}}<br />
<br />
There is an unofficial perl extension ([https://github.com/tmux/tmux/wiki/FAQ#how-do-i-copy-a-selection-from-tmux-to-the-systems-clipboard mentioned] in the official [https://github.com/tmux/tmux/wiki/FAQ FAQ]) to enable copying/pasting in and out of urxvt with tmux via Middle Mouse Clicking.<br />
<br />
First, you will need to download the perl script and place it into urxvts perl lib:<br />
<br />
{{bc|wget http://anti.teamidiot.de/static/nei/*/Code/urxvt/osc-xterm-clipboard<br />
mv osc-xterm-clipboard /usr/lib/urxvt/perl/|<br />
}}<br />
<br />
You will also need to enable that perl script in your .Xdefaults:<br />
<br />
{{hc|~/.Xdefaults|<br />
...<br />
*URxvt.perl-ext-common: osc-xterm-clipboard<br />
...<br />
}}<br />
<br />
Next, you want to tell tmux about the new function and enable mouse support (if you haven't already):<br />
<br />
{{hc|~/.tmux.conf|<br />
...<br />
set-option -ga terminal-override ',rxvt-uni*:XT:Ms<nowiki>=</nowiki>\E]52;%p1%s;%p2%s\007'<br />
set -g mouse on<br />
...<br />
}}<br />
<br />
That's it. Be sure to end all instances of tmux before trying the new MiddleClick functionality.<br />
<br />
While in tmux, Shift+MiddleMouseClick will paste the clipboard selection while just MiddleMouseClick will paste your tmux buffer.<br />
Outside of tmux, just use MiddleMouseClick to paste your tmux buffer and your standard Ctrl-c to copy.<br />
<br />
== Tips and tricks ==<br />
=== Start tmux with default session layout ===<br />
Session managers like tmuxinator and [[tmuxp]] make it easy to manage common session configurations.<br />
<br />
For tmuxinator, install {{AUR|tmuxinator}} from [[AUR]]. Test your installation with<br />
<br />
tmuxinator doctor<br />
<br />
==== Get the default layout values ====<br />
Start tmux as usual and configure your windows and panes layout as you like. When finished, get the current layout values by executing (while you are still within the current tmux session)<br />
<br />
tmux list-windows<br />
<br />
The output may look like this (two windows with 3 panes and 2 panes layout)<br />
<br />
0: default* (3 panes) [274x83] [layout 20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}] @2 (active)<br />
1: remote- (2 panes) [274x83] [layout e3d3,274x83,0,0[274x41,0,0,4,274x41,0,42,7]] @3 <br />
<br />
The Interesting part you need to copy for later use begins after '''[layout...''' and excludes '''... ] @2 (active)'''. For the first window layout you need to copy e.g. '''20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}'''<br />
<br />
==== Define the default tmux layout ====<br />
<br />
Knowing this, you can exit the current tmux session. Following this, you create your default tmux session layout by editing tmuxinator's config file (Don't copy the example, get your layout values as described above)<br />
<br />
{{hc|~/.tmuxinator/default.yml|<nowiki><br />
name: default<br />
root: ~/<br />
windows:<br />
- default:<br />
layout: 20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}<br />
panes:<br />
- clear<br />
- vim<br />
- clear && emacs -nw<br />
- remote:<br />
layout: 24ab,274x83,0,0{137x83,0,0,3,136x83,138,0,4}<br />
panes:<br />
- <br />
- <br />
</nowiki>}}<br />
<br />
The example defines two windows named "default" and "remote". With your determined layout values. For each pane you have to use at least one {{ic|-}} line. Within the first window panes you start the commandline "clear" in pane one, "vim" in pane two and "clear && emacs -nw" executes two commands in pane three on each tmux start. The second window layout has two panes without defining any start commmands.<br />
<br />
Test the new default layout with (yes, it is "mux"):<br />
<br />
mux default<br />
<br />
==== Autostart tmux with default tmux layout ====<br />
<br />
If you like to start your terminal session with your default tmux session layout edit<br />
{{hc|~/.bashrc|<nowiki><br />
if [ -z "$TMUX" ]; then<br />
mux default <br />
fi <br />
</nowiki>}}<br />
<br />
====Alternate approach for default session====<br />
Instead of using the above method, one can just write a bash script that when run, will create the default session and attach to it.<br />
Then you can execute it from a terminal to get the pre-designed configuration in that terminal<br />
<br />
#!/bin/bash<br />
tmux new-session -d -n WindowName Command<br />
tmux new-window -n NewWindowName<br />
tmux split-window -v<br />
tmux selectp -t 1<br />
tmux split-window -h<br />
tmux selectw -t 1<br />
tmux -2 attach-session -d<br />
<br />
===Start tmux in urxvt===<br />
Use this command to start urxvt with a started tmux session. I use this with the exec command from my .ratpoisonrc file.<br />
{{bc|<nowiki>urxvt -e bash -c "tmux -q has-session && exec tmux attach-session -d || exec tmux new-session -n$USER -s$USER@$HOSTNAME"</nowiki>}}<br />
<br />
=== Start tmux on every shell login ===<br />
<br />
==== Bash ====<br />
<br />
For bash, simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# If not running interactively, do not do anything<br />
[[ $- != *i* ]] && return<br />
[[ -z "$TMUX" ]] && exec tmux<br />
</nowiki>}}<br />
<br />
{{note|This snippet ensures that tmux is not launched inside of itself (something tmux usually already checks for anyway). tmux sets $TMUX to the socket it is using whenever it runs, so if $TMUX isn't set or is length 0, we know we aren't already running tmux.}}<br />
<br />
Add the following snippet to start only one session (unless you start some manually), on login, try attach at first, only create a session if no tmux is running.<br />
<br />
{{bc|<nowiki><br />
# TMUX<br />
if which tmux >/dev/null 2>&1; then<br />
#if not inside a tmux session, and if no session is started, start a new session<br />
test -z "$TMUX" && (tmux attach || tmux new-session)<br />
fi<br />
</nowiki>}}<br />
<br />
The following snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
{{bc|<nowiki><br />
# TMUX<br />
if which tmux >/dev/null 2>&1; then<br />
# if no session is started, start a new session<br />
test -z ${TMUX} && tmux<br />
<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
</nowiki>}}<br />
<br />
Another possibility is to try to attach to existing deattached session or start a new session:<br />
<br />
{{bc|<nowiki><br />
if [[ -z "$TMUX" ]] ;then<br />
ID="`tmux ls | grep -vm1 attached | cut -d: -f1`" # get the id of a deattached session<br />
if [[ -z "$ID" ]] ;then # if not available create a new one<br />
tmux new-session<br />
else<br />
tmux attach-session -t "$ID" # if available attach to it<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
=== Start a non-login shell ===<br />
<br />
tmux starts a [http://unix.stackexchange.com/questions/38175 login shell] [http://comments.gmane.org/gmane.comp.terminal-emulators.tmux.user/5997 by default], which may result in multiple negative side effects:<br />
<br />
* Users of [[Wikipedia:fortune (Unix)|fortune]] may notice that quotes are printed when creating a new panel.<br />
* The configuration files for login shells such as {{ic|~/.profile}} are interpreted each time a new panel is created, so commands intended to be run on session initialization (e.g. setting audio level) are executed.<br />
<br />
To disable this behaviour, add to {{ic|~/.tmux.conf}}:<br />
<br />
set -g default-command "${SHELL}"<br />
<br />
=== Use tmux windows like tabs ===<br />
<br />
The following settings added to {{ic|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]{{Broken section link}}. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{ic|Ctrl+d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
=== Clients simultaneously interacting with various windows of a session ===<br />
<br />
In [http://mutelight.org/articles/practical-tmux Practical Tmux], Brandur Leach writes:<br />
<br />
: Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
: This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
The script “{{Ic|tmx}}” below implements this — the version here is slightly modified to execute “{{Ic|tmux new-window}}” if “1” is its second parameter. Invoked as {{Ic|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise a new “client” session linked to the base, optionally add a new window and attach, setting it to kill itself once it turns “zombie”.<br />
<br />
{{hc|tmx|2=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
echo "Launching copy of base session $base_session ..."<br />
# Session id is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session & kill it once orphaned<br />
tmux attach-session -t $session_id \; set-option destroy-unattached<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{ic|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
An alternative taken from [http://comments.gmane.org/gmane.comp.terminal-emulators.tmux.user/2632] is to put the following ~/.bashrc:<br />
<br />
{{hc|.bashrc|2=<nowiki><br />
function rsc() {<br />
CLIENTID=$1.`date +%S`<br />
tmux new-session -d -t $1 -s $CLIENTID \; set-option destroy-unattached \; attach-session -t $CLIENTID<br />
}<br />
<br />
function mksc() {<br />
tmux new-session -d -s $1<br />
rsc $1<br />
}<br />
</nowiki>}}<br />
<br />
Citing the author:<br />
<br />
: "mksc foo" creates a always detached permanent client named "foo". It also calls "rsc foo" to create a client to newly created session. "rsc foo" creates a new client grouped by "foo" name. It has destroy-unattached turned on so when I leave it, it kills client.<br />
: Therefore, when my computer looses network connectivity, all "foo.something" clients are killed while "foo" remains. I can then call "rsc foo" to continue work from where I stopped.<br />
<br />
=== Correct the TERM variable according to terminal type ===<br />
Instead of [[#Setting_the_correct_term|setting a fixed TERM variable in tmux]], it is possible to set the proper TERM (either {{ic|screen}} or {{ic|screen-256color}}) according to the type of your terminal emulator:<br />
<br />
{{hc|~/.tmux.conf|<br />
## set the default TERM<br />
set -g default-terminal screen<br />
<br />
## update the TERM variable of terminal emulator when creating a new session or attaching a existing session<br />
set -g update-environment 'DISPLAY SSH_ASKPASS SSH_AGENT_PID SSH_CONNECTION WINDOWID XAUTHORITY TERM'<br />
## determine if we should enable 256-colour support<br />
if "[[ ${TERM} =~ 256color || ${TERM} == fbterm ]]" 'set -g default-terminal screen-256color'<br />
}}<br />
<br />
{{hc|1=~/.zshrc|2=<br />
## workaround for handling TERM variable in multiple tmux sessions properly from http://sourceforge.net/p/tmux/mailman/message/32751663/ by Nicholas Marriott<br />
if [[ -n ${TMUX} && -n ${commands[tmux]} ]];then<br />
case $(tmux showenv TERM 2>/dev/null) in<br />
*256color) ;&<br />
TERM=fbterm)<br />
TERM=screen-256color ;;<br />
*)<br />
TERM=screen<br />
esac<br />
fi<br />
}}<br />
<br />
=== Reload an updated configuration without restarting tmux ===<br />
<br />
By default tmux reads {{ic|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{ic|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
You can also do ^: and type :<br />
source .tmux.conf<br />
<br />
===Template script to run program in new session resp. attach to existing one===<br />
<br />
This script checks for a program presumed to have been started by a previous run of itself. Unless found it creates a new tmux session and attaches to a window named after and running the program. If however the program was found it merely attaches to the session and selects the window.<br />
<br />
#!/bin/bash<br />
<br />
PID=$(pidof $1)<br />
<br />
if [ -z "$PID" ]; then<br />
tmux new-session -d -s main ;<br />
tmux new-window -t main -n $1 "$*" ;<br />
fi<br />
tmux attach-session -d -t main ;<br />
tmux select-window -t $1 ;<br />
exit 0<br />
<br />
A derived version to run ''irssi'' with the ''nicklist'' plugin can be found on [[Irssi#irssi_with_nicklist_in_tmux|its ArchWiki page]].<br />
<br />
=== Terminal emulator window titles ===<br />
If you SSH into a host in a tmux window, you'll notice the window title of your terminal emulator remains to be {{ic|user@localhost}} rather than {{ic|user@server}}. To allow the title bar to adapt to whatever host you connect to, set the following in {{ic|~/.tmux.conf}}<br />
<br />
set -g set-titles on<br />
set -g set-titles-string "#T"<br />
<br />
For {{ic|set-titles-string}}, {{ic|#T}} will display {{ic|user@host:~}} and change accordingly as you connect to different hosts.<br />
<br />
=== Automatic layouting ===<br />
When creating new splits or destroying older ones the currently selected layout isn't applied. To fix that, add following binds which will apply the currently selected layout to new or remaining panes:<br />
<br />
bind-key -n M-c kill-pane \; select-layout<br />
bind-key -n M-n split-window \; select-layout<br />
<br />
=== Vim friendly configuration ===<br />
<br />
See [https://gist.github.com/anonymous/6bebae3eb9f7b972e6f0] for a configuration friendly to [[vim]] users.<br />
<br />
With tmux 2.4 change:<br />
bind -t vi-copy 'v' begin-selection<br />
bind -t vi-copy 'y' copy-selection<br />
bind -t vi-copy 'Space' halfpage-down<br />
bind -t vi-copy 'Bspace' halfpage-up<br />
<br />
to:<br />
bind-key -T copy-mode-vi 'v' send -X begin-selection<br />
bind-key -T copy-mode-vi 'y' send -X copy-selection<br />
bind-key -T copy-mode-vi 'Space' send -X halfpage-down<br />
bind-key -T copy-mode-vi 'Bspace' send -X halfpage-up<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 BBS topic]<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison]<br />
* [https://github.com/Lokaltog/powerline powerline], a dynamic statusbar for tmux<br />
* [https://github.com/tmux-plugins Plugins for tmux]<br />
<br />
'''Tutorials'''<br />
<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux]<br />
* [http://www.openbsd.org/cgi-bin/man.cgi?query=tmux man page (OpenBSD)]<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] and [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2]<br />
* [https://leanpub.com/the-tao-of-tmux/read ''The Tao of tmux''], an ebook by Tony Narlock, author of [https://tmuxp.git-pull.com tmuxp] and [https://libtmux.git-pull.com libtmux]</div>Kay94https://wiki.archlinux.org/index.php?title=User_talk:Edh&diff=483390User talk:Edh2017-07-30T10:58:06Z<p>Kay94: /* sudo/visudo */ correct mistake in formatting</p>
<hr />
<div>{| style="border:1px solid #8888aa; background-color:#f7f8ff; padding:5px; font-size:95%;" align=center width=90% id=toc0<br />
|align="center" rowspan="2"| <br />
<font face="Times New Roman, serif" color="#000080" size="+2">W<small>ELCOME TO MY TALK PAGE!</small></font><br><small> <span class="plainlinks">'''[{{fullurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit&section=new}} <span style="color: #002BB8;">Leave me a message</span>]</span>''' · '''[[Wikipedia:Signatures|Please sign and date your posts]] by typing four tildes (<code><nowiki>~~~~</nowiki></code>).'''</small><br />
|}<br />
<br />
== sudo/visudo ==<br />
Hi,<br />
I saw your edit in sudo. How about pointing out the command "EDITOR=nano visudo" has to be run as root in the text (not in the code as I did), just with a "(as root)"? Maybe I'm stupid, but believe me, I was literally sitting at my computer half an our to make the given code somehow run with different approaches with sudo, which all didn't work and I so far have never read that '#' is meaning root. I mean, of course I believe you in that, it's just sometimes hard to get to know those small facts as a newbie when reading a wiki article. :) Regards<br />
[[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:11, 29 July 2017 (UTC)kay94<br />
<br />
: It is quite common for shell documentation to follow this schema of prefixing root commands with {{ic|#}} and the standard user prompt with {{ic|$}}. I do admit that this might be hard to even notice at first. However the warning message when running a root command as non-root user is usually very revealing. In the discussed case the error message should yield something similar to "''visudo: /etc/sudoers: '''Permission''' denied''" which should already have given you the hint to check whether you do run this as the 'correct' user.<br />
<br />
: I am sorry to hear that this worsen your experience setting up [[sudo]]. However I still think it is better to not specifically mention the user under which the command is supposed to run. The core question becomes why would it be necessary to state it here and not elsewhere? Clearly it nonsensical to specify it every time. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:11, 29 July 2017 (UTC)<br />
<br />
: I guess it will not help you much now, but just for completeness sake: Here is a link to the corresponding section of the [[Help:Style#Command line text|command formatting article]] in the ArchWiki. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:32, 29 July 2017 (UTC)<br />
<br />
::Thanks Edh, if I can step in quickly, I suggest Kay94 to read [[Help:Reading#Regular user or root]] and the rest of that article :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:45, 30 July 2017 (UTC)<br />
<br />
::: Hi, thank you very much for your reactions! I can see your points. Anyway, in this particular case, I think it might be helpful to specify "(as root)" additionally, because when I do "$ EDITOR=nano visudo" of course it tells me about missing privileges. So I did "$ EDITOR=nano sudo visudo" and "$ EDITOR=nano" "$ sudo visudo", which both didn't work, I ended up in vi both times (VISUAL is set to nano, too, btw). Sure I missunderstand something there about proper usage of visudo, but I think this will happen to other people too. Regards -- [[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:58, 30 July 2017 (UTC) kay94<br />
<br />
== <s>Update reference to libinput-gestures</s> ==<br />
<br />
Hi,<br />
<br />
I see you added your libinput-gestures-git to the Arch Wiki page on libinput. Do you mind if I update that to to point to libinput-gestures?<br />
<br />
[[User:Bulletmark|Bulletmark]] ([[User talk:Bulletmark|talk]]) 00:23, 19 August 2016 (UTC)<br />
<br />
: Sure, go ahead. It is always preferred to point to the stable release. I edited the wiki prior to the creation of your package. It was was not meant to be permanent. Though obviously your package deserves the spotlight here, it is very kind of you to ask. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 07:02, 19 August 2016 (UTC)</div>Kay94https://wiki.archlinux.org/index.php?title=User_talk:Edh&diff=483389User talk:Edh2017-07-30T10:57:10Z<p>Kay94: /* sudo/visudo */ reaction</p>
<hr />
<div>{| style="border:1px solid #8888aa; background-color:#f7f8ff; padding:5px; font-size:95%;" align=center width=90% id=toc0<br />
|align="center" rowspan="2"| <br />
<font face="Times New Roman, serif" color="#000080" size="+2">W<small>ELCOME TO MY TALK PAGE!</small></font><br><small> <span class="plainlinks">'''[{{fullurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit&section=new}} <span style="color: #002BB8;">Leave me a message</span>]</span>''' · '''[[Wikipedia:Signatures|Please sign and date your posts]] by typing four tildes (<code><nowiki>~~~~</nowiki></code>).'''</small><br />
|}<br />
<br />
== sudo/visudo ==<br />
Hi,<br />
I saw your edit in sudo. How about pointing out the command "EDITOR=nano visudo" has to be run as root in the text (not in the code as I did), just with a "(as root)"? Maybe I'm stupid, but believe me, I was literally sitting at my computer half an our to make the given code somehow run with different approaches with sudo, which all didn't work and I so far have never read that '#' is meaning root. I mean, of course I believe you in that, it's just sometimes hard to get to know those small facts as a newbie when reading a wiki article. :) Regards<br />
[[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:11, 29 July 2017 (UTC)kay94<br />
<br />
: It is quite common for shell documentation to follow this schema of prefixing root commands with {{ic|#}} and the standard user prompt with {{ic|$}}. I do admit that this might be hard to even notice at first. However the warning message when running a root command as non-root user is usually very revealing. In the discussed case the error message should yield something similar to "''visudo: /etc/sudoers: '''Permission''' denied''" which should already have given you the hint to check whether you do run this as the 'correct' user.<br />
<br />
: I am sorry to hear that this worsen your experience setting up [[sudo]]. However I still think it is better to not specifically mention the user under which the command is supposed to run. The core question becomes why would it be necessary to state it here and not elsewhere? Clearly it nonsensical to specify it every time. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:11, 29 July 2017 (UTC)<br />
<br />
: I guess it will not help you much now, but just for completeness sake: Here is a link to the corresponding section of the [[Help:Style#Command line text|command formatting article]] in the ArchWiki. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:32, 29 July 2017 (UTC)<br />
<br />
::Thanks Edh, if I can step in quickly, I suggest Kay94 to read [[Help:Reading#Regular user or root]] and the rest of that article :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:45, 30 July 2017 (UTC)<br />
<br />
::: Hi, thank you very much for your reactions! I can see your points. Anyway, in this particular case, I think it might be helpful to specify "(as root)" additionally, because when I do "$ EDITOR=nano visudo" of course it tells me about missing privileges. So I did "$ EDITOR=nano sudo visudo" and "$ EDITOR=nano" "$ sudo visudo", which both didn't work, I ended up in vi both times (VISUAL is set to nano, too, btw). Sure I missunderstand something there about proper usage of visudo, but I think this will happen to other people too. Regards<br />
[[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:57, 30 July 2017 (UTC) kay94<br />
<br />
== <s>Update reference to libinput-gestures</s> ==<br />
<br />
Hi,<br />
<br />
I see you added your libinput-gestures-git to the Arch Wiki page on libinput. Do you mind if I update that to to point to libinput-gestures?<br />
<br />
[[User:Bulletmark|Bulletmark]] ([[User talk:Bulletmark|talk]]) 00:23, 19 August 2016 (UTC)<br />
<br />
: Sure, go ahead. It is always preferred to point to the stable release. I edited the wiki prior to the creation of your package. It was was not meant to be permanent. Though obviously your package deserves the spotlight here, it is very kind of you to ask. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 07:02, 19 August 2016 (UTC)</div>Kay94https://wiki.archlinux.org/index.php?title=User_talk:Edh&diff=483146User talk:Edh2017-07-29T10:11:30Z<p>Kay94: /* Update reference to libinput-gestures */ new topic "sudo/visudo"</p>
<hr />
<div>{| style="border:1px solid #8888aa; background-color:#f7f8ff; padding:5px; font-size:95%;" align=center width=90% id=toc0<br />
|align="center" rowspan="2"| <br />
<font face="Times New Roman, serif" color="#000080" size="+2">W<small>ELCOME TO MY TALK PAGE!</small></font><br><small> <span class="plainlinks">'''[{{fullurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit&section=new}} <span style="color: #002BB8;">Leave me a message</span>]</span>''' · '''[[Wikipedia:Signatures|Please sign and date your posts]] by typing four tildes (<code><nowiki>~~~~</nowiki></code>).'''</small><br />
|}<br />
<br />
== sudo/visudo ==<br />
Hi,<br />
I saw your edit in sudo. How about pointing out the command "EDITOR=nano visudo" has to be run as root in the text (not in the code as I did), just with a "(as root)"? Maybe I'm stupid, but believe me, I was literally sitting at my computer half an our to make the given code somehow run with different approaches with sudo, which all didn't work and I so far have never read that '#' is meaning root. I mean, of course I believe you in that, it's just sometimes hard to get to know those small facts as a newbie when reading a wiki article. :) Regards<br />
[[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 10:11, 29 July 2017 (UTC)kay94<br />
<br />
== <s>Update reference to libinput-gestures</s> ==<br />
<br />
Hi,<br />
<br />
I see you added your libinput-gestures-git to the Arch Wiki page on libinput. Do you mind if I update that to to point to libinput-gestures?<br />
<br />
[[User:Bulletmark|Bulletmark]] ([[User talk:Bulletmark|talk]]) 00:23, 19 August 2016 (UTC)<br />
<br />
: Sure, go ahead. It is always preferred to point to the stable release. I edited the wiki prior to the creation of your package. It was was not meant to be permanent. Though obviously your package deserves the spotlight here, it is very kind of you to ask. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 07:02, 19 August 2016 (UTC)</div>Kay94https://wiki.archlinux.org/index.php?title=Frequently_asked_questions&diff=483069Frequently asked questions2017-07-28T16:12:21Z<p>Kay94: /* Why would I not want to use Arch? */ Added link to ArchLinuxARM main page</p>
<hr />
<div>[[Category:About Arch]]<br />
[[ar:Frequently asked questions]]<br />
[[bg:Frequently asked questions]]<br />
[[cs:Frequently asked questions]]<br />
[[da:Frequently asked questions]]<br />
[[de:FAQ]]<br />
[[el:Frequently asked questions]]<br />
[[es:Frequently asked questions]]<br />
[[fa:سؤالات متداول]]<br />
[[fi:FAQ]]<br />
[[fr:FAQ]]<br />
[[hr:Frequently asked questions]]<br />
[[id:Frequently asked questions]]<br />
[[it:Frequently asked questions]]<br />
[[ja:FAQ]]<br />
[[ko:Frequently asked questions]]<br />
[[lt:Frequently asked questions]]<br />
[[nl:Frequently asked questions]]<br />
[[pt:Frequently asked questions]]<br />
[[ro:Întrebări frecvente]]<br />
[[ru:Frequently asked questions]]<br />
[[sk:Frequently asked questions]]<br />
[[sv:FAQ]]<br />
[[th:Frequently asked questions]]<br />
[[tr:Sss]]<br />
[[zh-hans:Frequently asked questions]]<br />
[[zh-hant:Frequently asked questions]]<br />
{{Related articles start}}<br />
{{Related|Arch terminology}}<br />
{{Related|Arch User Repository#FAQ}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
<br />
== General ==<br />
<br />
=== What is Arch Linux?===<br />
<br />
See the [[Arch Linux]] article.<br />
<br />
=== Why would I not want to use Arch?===<br />
<br />
You may '''not''' want to use Arch, if:<br />
<br />
* you do not have the ability/time/desire for a 'do-it-yourself' GNU/Linux distribution.<br />
* you require support for an architecture other than x86_64 (for ARM see: [https://archlinuxarm.org/ ArchLinuxARM]).<br />
* you take a strong stand on using a distribution which only provides free software as defined by GNU.<br />
* you believe an operating system should configure itself, run out of the box, and include a complete default set of software and desktop environment on the installation media.<br />
* you do not want a rolling release GNU/Linux distribution.<br />
* you are happy with your current OS.<br />
<br />
=== What architectures does Arch support?===<br />
<br />
Arch only supports the x86_64 (sometimes called amd64) architecture. Support for i686 is being phased out and will be completely dropped in November 2017[https://www.archlinux.org/news/phasing-out-i686-support/]: if you are still running a 32-bit system you may be interested in reading [[#Can I switch from i686 to x86_64 without reinstalling?]].<br />
<br />
=== Does Arch support ARM CPUs? ===<br />
<br />
No, but the [http://archlinuxarm.org/ Arch Linux ARM] project provides a port of Arch Linux to several ARM platforms. See [http://ix.io/73w/irc].<br />
<br />
=== Does Arch follow the [http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html FHS]? ===<br />
<br />
Arch Linux follows the ''file system hierarchy'' for operating systems using the [[systemd]] service manager. See {{man|7|file-hierarchy}} for an explanation of each directory along with their designations. In particular, {{ic|/bin}}, {{ic|/sbin}}, and {{ic|/usr/sbin}} are symbolic links to {{ic|/usr/bin}}, and {{ic|/lib}} (and {{ic|/lib64}} if applicable) are symbolic links to {{ic|/usr/lib}}.<br />
<br />
=== I am a complete GNU/Linux beginner. Should I use Arch?===<br />
<br />
If you are a beginner and want to use Arch, you must be willing to invest time into learning a new system, and accept that Arch is designed as a DIY (Do-It-Yourself) distribution; it is the user who assembles the system.<br />
<br />
Before asking for help, do your own independent research by Googling, searching the forum and the superb documentation provided by the Arch Wiki. ''There is a reason these resources were made available to you in the first place.'' Many thousands of ''volunteered'' hours have been spent compiling this excellent information.<br />
<br />
See also [[Arch terminology#RTFM]] and the [[Installation guide]].<br />
<br />
=== Is Arch designed to be used as a server? A desktop? A workstation?===<br />
<br />
Arch is not designed for any particular type of use. Rather, it is designed for a particular type of ''user''. Arch targets competent users who enjoy its do-it-yourself nature, and who further exploit it to shape the system to fit their unique needs. Therefore, in the hands of its target user base, Arch can be used for virtually any purpose. Many use Arch on both their desktops and workstations. And of course, archlinux.org runs on Arch.<br />
<br />
=== I really like Arch, except the development team needs to implement feature X===<br />
<br />
Get involved, contribute your code/solution to the community. If it is well regarded by the community and development team, perhaps it will be merged. The Arch community thrives on contribution and sharing of code and tools.<br />
<br />
=== When will the new release be made available?===<br />
<br />
Arch Linux releases are simply a live environment for installation or rescue, which include the {{grp|base}} group and a few [https://projects.archlinux.org/archiso.git/tree/configs/releng/packages.both other packages]. The releases are issued usually in the first half of every month.<br />
<br />
=== Is Arch Linux a stable distribution? Will I get frequent breakage?===<br />
<br />
It is ''the user'' who is ultimately responsible for the stability of his own rolling release system. The user decides when to upgrade, and merges necessary changes when required. If the user reaches out to the community for help, it is often provided in a timely manner. The difference between Arch and other distributions in this regard is that Arch is truly a 'do-it-yourself' distribution; complaints of breakage are misguided and unproductive, since upstream changes are not the responsibility of Arch devs.<br />
<br />
See the [[System maintenance]] article for tips on how to make an Arch Linux system as stable as possible.<br />
<br />
=== Arch needs more press (i.e. advertisement)===<br />
<br />
Arch gets plenty of press as it is. The goal of Arch Linux is not to be large; rather, organic, sustainable growth occurs naturally amongst the target user base.<br />
<br />
=== Arch needs more developers===<br />
<br />
Possibly so. Feel free to volunteer your time! Visit the [https://bbs.archlinux.org forums], [[IRC channels]], and [https://mailman.archlinux.org/mailman/listinfo/ mailing lists], and see what needs to be done. Getting involved in the Community Contributions subforum is a good way to start.<br />
<br />
=== Why is my internet so slow compared to other operating systems?===<br />
<br />
Is your network configured correctly? Have a look at the [[Network configuration]] article.<br />
<br />
Also note that Arch Linux does not come with [[Wikipedia:Traffic shaping|traffic shaping]] enabled. Thus, it is possible that if a program on it somehow utilizes your internet connection to the full – regardless if it's over P2P or classic client-server connections – other local ones will find it clogged, resulting in severe lags and timeouts. Relief can be provided by [[firewalls]] such as Shorewall or Vuurmuur; there are also static scripts for {{Pkg|iproute2}} (such as [http://serendipity.ruwenzori.net/index.php/2008/06/01/modified-wondershaper-for-better-voip-qos this derivative] of Wondershaper), which allow shaping on the network layer.<br />
<br />
=== Why is Arch using all my RAM?===<br />
<br />
Essentially, unused RAM is wasted RAM.<br />
<br />
Many new users notice how the Linux kernel handles memory differently than they are used to. Since accessing data from RAM is much faster than from a storage drive, the kernel caches recently accessed data in memory. The cached data is only cleared when the system begins to run out of available memory and new data needs to be loaded.<br />
<br />
We could distinguish the difference from {{ic|free}} command:<br />
<br />
{{hc|$ free -h|<br />
total used free shared buff/cache available<br />
Mem: 2.8G 1.1G 283M 224M 1.4G 1.2G<br />
Swap: 3.0G 881M 2.1G<br />
}}<br />
<br />
It is important to note the difference between "free" and "available" memory. In the above example, a laptop with 2.8G of total RAM appears to be using most of it, with only 283M as free memory. However, 1.4G of it is "buff/cache". There is still 1.2G available for starting new applications, without swapping. See {{ic|man free(1)}} for detail. The result of all this? Performance!<br />
<br />
See [http://www.linuxjournal.com/article/2770 this wonderful article] if your curiosity has been piqued! There's also a website dedicated to clearing this confusion: http://www.linuxatemyram.com/<br />
<br />
=== Where did all my free space go?===<br />
<br />
The answer to this question depends on your system. There are some [[List of applications#Disk usage display|fine utilities]] that may help you find the answer.<br />
<br />
== Package management ==<br />
<br />
See the [[pacman]], [[pacman/Tips and tricks]] and [[Official repositories]] pages for more answers.<br />
<br />
=== I've found an error with Package X. What should I do?===<br />
First, you need to figure out if this error is something the Arch team can fix. Sometimes it's not (e.g. Firefox crashes may be the fault of the Mozilla team); this is called an ''upstream error''. If it is an Arch problem, there is a series of steps you can take:<br />
<br />
# Search the forums for information. See if anyone else has noticed it.<br />
# Post a [[bug report]] with detailed information at https://bugs.archlinux.org.<br />
# If you'd like, write a forum post detailing the problem and the fact that you have reported it already. This will help prevent a lot of people from reporting the same error.<br />
<br />
=== Arch packages need to use a unique naming convention. ".pkg.tar.gz" and ".pkg.tar.xz" are too long and/or confusing===<br />
This has been discussed on the Arch mailing list. Some proposed a {{ic|.pac}} file extension. As far as is currently known, there is no plan to change the package extension. As Tobias Kieslich, one of the Arch devs, put it, "''A package '''is''' a gzipped'' [xz] ''tarball! And it can be opened, investigated and manipulated by any tar-capable application. Moreover, the mime-type is automatically detected correctly by most applications.''"<br />
<br />
=== Pacman needs a library so other applications can easily access package information===<br />
Pacman is a front-end to [https://www.archlinux.org/pacman/libalpm.3.html libalpm]—the "Arch Linux Package Management" library—which allows alternative front-ends, like a GUI front-end, to be written.<br />
<br />
=== Pacman needs feature X!===<br />
<br />
If you think an idea has merit, you may choose to discuss it on [https://lists.archlinux.org//listinfo/pacman-dev/ pacman-dev]. Also check https://bugs.archlinux.org for existing feature requests.<br />
<br />
However, the best way to get a feature added to pacman or Arch Linux is to implement it yourself. The patch or code may or may not be officially accepted, but perhaps others will appreciate, test and contribute to your effort.<br />
<br />
=== I just installed Package X. How do I start it?===<br />
If you're using a desktop environment like [[KDE]] or [[GNOME]], the program should automatically show up in your menu. If you're trying to run the program from a terminal and do not know the binary name, use:<br />
<br />
$ pacman -Qlq ''package_name'' | grep /usr/bin/<br />
<br />
=== Why is there only a single version of each shared library in the official repositories?===<br />
<br />
Several distributions, such as Debian, have different versions of shared libraries packaged as different packages: {{ic|libfoo1}}, {{ic|libfoo2}}, {{ic|libfoo3}} and so on. In this way it is possible to have applications compiled against different versions of {{ic|libfoo}} installed on the same system.<br />
<br />
In case of a distribution like Arch, only the latest stable versions of packages are officially supported. By dropping support for outdated software, package maintainers are able to spend more time ensuring that the newest versions work as expected. As soon as a new version of a shared library becomes available from upstream, it is added to the repositories and affected packages are rebuilt to use the new version.<br />
<br />
=== What if I run a full system upgrade and there will be an update for a shared library, but not for the apps that depend on it?===<br />
This scenario should not happen at all. Assuming an application called {{ic|foobaz}} is in one of the official repositories and builds successfully against a new version of a shared library called {{ic|libbaz}}, it will be updated along with {{ic|libbaz}}. If, however, it doesn't build successfully, {{ic|foobaz}} package will have a versioned dependency (e.g. ''libbaz 1.5''), and will be removed by pacman during {{ic|libbaz}} upgrade, due to a conflict.<br />
<br />
If {{ic|foobaz}} is a package that you built yourself and installed from AUR, you should try rebuilding {{ic|foobaz}} against the new version of {{ic|libbaz}}. If the build fails, report the bug to the {{ic|foobaz}} developers.<br />
<br />
=== Is it possible that there's a major kernel update in the repository, and that some of the driver packages haven't been updated?===<br />
No, it is not possible. Major kernel updates (e.g. ''linux 3.5.0-1'' to ''linux 3.6.0-1'') are always accompanied by rebuilds of all supported kernel driver packages. On the other hand, if you have an unsupported driver package installed on your system, such as {{AUR|catalyst}}, then a kernel update might break things for you if you do not rebuild it for the new kernel. Users are responsible for updating any unsupported driver packages that they have installed.<br />
<br />
=== What to do before upgrading?===<br />
<br />
Follow the [[System maintenance#Upgrading the system]] section.<br />
<br />
=== A package update was released, but pacman says the system is up to date ===<br />
<br />
''pacman'' mirrors are not synced immediately. It may take over 24 hours before an update is available to you. The only options are be patient or use another mirror. [https://www.archlinux.org/mirrors/status/ MirrorStatus] can help you identify an up-to-date mirror.<br />
<br />
=== Upstream project ''X'' has released a new version. How long will it take for the Arch package to update to that new version? ===<br />
<br />
Package updates will be released when they are ready. The specifc amount of time can be as short as a few hours after upstream releases a minor bugfix update to as long as several weeks after a large package group's major update. The amount of time from an upstream's new version to Arch releasing a new package depends on the specific packages and the availability of the package maintainers. Additionally, some packages spend some time in the [[testing]] repository, so this can prolong the time before a package is updated. [[Package maintainer]]s attempt to work quickly to bring stable updates to the repositories. If you find a package in the official repositories that is out of date, go to that package's page at the [https://www.archlinux.org/packages/ package website] and flag it.<br />
<br />
== Installation ==<br />
<br />
=== Arch needs an installer. Maybe a GUI installer?===<br />
Since installation doesn't occur often (read the rest of this article to know more about what ''rolling release'' means), it is not a high priority for developers or users. The [[Installation guide]] has been fully updated to use the command-line method. If you're still interested in using an installer, consider using [[Archboot]].<br />
<br />
=== I installed Arch, and now I am at a shell! What now?===<br />
<br />
See [[General recommendations]].<br />
<br />
=== Which desktop environment or window manager should I use?===<br />
Since many are available to you, use the one you like the most to fit your needs. Have a look at the [[Desktop environment]] and [[Window manager]] articles.<br />
<br />
=== What makes Arch unique amongst other "minimal" distributions?===<br />
<br />
See [[Arch compared to other distributions]].<br />
<br />
== 64-bit ==<br />
<br />
=== How do I determine if my processor is x86_64 compatible? ===<br />
<br />
If your processor is [[wikipedia:X86-64|x86_64]] compatible, you will have the {{ic|lm}} flag in {{ic|/proc/cpuinfo}}. For example,<br />
<br />
$ grep -w lm /proc/cpuinfo<br />
<br />
Under Windows, using the freeware [http://www.cpuid.com/cpuz.php CPU-Z] helps determine whether your CPU is 64-bit compatible.<br />
CPUs with AMD's instruction set "AMD64" or Intel's solution "EM64T" should be compatible with the x86_64 releases and binary packages.<br />
<br />
=== Why 64-bit? ===<br />
<br />
It is faster under most circumstances and as an added bonus also inherently more secure due to the nature of [[wikipedia:Address space layout randomization|Address space layout randomization (ASLR)]] in combination with [[wikipedia:Position-independent code|Position-independent code (PIC)]] and the [[wikipedia:NX Bit|NX Bit]] which is not available in the stock i686 kernel due to disabled PAE. If your computer has more than 4GB of RAM, only a 64-bit OS will be able to fully utilize it.<br />
<br />
Programmers also increasingly tend to care less about 32-bit ("legacy") as "new" x86 CPUs typically support the 64-bit extensions.<br />
<br />
There are many more reasons we could list here to tell you to avoid 32-bit, but between the kernel, userspace and individual programs it is simply not viable to list every last thing that 64-bit does much better these days.<br />
<br />
=== Can I switch from i686 to x86_64 without reinstalling? ===<br />
<br />
No. All packages need to be reinstalled for the new architecture and configuration changes may be necessary. However, you do not need to repartition or reformat your hard drives during installation, so it is possible to migrate all of your old data. A forum thread has been created [https://bbs.archlinux.org/viewtopic.php?id=64485 here] which outlines steps taken to migrate an install from 32 to 64 bit without losing any configurations/settings/data using a large external hard drive.<br />
<br />
However, you can also start the system with the 64-bit installation ISO, mount the disk, backup anything you may want to keep that is not a 32-bit binary (e.g: {{ic|/home}} & {{ic|/etc}}), and install.<br />
<br />
You may also want to read about [[migrating between architectures]].</div>Kay94https://wiki.archlinux.org/index.php?title=Sudo&diff=483068Sudo2017-07-28T16:09:09Z<p>Kay94: /* Using visudo */ Added alternative way to edit sudoers with any editor and check with visudo afterwards</p>
<hr />
<div>[[Category:Security]]<br />
[[fa:sudo]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-hans:Sudo]]<br />
{{Related articles start}}<br />
{{Related|Users and groups}}<br />
{{Related|su}}<br />
{{Related articles end}}<br />
<br />
[https://www.sudo.ws/sudo/ sudo] allows a system administrator to delegate authority to give certain users—or groups of users—the ability to run commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelihood that a typo or a bug in an invoked command will ruin the system.<br />
<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|sudo}} package.<br />
<br />
== Usage ==<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. See [[#Configuration]].<br />
<br />
To use ''sudo'', simply prefix a command and its arguments with {{ic|sudo}} and a space:<br />
<br />
$ sudo ''cmd''<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See {{man|8|sudo|url=https://www.sudo.ws/man/sudo.man.html}} for more information.<br />
<br />
== Configuration ==<br />
<br />
{{Expansion|Move [[#Defaults skeleton]] here, and create an intro discussing {{ic|Defaults}}, perhaps with a table that lists common settings}}<br />
<br />
See {{man|5|sudoers|url=https://www.sudo.ws/man/sudoers.man.html}} for more information, such as configuring the password timeout.<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration, or {{ic|sudo -lU ''user''}} for a specific user.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|<br />
* It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.<br />
* From {{man|8|visudo|url=https://www.sudo.ws/man/visudo.man.html}}: ''Note that this can be a security hole since it allows the user to execute any program they wish simply by setting VISUAL or EDITOR.''<br />
}}<br />
<br />
The default editor for visudo is {{ic|vi}}. sudo from the core repository is compiled with {{Ic|--with-env-editor}} by default and honors the use of the {{Ic|VISUAL}} and {{Ic|EDITOR}} variables. {{ic|EDITOR}} is not used when {{ic|VISUAL}} is set.<br />
<br />
To establish nano as temporary '''visudo''' editor, do the following depending on the current user:<br />
<br />
# EDITOR=nano visudo # as root<br />
# sudo sh -c "EDITOR=nano visudo" # as non-root<br />
<br />
If a lock is not neccessary because nobody else might be editing it, you can alternatively edit a copy of {{ic|/etc/sudoers}} (with any editor of choice) and check it with '''visudo''' before finally replacing the original {{ic|/etc/sudoers}}, like so (as root):<br />
<br />
# cp /etc/sudoers /etc/sudoers.new<br />
# nano /etc/sudoers.new<br />
# visudo -c -f /etc/sudoers.new<br />
/etc/sudoers.new: parsed OK<br />
# mv /etc/sudoers.new /etc/sudoers<br />
<br />
To change the editor permanently, see [[Environment variables#Per user]]. To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following to {{ic|/etc/sudoers}} (assuming {{ic|nano}} is your preferred editor):<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname {{ic|HOST_NAME}}:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user {{ic|USER_NAME}}:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user {{ic|USER_NAME}} on host {{ic|HOST_NAME}}:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user {{ic|USER_NAME}} on host {{ic|HOST_NAME}} without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed {{ic|sudoers}} example is available at {{ic|/usr/share/doc/sudo/examples/sudoers}}. Otherwise, see the {{man|5|sudoers|url=https://www.sudo.ws/man/sudoers.man.html}} for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the {{ic|sudoers}} file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
== Tips and tricks ==<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding {{ic|targetpw}} (target user, defaults to root) or {{ic|rootpw}} to the Defaults line in {{ic|/etc/sudoers}}:<br />
Defaults targetpw<br />
<br />
To prevent exposing your root password to users, you can restrict this to a specific group:<br />
Defaults:%wheel targetpw<br />
%wheel ALL=(ALL) ALL<br />
<br />
=== Disable root login ===<br />
<br />
Users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password. See for example [[Ssh#Deny]].<br />
<br />
{{Warning|<br />
* Be careful, you may lock yourself out by disabling root login. Sudo is not automatically installed and its default configuration allows neither passwordless root access nor root access with your own password. Ensure a user is properly configured as a sudoer ''before'' disabling the root account!<br />
* If you have changed your sudoers -file to use rootpw as default, then do not disable root login with any of the following commands!<br />
* If you are already locked out, see [[Password recovery]] for help.}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
{{Tip|To get to an interactive root prompt, even after disabling the ''root'' account, use {{ic|sudo -i}}.}}<br />
<br />
==== gksu ====<br />
<br />
To set ''gksu'' to use sudo by default, run:<br />
<br />
$ gconftool-2 --set --type boolean /apps/gksu/sudo-mode true<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.config/kdesurc}} (or {{ic|~/.kde4/share/config/kdesurc}} for the kde4 version of kdesu):<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
or use the following command (use ''kwriteconfig'' for the kde4 version of kdesu):<br />
<br />
$ kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command sudo<br />
<br />
Alternatively, install {{AUR|kdesudo}}, which has the added advantage of tab-completion for the command following.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Let us say you create 3 users: admin, devel, and joe. The user "admin" is used for journalctl, systemctl, mount, kill, and iptables; "devel" is used for installing packages, and editing config files; and "joe" is the user you log in with. To let "joe" reboot, shutdown, and use netctl we would do the following:<br />
<br />
Edit {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-1}}<br />
Require user be in the wheel group, but do not put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group. Only "joe" will be part of this group.<br />
groupadd -r ssh<br />
gpasswd -a joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
<br />
[[Restart]] {{ic|sshd.service}}.<br />
<br />
Add users to other groups.<br />
for g in power network ;do ;gpasswd -a joe $g ;done<br />
for g in network power storage ;do ;gpasswd -a admin $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias STORAGE = /usr/bin/mount -o nosuid\,nodev\,noexec, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables, /usr/bin/ip6tables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%storage ALL = (root) STORAGE<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SHELL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
"Joe" can connect to his home WiFi.<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
"Joe" can not use netctl as any other user.<br />
sudo -u admin -- netctl start home<br />
<br />
When "joe" needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But "joe" cannot switch to the root user.<br />
sudo -i -u root<br />
<br />
If "joe" want to start a gnu-screen session as admin he can do it like this:<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
=== Configure sudo using drop-in files in /etc/sudoers.d ===<br />
<br />
''sudo'' parses files contained in the directory {{ic|/etc/sudoers.d/}}. This means that instead of editing {{ic|/etc/sudoers}}, you can change settings in standalone files and drop them in that directory. This has two advantages:<br />
<br />
* There is no need to edit a {{ic|sudoers.pacnew}} file;<br />
* If there is a problem with a new entry, you can remove the offending file instead of editing {{ic|/etc/sudoers}} (but see the warning below).<br />
<br />
The format for entries in these drop-in files is the same as for {{ic|/etc/sudoers}} itself. To edit them directly, use {{ic|visudo -f /etc/sudoers.d/''somefile''}}. See the "Including other files from within sudoers" section of {{man|5|sudoers|url=https://www.sudo.ws/man/sudoers.man.html}} for details.<br />
<br />
The files in {{ic|/etc/sudoers.d/}} directory are parsed in lexicographical order, file names containing {{ic|.}} or {{ic|~}} are skipped. To avoid sorting problems, the file names should begin with two digits, e.g. {{ic|01_foo}}.<br />
<br />
{{Note|The order of entries in the drop-in files is important: make sure that the statements do not override themselves.}}<br />
<br />
{{Warning|The files in {{ic|/etc/sudoers.d/}} are just as fragile as {{ic|/etc/sudoers}} itself: any improperly formatted file will prevent {{ic|sudo}} from working. Hence, for the same reason it is strongly advised to use {{ic|visudo}}}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Problems ===<br />
<br />
{{Merge|#Configuration}}<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Permissive umask ===<br />
<br />
{{Merge|#Configuration}}<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
=== Defaults skeleton ===<br />
<br />
{{Merge|#Configuration}}<br />
<br />
The authors site has a [http://www.sudo.ws/sudo/sudoers.man.html#x5355444f455253204f5054494f4e53 list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
See [https://gist.github.com/AladW/7eca9799b9ea624eca31] for a list of options (parsed from the version 1.8.7 source code) in a format optimized for {{ic|sudoers}}.</div>Kay94https://wiki.archlinux.org/index.php?title=Sudo&diff=483067Sudo2017-07-28T15:51:34Z<p>Kay94: /* Using visudo */ My sudoers is still default an the described commands to run visudo with nano only worked for root, which isn't clear. I thereby changed the description and added the commands that worked for me.</p>
<hr />
<div>[[Category:Security]]<br />
[[fa:sudo]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-hans:Sudo]]<br />
{{Related articles start}}<br />
{{Related|Users and groups}}<br />
{{Related|su}}<br />
{{Related articles end}}<br />
<br />
[https://www.sudo.ws/sudo/ sudo] allows a system administrator to delegate authority to give certain users—or groups of users—the ability to run commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelihood that a typo or a bug in an invoked command will ruin the system.<br />
<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|sudo}} package.<br />
<br />
== Usage ==<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. See [[#Configuration]].<br />
<br />
To use ''sudo'', simply prefix a command and its arguments with {{ic|sudo}} and a space:<br />
<br />
$ sudo ''cmd''<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See {{man|8|sudo|url=https://www.sudo.ws/man/sudo.man.html}} for more information.<br />
<br />
== Configuration ==<br />
<br />
{{Expansion|Move [[#Defaults skeleton]] here, and create an intro discussing {{ic|Defaults}}, perhaps with a table that lists common settings}}<br />
<br />
See {{man|5|sudoers|url=https://www.sudo.ws/man/sudoers.man.html}} for more information, such as configuring the password timeout.<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration, or {{ic|sudo -lU ''user''}} for a specific user.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|<br />
* It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.<br />
* From {{man|8|visudo|url=https://www.sudo.ws/man/visudo.man.html}}: ''Note that this can be a security hole since it allows the user to execute any program they wish simply by setting VISUAL or EDITOR.''<br />
}}<br />
<br />
The default editor for visudo is {{ic|vi}}. sudo from the core repository is compiled with {{Ic|--with-env-editor}} by default and honors the use of the {{Ic|VISUAL}} and {{Ic|EDITOR}} variables. {{ic|EDITOR}} is not used when {{ic|VISUAL}} is set.<br />
<br />
To establish nano as temporary '''visudo''' editor, do the following depending on the current user:<br />
<br />
# EDITOR=nano visudo # as root<br />
# sudo sh -c "EDITOR=nano visudo" # as non-root<br />
<br />
To change the editor permanently, see [[Environment variables#Per user]]. To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following to {{ic|/etc/sudoers}} (assuming {{ic|nano}} is your preferred editor):<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname {{ic|HOST_NAME}}:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user {{ic|USER_NAME}}:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user {{ic|USER_NAME}} on host {{ic|HOST_NAME}}:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user {{ic|USER_NAME}} on host {{ic|HOST_NAME}} without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed {{ic|sudoers}} example is available at {{ic|/usr/share/doc/sudo/examples/sudoers}}. Otherwise, see the {{man|5|sudoers|url=https://www.sudo.ws/man/sudoers.man.html}} for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the {{ic|sudoers}} file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
== Tips and tricks ==<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding {{ic|targetpw}} (target user, defaults to root) or {{ic|rootpw}} to the Defaults line in {{ic|/etc/sudoers}}:<br />
Defaults targetpw<br />
<br />
To prevent exposing your root password to users, you can restrict this to a specific group:<br />
Defaults:%wheel targetpw<br />
%wheel ALL=(ALL) ALL<br />
<br />
=== Disable root login ===<br />
<br />
Users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password. See for example [[Ssh#Deny]].<br />
<br />
{{Warning|<br />
* Be careful, you may lock yourself out by disabling root login. Sudo is not automatically installed and its default configuration allows neither passwordless root access nor root access with your own password. Ensure a user is properly configured as a sudoer ''before'' disabling the root account!<br />
* If you have changed your sudoers -file to use rootpw as default, then do not disable root login with any of the following commands!<br />
* If you are already locked out, see [[Password recovery]] for help.}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
{{Tip|To get to an interactive root prompt, even after disabling the ''root'' account, use {{ic|sudo -i}}.}}<br />
<br />
==== gksu ====<br />
<br />
To set ''gksu'' to use sudo by default, run:<br />
<br />
$ gconftool-2 --set --type boolean /apps/gksu/sudo-mode true<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.config/kdesurc}} (or {{ic|~/.kde4/share/config/kdesurc}} for the kde4 version of kdesu):<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
or use the following command (use ''kwriteconfig'' for the kde4 version of kdesu):<br />
<br />
$ kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command sudo<br />
<br />
Alternatively, install {{AUR|kdesudo}}, which has the added advantage of tab-completion for the command following.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Let us say you create 3 users: admin, devel, and joe. The user "admin" is used for journalctl, systemctl, mount, kill, and iptables; "devel" is used for installing packages, and editing config files; and "joe" is the user you log in with. To let "joe" reboot, shutdown, and use netctl we would do the following:<br />
<br />
Edit {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-1}}<br />
Require user be in the wheel group, but do not put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group. Only "joe" will be part of this group.<br />
groupadd -r ssh<br />
gpasswd -a joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
<br />
[[Restart]] {{ic|sshd.service}}.<br />
<br />
Add users to other groups.<br />
for g in power network ;do ;gpasswd -a joe $g ;done<br />
for g in network power storage ;do ;gpasswd -a admin $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias STORAGE = /usr/bin/mount -o nosuid\,nodev\,noexec, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables, /usr/bin/ip6tables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%storage ALL = (root) STORAGE<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SHELL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
"Joe" can connect to his home WiFi.<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
"Joe" can not use netctl as any other user.<br />
sudo -u admin -- netctl start home<br />
<br />
When "joe" needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But "joe" cannot switch to the root user.<br />
sudo -i -u root<br />
<br />
If "joe" want to start a gnu-screen session as admin he can do it like this:<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
=== Configure sudo using drop-in files in /etc/sudoers.d ===<br />
<br />
''sudo'' parses files contained in the directory {{ic|/etc/sudoers.d/}}. This means that instead of editing {{ic|/etc/sudoers}}, you can change settings in standalone files and drop them in that directory. This has two advantages:<br />
<br />
* There is no need to edit a {{ic|sudoers.pacnew}} file;<br />
* If there is a problem with a new entry, you can remove the offending file instead of editing {{ic|/etc/sudoers}} (but see the warning below).<br />
<br />
The format for entries in these drop-in files is the same as for {{ic|/etc/sudoers}} itself. To edit them directly, use {{ic|visudo -f /etc/sudoers.d/''somefile''}}. See the "Including other files from within sudoers" section of {{man|5|sudoers|url=https://www.sudo.ws/man/sudoers.man.html}} for details.<br />
<br />
The files in {{ic|/etc/sudoers.d/}} directory are parsed in lexicographical order, file names containing {{ic|.}} or {{ic|~}} are skipped. To avoid sorting problems, the file names should begin with two digits, e.g. {{ic|01_foo}}.<br />
<br />
{{Note|The order of entries in the drop-in files is important: make sure that the statements do not override themselves.}}<br />
<br />
{{Warning|The files in {{ic|/etc/sudoers.d/}} are just as fragile as {{ic|/etc/sudoers}} itself: any improperly formatted file will prevent {{ic|sudo}} from working. Hence, for the same reason it is strongly advised to use {{ic|visudo}}}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Problems ===<br />
<br />
{{Merge|#Configuration}}<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Permissive umask ===<br />
<br />
{{Merge|#Configuration}}<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
=== Defaults skeleton ===<br />
<br />
{{Merge|#Configuration}}<br />
<br />
The authors site has a [http://www.sudo.ws/sudo/sudoers.man.html#x5355444f455253204f5054494f4e53 list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
See [https://gist.github.com/AladW/7eca9799b9ea624eca31] for a list of options (parsed from the version 1.8.7 source code) in a format optimized for {{ic|sudoers}}.</div>Kay94https://wiki.archlinux.org/index.php?title=Talk:Sudo&diff=483063Talk:Sudo2017-07-28T15:03:50Z<p>Kay94: </p>
<hr />
<div>Hi, in the section "Example entries" I stumbled over this sentence:<br />
"To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:"<br />
Is this intended to be saying "...on the machine...", like physically, not by ssh for example?<br />
Would be great to clarify this!<br />
[[User:Kay94|Kay94]] ([[User talk:Kay94|talk]]) 15:03, 28 July 2017 (UTC)kay94</div>Kay94