https://wiki.archlinux.org/api.php?action=feedcontributions&user=Madchine&feedformat=atomArchWiki - User contributions [en]2024-03-28T13:39:20ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=253029Beginners' guide2013-04-05T18:50:20Z<p>Madchine: /* Establish an internet connection */ give the command "ip addr show", don't just say "use ip"</p>
<hr />
<div><noinclude><br />
[[Category:Getting and installing Arch]]<br />
[[Category:About Arch]]<br />
[[da:Beginners' Guide/Installation]]<br />
[[es:Beginners' Guide/Installation]]<br />
[[hr:Beginners' Guide/Installation]]<br />
[[hu:Beginners' Guide/Installation]]<br />
[[it:Beginners' Guide/Installation]]<br />
[[ja:Beginners' Guide/Installation]]<br />
[[ko:Beginners' Guide/Installation]]<br />
[[nl:Beginners' Guide/Installatie]]<br />
[[pl:Beginners' Guide/Installation]]<br />
[[pt:Beginners' Guide/Installation]]<br />
[[ro:Ghidul începătorilor/Instalare]]<br />
[[ru:Beginners' Guide/Installation]]<br />
[[sr:Beginners' Guide/Installation]]<br />
[[zh-CN:Beginners' Guide/Installation]]<br />
[[zh-TW:Beginners' Guide/Installation]]<br />
{{Tip|This is part of a multi-page article for The Beginners' Guide. '''[[Beginners' Guide|Click here]]''' if you would rather read the guide in its entirety.}}<br />
</noinclude><br />
== Installation ==<br />
<br />
You are now presented with a shell prompt, automatically logged in as root.<br />
<br />
=== Change the language ===<br />
<br />
{{Tip|These are optional for the majority of users. Useful only if you plan on writing in your own language in any of the configuration files, if you use diacritical marks in the Wi-Fi password, or if you would like to receive system messages (e.g. possible errors) in your own language.}}<br />
<br />
By default, the keyboard layout is set to {{ic|us}}. If you have a non-[[Wikipedia:File:KB United States-NoAltGr.svg|US]] keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
...where ''layout'' can be {{ic|fr}}, {{ic|uk}}, {{ic|be-latin1}}, etc. See [[KEYMAP#Keyboard layouts|here]] for a comprehensive list.<br />
<br />
The font should also be changed, because most languages use more glyphs than the 26 letter [[Wikipedia:English alphabet|English alphabet]]. Otherwise some foreign characters may show up as white squares or as other symbols. Note that the name is case-sensitive, so please type it ''exactly'' as you see it:<br />
<br />
# setfont Lat2-Terminus16<br />
<br />
By default, the language is set to English (US). If you would like to change the language for the install process ''(German, in this example)'', remove the {{ic|#}} in front of the [http://www.greendesktiny.com/support/knowledgebase_detail.php?ref=EUH-483 locale] you want from {{ic|/etc/locale.gen}}, along with English (US). Please choose the {{ic|UTF-8}} entry.<br />
<br />
Use {{Keypress|Ctrl+X}} to exit, and when prompted to save changes, press {{Keypress|Y}} and {{Keypress|Enter}} to use the same filename.<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
en_US.UTF-8 UTF-8<br />
de_DE.UTF-8 UTF-8}}<br />
<br />
# locale-gen<br />
# export LANG=de_DE.UTF-8<br />
<br />
Remember, {{Keypress|LAlt+LShift}} activates and deactivates the keymap.<br />
<br />
=== Establish an internet connection ===<br />
<br />
{{Warning|udev no longer assigns network interface names according to the wlanX and ethX naming scheme. If you're coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named wlan0, or that your wired interface is named eth0. You can use the command "ip addr show" to discover the names of your interfaces.}}<br />
<br />
From systemd-197's release and onward, udev now assigns predictable, stable network interface names that deviate from the legacy incremental naming scheme (wlan0, wlan1, etc.). These interface names are guaranteed to be persistent across reboots, which solves the problem of the lack of predictability of network interface name assignment. For more information about why this was necessary, read http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames .<br />
<br />
The {{ic|dhcpcd}} network daemon is started automatically at boot and it will attempt to start a wired connection, if available. Try pinging a website to see if it was successful. And since Google is always on...<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is any problem with your cable (or if you have enough wireless signal), otherwise you will need to set up the network manually, as explained below.<br />
<br />
Otherwise, move on to [[#Prepare the storage drive|Prepare the storage drive]].<br />
<br />
==== Wired ====<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
First, identify the name of your Ethernet interface.<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff}}<br />
<br />
In this example, the Ethernet interface is {{ic|enp2s0f0}}. If you're unsure, your Ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w". You can also use {{ic|iwconfig}} and see which interfaces are not wireless:<br />
<br />
{{hc|# iwconfig|2=<br />
enp2s0f0 no wireless extensions.<br />
wlp3s0 IEEE 802.11bgn ESSID:"NETGEAR97"<br />
Mode:Managed Frequency:2.427 GHz Access Point: 2C:B0:5D:9C:72:BF<br />
Bit Rate=65 Mb/s Tx-Power=16 dBm<br />
Retry long limit:7 RTS thr:off Fragment thr:off<br />
Power Management:on<br />
Link Quality=61/70 Signal level=-49 dBm<br />
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0<br />
Tx excessive retries:0 Invalid misc:430 Missed beacon:0<br />
lo no wireless extensions.}}<br />
<br />
In this example, neither {{ic|enp2s0f0}} nor the loopback device have wireless extensions, meaning {{ic|enp2s0f0}} is our Ethernet interface.<br />
<br />
You also need to know these settings:<br />
<br />
* Static IP address.<br />
* Subnet mask.<br />
* Gateway's IP address.<br />
* Name servers' (DNS) IP addresses.<br />
* Domain name (unless you're on a local LAN, in which case you can make it up).<br />
<br />
Activate the connected Ethernet interface (e.g. {{ic|enp2s0f0}}):<br />
<br />
# ip link set enp2s0f0 up<br />
<br />
Add the address:<br />
<br />
# ip addr add ''ip_address''/''subnetmask'' dev ''interface_name''<br />
<br />
For example:<br />
<br />
# ip addr add 192.168.1.2/24 dev enp2s0f0<br />
<br />
For more options, run {{ic|man ip}}.<br />
<br />
Add your gateway like this, substituting your own gateway's IP address:<br />
<br />
# ip route add default via ''ip_address''<br />
<br />
For example:<br />
<br />
# ip route add default via 192.168.1.1<br />
<br />
Edit {{ic|resolv.conf}}, substituting your name servers' IP addresses and your local domain name:<br />
<br />
{{hc|# nano /etc/resolv.conf|<br />
nameserver 61.23.173.5<br />
nameserver 61.95.849.8<br />
search example.com}}<br />
<br />
{{Note|Currently, you may include a maximum of three {{ic|nameserver}} lines.}}<br />
<br />
You should now have a working network connection. If you do not, check the detailed [[Network Configuration]] page.<br />
<br />
==== Wireless ====<br />
<br />
Follow this procedure if you need wireless connectivity (Wi-Fi) during the installation process.<br />
<br />
First, identify the name of your wireless interface.<br />
<br />
{{hc|# iwconfig|2=<br />
enp2s0f0 no wireless extensions.<br />
wlp3s0 IEEE 802.11bgn ESSID:"NETGEAR97"<br />
Mode:Managed Frequency:2.427 GHz Access Point: 2C:B0:5D:9C:72:BF<br />
Bit Rate=65 Mb/s Tx-Power=16 dBm<br />
Retry long limit:7 RTS thr:off Fragment thr:off<br />
Power Management:on<br />
Link Quality=61/70 Signal level=-49 dBm<br />
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0<br />
Tx excessive retries:0 Invalid misc:430 Missed beacon:0<br />
lo no wireless extensions.}}<br />
<br />
In this example, {{ic|wlp3s0}} is the available wireless interface. If you're unsure, your wireless interface is likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e". <br />
<br />
{{Note|If you do not see output similar to this, then your wireless driver has not been loaded. If this is the case, you must load the driver yourself. Please see [[Wireless Setup]] for more detailed information.}}<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
A small percentage of wireless chipsets also require firmware, in addition to a corresponding driver. If the wireless chipset requires firmware, you are likely to receive this error when bringing the interface up:<br />
<br />
{{hc|# ip link set wlp3s0 up|<br />
SIOCSIFFLAGS: No such file or directory}}<br />
<br />
If unsure, invoke {{ic|dmesg}} to query the kernel log for a firmware request from the wireless chipset.<br />
<br />
Example output from an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|# dmesg <nowiki>|</nowiki> grep firmware|<br />
firmware: requesting iwlwifi-5000-1.ucode}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless Setup]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Next, use {{Pkg|netcfg}}'s {{ic|wifi-menu}} to connect to a network:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
You should now have a working network connection. If you do not, check the detailed [[Wireless Setup]] page.<br />
<br />
==== xDSL (PPPoE), analog modem or ISDN ====<br />
<br />
If you have a router in bridge mode, run:<br />
<br />
# pppoe-setup<br />
<br />
* Type in the username that the ISP provided you with.<br />
* Press {{Keypress|Enter}} for "eth0".<br />
* Press {{Keypress|Enter}} for "no", so that it stays up continuously.<br />
* Type {{ic|server}} (since this is usually the case).<br />
* Press {{Keypress|1}} for a firewall.<br />
* Type in the password that the ISP provided you with.<br />
* Press {{Keypress|Y}} at the end.<br />
<br />
To use these settings and connect to your ISP, run:<br />
<br />
# pppoe-start<br />
<br />
You may also need to adjust your {{ic|resolv.conf}}:<br />
<br />
# echo nameserver 8.8.8.8 > /etc/resolv.conf<br />
<br />
If you have a dial-up or ISDN connection, see [[Direct Modem Connection]].<br />
<br />
==== Behind a proxy server ====<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
=== Prepare the storage drive ===<br />
<br />
{{Warning|Partitioning can destroy data. You are '''strongly''' cautioned and advised to backup any critical data before proceeding.}}<br />
<br />
Absolute beginners are encouraged to use a graphical partitioning tool. [http://gparted.sourceforge.net/download.php GParted] is a good example, and is [http://gparted.sourceforge.net/livecd.php provided as a "live" CD]. It is also included on live CDs of most Linux distributions such as [[Wikipedia:Ubuntu (operating system)|Ubuntu]] and [[Wikipedia:Linux Mint|Linux Mint]]. A drive should first be [[partitioning|partitioned]] and the partitions should be formatted with a [[File Systems|file system]] before rebooting.<br />
<br />
See [[Swap]] for details if you wish to set up a swap partition or file now. A swap file is easier to resize than a partition and can be created at any point after installation, but cannot be used with a BTRFS filesystem.<br />
<br />
If you have already done so, proceed to [[#Mount the partitions|Mount the partitions]].<br />
<br />
Otherwise, see the following example.<br />
<br />
==== Example ====<br />
<br />
The Arch Linux install media includes the following partitioning tools: {{ic|fdisk}}, {{ic|gdisk}}, {{ic|cfdisk}}, {{ic|cgdisk}}, {{ic|parted}}.<br />
<br />
{{Box BLUE|Notes regarding [[UEFI]] boot:|<br />
* If you have a UEFI motherboard, you will need to create an extra [[Unified Extensible Firmware Interface#Create an UEFI System Partition in Linux|UEFI System Partition]].<br />
* It is recommended to always use GPT for UEFI boot, as some UEFI firmwares do not allow UEFI-MBR boot.}}<br />
<br />
{{Box BLUE|Notes regarding [[GPT]] partitioning:|<br />
* If you are not dual booting with Windows, then it is advisable to use GPT instead of MBR. Read [[GPT]] for a list of advantages.<br />
* If you have a BIOS motherboard (or plan on booting in BIOS compatibility mode) and you want to setup GRUB on a GPT-partitioned drive, you will need to create an extra [[GRUB2#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]]. Syslinux doesn't need one.<br />
* Some BIOS systems may have issues with GPT. See http://mjg59.dreamwidth.org/8035.html and http://rodsbooks.com/gdisk/bios.html for more info and possible workarounds.}}<br />
<br />
{{Note|If you are installing to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
<br />
The example system will contain a 15 GB root partition, and a [[Partitioning#/home|home]] partition for the remaining space. Choose either [[MBR]] or [[GPT]]. Do not choose both!<br />
<br />
It should be emphasized that partitioning is a personal choice and that this example is only for illustrative purposes. See [[Partitioning]].<br />
<br />
{| class="wikitable"<br />
|-<br />
| rowspan="2" | '''MBR'''<br />
| rowspan="2"| {{ic|cfdisk&nbsp;/dev/sda}}<br />
| '''Root:'''<br />
<br />
* Choose New (or press {{Keypress|N}}) – {{Keypress|Enter}} for Primary – type in "15360" – {{Keypress|Enter}} for Beginning – {{Keypress|Enter}} for Bootable.<br />
|-<br />
|<br />
'''Home:'''<br />
<br />
* Press the down arrow to move to the free space area.<br />
* Choose New (or press {{Keypress|N}}) – {{Keypress|Enter}} for Primary – {{Keypress|Enter}} to use the rest of the drive (or you could type in the desired size).<br />
|-<br />
| rowspan="2" | '''GPT'''<br />
| rowspan="2"| {{ic|cgdisk&nbsp;/dev/sda}}<br />
| '''Root:'''<br />
<br />
* Choose New (or press {{Keypress|N}}) – {{Keypress|Enter}} for the first sector (2048) – type in "15G" – {{Keypress|Enter}} for the default hex code (8300) – {{Keypress|Enter}} for a blank partition name.<br />
|-<br />
| '''Home:'''<br />
<br />
* Press the down arrow a couple of times to move to the larger free space area.<br />
* Choose New (or press {{Keypress|N}}) – {{Keypress|Enter}} for the first sector – {{Keypress|Enter}} to use the rest of the drive (or you could type in the desired size; for example "30G") – {{Keypress|Enter}} for the default hex code (8300) – {{Keypress|Enter}} for a blank partition name.<br />
|}<br />
<br />
If you chose MBR, here's how it should look like:<br />
<br />
Name Flags Part Type FS Type [Label] Size (MB)<br />
-----------------------------------------------------------------------<br />
sda1 Boot Primary Linux 15360<br />
sda2 Primary Linux 133000*<br />
<br />
If you chose GPT, here's how it should look like:<br />
<br />
Part. # Size Partition Type Partition Name<br />
----------------------------------------------------------------<br />
1007.0 KiB free space<br />
1 15.0 GiB Linux filesystem<br />
2 123.45 GiB Linux filesystem<br />
<br />
Double check and make sure that you are happy with the partition sizes as well as the partition table layout before continuing.<br />
<br />
If you would like to start over, you can simply select Quit (or press {{Keypress|Q}}) to exit without saving changes and then restart cfdisk (or cgdisk).<br />
<br />
If you are satisfied, choose Write (or press {{Keypress|Shift+W}}) to finalize and to write the partition table to the drive. Type "yes" and choose Quit (or press {{Keypress|Q}}) to exit without making any more changes.<br />
<br />
Simply partitioning is not enough; the partitions also need a [[File Systems|filesystem]]. To format the partitions with an ext4 filesystem:<br />
<br />
{{Warning|Double check and triple check that it's actually {{ic|/dev/sda1}} and {{ic|/dev/sda2}} that you want to format.}}<br />
<br />
# mkfs.ext4 /dev/sda1<br />
# mkfs.ext4 /dev/sda2<br />
<br />
If you have made a partition dedicated to swap (code 82), don't forget to format and activate it with:<br />
<br />
# mkswap /dev/sda''X''<br />
# swapon /dev/sda''X''<br />
<br />
=== Mount the partitions ===<br />
<br />
Each partition is identified with a number suffix. For example, {{ic|sda1}} specifies the first partition of the first drive, while {{ic|sda}} designates the entire drive.<br />
<br />
To display the current partition layout:<br />
<br />
# lsblk /dev/sda<br />
<br />
{{Note|Do not mount more than one partition to the same directory. And pay attention, because the mounting order is important.}}<br />
<br />
First, mount the root partition on {{ic|/mnt}}. Following the example when using {{ic|cfdisk}} above (yours may be different), it would be:<br />
<br />
# mount /dev/sda1 /mnt<br />
<br />
Then mount the home partition and any other separate partition ({{ic|/boot}}, {{ic|/var}}, etc), if you have any:<br />
<br />
# mkdir /mnt/home<br />
# mount /dev/sda2 /mnt/home<br />
<br />
In case you have a UEFI motherboard, mount the UEFI partition:<br />
<br />
# mkdir -p /mnt/boot/efi<br />
# mount /dev/sda''X'' /mnt/boot/efi<br />
<br />
=== Select a mirror ===<br />
<br />
Before installing, you may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by {{ic|pacstrap}} as well, so it's worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on 2012-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
* {{Keypress|Alt+6}} to copy a {{ic|Server}} line.<br />
* {{Keypress|PageUp}} key to scroll up.<br />
* {{Keypress|Ctrl+U}} to paste it at the top of the list.<br />
* {{Keypress|Ctrl+X}} to exit, and when prompted to save changes, press {{Keypress|Y}} and {{Keypress|Enter}} to use the same filename.<br />
<br />
If you want, you can make it the ''only'' mirror available by getting rid of everything else (using {{Keypress|Ctrl+K}}), but it's usually a good idea to have a few more, in case the first one goes offline.<br />
<br />
{{Tip|<br />
* Use the [https://www.archlinux.org/mirrorlist/ Mirrorlist Generator] to get an updated list for your country. HTTP mirrors are faster than FTP, because of something called [[Wikipedia:Keepalive|keepalive]]. With FTP, pacman has to send out a signal each time it downloads a package, resulting in a brief pause. For other ways to generate a mirror list, see [[Mirrors#Sorting mirrors|Sorting mirrors]] and [[Reflector]].<br />
* [https://archlinux.org/mirrors/status/ Arch Linux MirrorStatus] reports various aspects about the mirrors such as network problems with mirrors, data collection problems, the last time mirrors have been synced, etc.}}<br />
<br />
{{Note|<br />
* Whenever in the future you change your list of mirrors, always remember to force pacman to refresh all package lists with {{ic|pacman -Syy}}. This is considered to be good practice and will avoid possible headaches. See [[Mirrors]] for more information.<br />
* If you're using an older installation medium, your mirrorlist might be outdated, which might lead to problems when updating Arch Linux (see {{Bug|22510}}). Therefore it is advised to obtain the latest mirror information as described above.<br />
* Some issues have been reported in the [https://bbs.archlinux.org/ Arch Linux forums] regarding network problems that prevent pacman from updating/synchronizing repositories (see [https://bbs.archlinux.org/viewtopic.php?id&#61;68944] and [https://bbs.archlinux.org/viewtopic.php?id&#61;65728]). When installing Arch Linux natively, these issues have been resolved by replacing the default pacman file downloader with an alternative (see [[Improve Pacman Performance]] for more details). When installing Arch Linux as a guest OS in [[VirtualBox]], this issue has also been addressed by using "Host interface" instead of "NAT" in the machine properties.}}<br />
<br />
=== Install the base system ===<br />
<br />
The base system is installed using the [https://github.com/falconindy/arch-install-scripts/blob/master/pacstrap.in pacstrap] script.<br />
<br />
The {{ic|-i}} switch can be omitted if you wish to install every package from the ''base'' and ''base-devel'' groups without prompting.<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
{{Note|If pacman fails to verify your packages, check the system time with {{ic|cal}}. If the system date is invalid (e.g. it shows the year 2010), signing keys will be considered expired (or invalid), signature checks on packages will fail and installation will be interrupted. Make sure to correct the system time, either by doing so manually or with the {{Pkg|ntp}} client, and retry running the pacstrap command. Refer to [[Time]] page for more information on correcting system time.}}<br />
<br />
{{Note|If pacman complains that {{ic|error: failed to commit transaction (invalid or corrupted package)}}, run the following command:<br />
# pacman-key --init && pacman-key --populate archlinux<br />
}}<br />
<br />
* {{Grp|base}}: Software packages from the [core] repo to provide the minimal base environment.<br />
<br />
* {{Grp|base-devel}}: Extra tools from [core] such as {{ic|make}}, and {{ic|automake}}. Most beginners should choose to install it, as it will likely be needed to expand the system. The ''base-devel'' group will be required to install software from the [[Arch User Repository]].<br />
<br />
This will give you a basic Arch system. Other packages can be installed later using [[pacman]].<br />
<br />
=== Generate an fstab ===<br />
<br />
Generate an [[fstab]] file with the following command. UUIDs will be used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you would prefer to use labels instead, replace the {{ic|-U}} option with {{ic|-L}}.<br />
<br />
{{Note|If you encounter errors running genfstab or later in the install process, do '''not''' run genfstab again; just edit the fstab file.}}<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The fstab file should always be checked after generating it. If you made an EFI system partition earlier, then {{ic|genfstab}} has incorrectly added options to your EFI system partition. This will in fact ''prevent'' your computer from booting from that drive, so you need to remove all options for the EFI partition except for {{ic|noatime}}. For the other partitions that use it, be sure to replace {{ic|1="codepage=cp437"}} with {{ic|1="codepage=437"}} or else when you next reboot, any mounts with this option will fail and systemd will halt and drop into recovery mode. This should be fixed by linux 3.8}}<br />
<br />
A few considerations:<br />
<br />
* Only the root ({{ic|/}}) partition needs {{ic|1}} for the last field. Everything else should have either {{ic|2}} or {{ic|0}} (see [[fstab#Field definitions]]).<br />
<br />
=== Chroot and configure the base system ===<br />
<br />
Next, we [[chroot]] into our newly installed system:<br />
<br />
# arch-chroot /mnt<br />
<br />
{{Note|Use {{ic|arch-chroot /mnt /bin/bash}} to chroot into a bash shell.}}<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
==== Locale ====<br />
<br />
Locales are used by '''glibc''' and other locale-aware programs or libraries for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards.<br />
<br />
There are two files that need editing: {{ic|locale.gen}} and {{ic|locale.conf}}.<br />
<br />
* The {{ic|locale.gen}} file is empty by default (everything is commented out) and you need to remove the {{ic|#}} in front of the line(s) you want. You may uncomment more lines than just English (US), as long as you choose their {{ic|UTF-8}} encoding:<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
en_US.UTF-8 UTF-8<br />
de_DE.UTF-8 UTF-8}}<br />
<br />
# locale-gen<br />
<br />
This will run on every '''glibc''' upgrade, generating all the locales specified in {{ic|/etc/locale.gen}}.<br />
<br />
* The {{ic|locale.conf}} file doesn't exist by default. Setting only {{ic|LANG}} should be enough. It will act as the default value for all other variables.<br />
<br />
# echo LANG=en_US.UTF-8 > /etc/locale.conf<br />
# export LANG=en_US.UTF-8<br />
<br />
{{Note|If you set some other language than English at the beginning of the install, the above commands would be something like:<br />
# echo LANG<nowiki>=</nowiki>de_DE.UTF-8 > /etc/locale.conf<br />
# export LANG<nowiki>=</nowiki>de_DE.UTF-8<br />
}}<br />
<br />
To use other {{ic|LC_*}} variables, first run {{ic|locale}} to see the available options. An advanced example can be found [[Locale#Setting_system-wide_locale|here]].<br />
<br />
{{Warning|Using the {{ic|LC_ALL}} variable is strongly discouraged because it overrides everything.}}<br />
<br />
==== Console font and keymap ====<br />
<br />
If you set a keymap at [[#Change_the_language|the beginning]] of the install process, load it now, as well, because the environment has changed. For example:<br />
<br />
# loadkeys ''de-latin1''<br />
# setfont Lat2-Terminus16<br />
<br />
To make them available after reboot, edit {{ic|vconsole.conf}}:<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=de-latin1<br />
FONT=Lat2-Terminus16<br />
}}<br />
<br />
* {{ic|KEYMAP}} – Please note that this setting is only valid for your TTYs, not any graphical window managers or Xorg.<br />
<br />
* {{ic|FONT}} – Available alternate console fonts reside in {{ic|/usr/share/kbd/consolefonts/}}. The default (blank) is safe, but some foreign characters may show up as white squares or as other symbols. It's recommended that you change it to {{ic|Lat2-Terminus16}}, because according to {{ic|/usr/share/kbd/consolefonts/README.Lat2-Terminus16}}, it claims to support "about 110 language sets".<br />
<br />
* Possible option {{ic|FONT_MAP}} – Defines the console map to load at boot. Read {{ic|man setfont}}. Removing it or leaving it blank is safe.<br />
<br />
See [[Fonts#Console_fonts|Console fonts]] and {{ic|man vconsole.conf}} for more information.<br />
<br />
==== Time zone ====<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/<Zone>/<SubZone>}} directories.<br />
<br />
To view the available <Zone>, check the directory {{ic|/usr/share/zoneinfo/}}:<br />
<br />
# ls /usr/share/zoneinfo/<br />
<br />
Similarly, you can check the contents of directories belonging to a <SubZone>:<br />
<br />
# ls /usr/share/zoneinfo/Europe<br />
<br />
Create a symbolic link {{ic|/etc/localtime}} to your zone file {{ic|/usr/share/zoneinfo/<Zone>/<SubZone>}} using this command:<br />
<br />
# ln -s /usr/share/zoneinfo/<Zone>/<SubZone> /etc/localtime<br />
<br />
'''Example:'''<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
==== Hardware clock ====<br />
<br />
Set the hardware clock mode uniformly between your operating systems. Otherwise, they may overwrite the hardware clock and cause time shifts.<br />
<br />
You can generate {{ic|/etc/adjtime}} automatically by using one of the following commands:<br />
<br />
* '''UTC''' (recommended)<br />
<br />
: {{Note|Using [[Wikipedia:Coordinated Universal Time|UTC]] for the hardware clock does not mean that software will display time in UTC.}}<br />
<br />
: {{bc|# hwclock --systohc --utc}}<br />
<br />
To synchronize your "UTC" time over the internet, see [[Network Time Protocol daemon|NTPd]].<br />
<br />
* '''localtime''' (discouraged; used by default in Windows)<br />
<br />
: {{Warning|Using ''localtime'' may lead to several known and unfixable bugs. However, there are no plans to drop support for ''localtime''.}}<br />
<br />
: {{bc|# hwclock --systohc --localtime}}<br />
<br />
If you have (or planning on having) a dual boot setup with Windows:<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC. A quick [[Time#UTC in Windows|registry fix]] is needed. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to ''localtime''.<br />
<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable any time-related services, like [[Network Time Protocol daemon|NTPd]] . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please don't ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
==== Kernel modules ====<br />
<br />
{{Tip|This is just an example, you do not need to set it. All needed modules are automatically loaded by udev, so you will rarely need to add something here. Only add modules that you know are missing.}}<br />
<br />
For kernel modules to load during boot, place a {{ic|*.conf}} file in {{ic|/etc/modules-load.d/}}, with a name based on the program that uses them.<br />
<br />
{{hc|# nano /etc/modules-load.d/virtio-net.conf|<br />
# Load 'virtio-net.ko' at boot.<br />
<br />
virtio-net}}<br />
<br />
If there are more modules to load per {{ic|*.conf}}, the module names can be separated by newlines. A good example are the [[VirtualBox#Arch Linux guests|VirtualBox Guest Additions]].<br />
<br />
Empty lines and lines starting with {{ic|#}} or {{ic|;}} are ignored.<br />
<br />
==== Hostname ====<br />
<br />
Set the [[Wikipedia:hostname|hostname]] to your liking (e.g. ''arch''):<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
{{Note|There is no need to edit {{ic|/etc/hosts}}.}}<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are very similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
{{Note|For more in-depth information on network configration, visit [[Network Configuration]] and [[Wireless Setup]].}}<br />
<br />
==== Wired ====<br />
<br />
; Dynamic IP<br />
<br />
{{Warning|A bug has been noted in the install ISO, in which the name your interface has during installation differs from the one it will have upon reboot. See [https://bugs.archlinux.org/task/33923 Bug #33923] for more details.<br/><br />
<br />
Use the command {{ic|ip link}} (shows interface names) after rebooting into your installed system to find out if you are affected by this. If so, you will have to redo the configuration described below with the correct interface name.}}<br />
<br />
If you only use a single fixed wired network connection, you do not need a network management service and can simply enable the {{ic|dhcpcd}} service. Here, {{ic|''interface_name''}} is your wired interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
And that's it.<br />
<br />
Move on to the next step: [[Beginners%27_Guide/Installation#Create_an_initial_ramdisk_environment|Create an initial ramdisk environment]].<br />
<br />
Alternatively, you can use {{Pkg|netcfg}}'s {{ic|net-auto-wired}}, which gracefully handles dynamic connections to new networks:<br />
<br />
Install {{Pkg|ifplugd}}, which is required for {{ic|net-auto-wired}}:<br />
<br />
# pacman -S ifplugd<br />
<br />
Edit {{ic|/etc/conf.d/netcfg}} and modify the network interface name, most likely it is not eth0. You can find out more about the naming in the warning above.<br />
<br />
{{hc|# nano /etc/conf.d/netcfg|2=<br />
WIRED_INTERFACE="''interface_name''"}}<br />
<br />
Copy a sample profile from {{ic|/etc/network.d/examples}} to {{ic|/etc/network.d}}:<br />
<br />
# cd /etc/network.d<br />
# cp examples/ethernet-dhcp .<br />
<br />
Edit the profile as needed (modify {{ic|INTERFACE}}):<br />
<br />
# nano ethernet-dhcp<br />
<br />
Enable the {{ic|net-auto-wired}} service:<br />
<br />
# systemctl enable net-auto-wired.service<br />
<br />
; Static IP<br />
<br />
Copy a sample profile from {{ic|/etc/network.d/examples}} to {{ic|/etc/network.d}}:<br />
<br />
# cd /etc/network.d<br />
# cp examples/ethernet-static .<br />
<br />
Edit the profile as needed (modify {{ic|INTERFACE}}, {{ic|ADDR}}, {{ic|GATEWAY}} and {{ic|DNS}}):<br />
<br />
# nano ethernet-static<br />
<br />
Edit {{ic|/etc/conf.d/netcfg}} and add the new network profile to the {{ic|NETWORKS}} array:<br />
<br />
{{hc|nano /etc/conf.d/netcfg|2=<br />
NETWORKS=(ethernet-static)}}<br />
<br />
Enable the {{ic|netcfg}} service:<br />
<br />
# systemctl enable netcfg.service<br />
<br />
==== Wireless ====<br />
<br />
You will need to install additional programs to be able to configure and manage wireless network profiles for [[netcfg]].<br />
<br />
[[NetworkManager]] and [[Wicd]] are other popular alternatives.<br />
<br />
* Install the required packages:<br />
<br />
# pacman -S wireless_tools wpa_supplicant wpa_actiond dialog<br />
<br />
If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also [[Wireless Setup#Drivers and firmware|here]]), install the package containing your firmware. For example:<br />
<br />
# pacman -S zd1211-firmware<br />
<br />
See [[Wireless Setup]] and [[WPA supplicant]] for more info.<br />
<br />
* After finishing the rest of this installation and rebooting, you can connect to the network with {{ic|wifi-menu ''interface_name''}} (where {{ic|''interface_name''}} is the interface of your wireless chipset), which will generate a profile file in {{ic|/etc/network.d}} named after the SSID. There are also templates available in {{ic|/etc/network.d/examples/}} for manual configuration.<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
{{Warning|If you're using {{ic|wifi-menu}}, this must be done *after* your reboot when you're no longer chrooted. The process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the templates previously mentioned so that you don't have to worry about using {{ic|wifi-menu}} at all.}}<br />
<br />
* Enable the {{ic|net-auto-wireless}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable net-auto-wireless.service<br />
<br />
{{Note|From [[Netcfg#Net-Auto-Wireless]]: {{ic|wireless-wpa-config}} profiles do not work with {{ic|net-auto-wireless}}. Convert them to {{ic|wireless-wpa-configsection}} or {{ic|wireless-wpa}} instead.}}<br />
<br />
{{Note|[[Netcfg]] also provides {{ic|net-auto-wired}}, which can be used in conjunction with {{ic|net-auto-wireless}}.}}<br />
<br />
{{Note|Wpasupplicant could be fail with message "WPA Authentication/Association Failed". In that case, see this [https://bbs.archlinux.org/viewtopic.php?id&#61;155273 link] for a solution.}}<br />
<br />
* Make sure that the correct wireless interface (e.g. {{ic|wlp3s0}}) is set in {{ic|/etc/conf.d/netcfg}}:<br />
<br />
{{hc|# nano /etc/conf.d/netcfg|2=<br />
WIRELESS_INTERFACE="wlp3s0"}}<br />
<br />
It is also possible to define a list of network profiles that should be automatically connected, using the {{ic|AUTO_PROFILES}} variable in {{ic|/etc/conf.d/netcfg}}. If {{ic|AUTO_PROFILES}} is not set, all known wireless networks will be tried.<br />
<br />
==== xDSL (PPPoE), analog modem or ISDN ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
{{Tip|Most users can skip this step and use the defaults provided in {{ic|mkinitcpio.conf}}. The initramfs image (from the {{ic|/boot}} folder) has already been generated based on this file when the {{Pkg|linux}} package (the Linux kernel) was installed earlier with {{ic|pacstrap}}.}}<br />
<br />
Here you need to set the right [[Mkinitcpio#HOOKS|hooks]] if the root is on a USB drive, if you use RAID, LVM, or if {{ic|/usr}} is on a separate partition.<br />
<br />
Edit {{ic|/etc/mkinitcpio.conf}} as needed and re-generate the initramfs image with:<br />
<br />
# mkinitcpio -p linux<br />
<br />
{{Note|Arch VPS installations on QEMU (e.g. when using {{ic|virt-manager}}) may need {{ic|virtio}} modules in {{ic|mkinitcpio.conf}} to be able to boot.<br />
<br />
{{hc|# nano /etc/mkinitcpio.conf|2=<br />
MODULES="virtio virtio_blk virtio_pci virtio_net"}}}}<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
==== For BIOS motherboards ====<br />
<br />
For BIOS systems, there are three bootloaders - Syslinux, GRUB, and [[LILO]]. Choose the bootloader as per your convenience. Below only Syslinux and GRUB are explained.<br />
<br />
* Syslinux is (currently) limited to loading only files from the partition where it was installed. Its configuration file is considered to be easier to understand. An example configuration can be found [https://bbs.archlinux.org/viewtopic.php?pid=1109328#p1109328 here].<br />
<br />
* GRUB is more feature-rich and supports more complex scenarios. Its configuration file(s) is more similar to a scripting language, which may be difficult for beginners to manually write. It is recommended that they automatically generate one.<br />
<br />
{{Note|Some BIOS systems may have issues with GPT. See http://mjg59.dreamwidth.org/8035.html and http://rodsbooks.com/gdisk/bios.html for more info and possible workarounds.}}<br />
<br />
===== Syslinux =====<br />
<br />
Install the {{Pkg|syslinux}} package and then use the {{ic|syslinux-install_update}} script to automatically ''install'' the files ({{ic|-i}}), mark the partition ''active'' by setting the boot flag ({{ic|-a}}), and install the ''MBR'' boot code ({{ic|-m}}):<br />
<br />
{{Note|If you have partitioned the drive as GPT, install {{Pkg|gptfdisk}} package, as well ({{ic|pacman -S gptfdisk}}), because it contains {{ic|sgdisk}}, which will be used to set the GPT-specific boot flag.}}<br />
<br />
# pacman -S syslinux<br />
# syslinux-install_update -i -a -m<br />
<br />
Configure {{ic|syslinux.cfg}} to point to the right root partition. This step is vital. If it points to the wrong partition, Arch Linux will not boot. Change {{ic|/dev/sda3}} to reflect your root partition ''(if you partitioned your drive as in [[#Prepare the storage drive|the example]], your root partition is sda1)''. Do the same for the fallback entry.<br />
<br />
{{hc|# nano /boot/syslinux/syslinux.cfg|2=<br />
...<br />
LABEL arch<br />
...<br />
APPEND root=/dev/sda3 ro<br />
...}}<br />
<br />
For more information on configuring and using Syslinux, see [[Syslinux]].<br />
<br />
===== GRUB =====<br />
<br />
Install the {{Pkg|grub-bios}} package and then run {{ic|grub-install /dev/sda}}:<br />
<br />
{{Note|Change {{ic|/dev/sda}} to reflect the drive you installed Arch on. Do not append a partition number (do not use {{ic|sda''X''}}).}}<br />
<br />
{{Note|For GPT-partitioned drives on BIOS motherboards, GRUB needs a "[[GRUB2#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]]".}}<br />
<br />
# pacman -S grub-bios<br />
# grub-install --recheck /dev/sda<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
While using a manually created {{ic|grub.cfg}} is absolutely fine, it's recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} ({{ic|pacman -S os-prober}}) before running the next command.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
For more information on configuring and using GRUB, see [[GRUB2]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
For UEFI boot, the drive needs to be GPT-partitioned, and a UEFI System Partition (512 MiB or higher, FAT32, type {{ic|EF00}}) must be present and mounted on {{ic|/boot/efi}}. If you have followed this guide from the beginning, you've already done all of these.<br />
<br />
While there are other [[UEFI Bootloaders|UEFI bootloaders]] available, using EFISTUB is recommended. Below are instructions for setting up EFISTUB and GRUB (of course you choose only one of them).<br />
<br />
{{Note|Syslinux does not yet support UEFI.}}<br />
<br />
===== EFISTUB =====<br />
<br />
The Linux kernel can act as its own bootloader using EFISTUB. This is the UEFI boot method recommended by developers and simpler compared to {{ic|grub-efi-x86_64}}. The steps below set up rEFInd (a fork of rEFIt) to provide a menu for EFISTUB kernels, as well as for booting other UEFI bootloaders. You can also use [[UEFI Bootloaders#Using gummiboot|gummiboot]] instead of rEFInd. Both rEFInd and gummiboot can detect Windows UEFI bootloader in case of dual-boot.<br />
<br />
1. Boot in UEFI mode and load {{ic|efivars}} kernel module before chrooting:<br />
<br />
# modprobe efivars # before chrooting<br />
<br />
2. Mount the UEFISYS partition at {{ic|/mnt/boot/efi}}, chroot and [[UEFI_Bootloaders#Setting_up_EFISTUB|copy the kernel and initramfs files]] as described below.<br />
<br />
* Create {{ic|/boot/efi/EFI/arch/}} directory.<br />
<br />
* Copy {{ic|/boot/vmlinuz-linux}} to {{ic|/boot/efi/EFI/arch/vmlinuz-arch.efi}}. The {{ic|.efi}} file extension is very important as some UEFI firmwares refuse to launch a file without this extension. '''Important:''' Remember that the file is called vmlinu'''z''', but not vmlinu'''x'''.<br />
<br />
* Copy {{ic|/boot/initramfs-linux.img}} to {{ic|/boot/efi/EFI/arch/initramfs-arch.img}}.<br />
<br />
* Copy {{ic|/boot/initramfs-linux-fallback.img}} to {{ic|/boot/efi/EFI/arch/initramfs-arch-fallback.img}}.<br />
<br />
Every time the kernel and initramfs files are updated in {{ic|/boot}}, they need to be updated in {{ic|/boot/efi/EFI/arch}}. This can be automated [[UEFI_Bootloaders#Systemd|using systemd]].<br />
<br />
3. In this guide you set up a bootloader GUI called rEFInd. Alternative bootloaders can be found on the page [[UEFI Bootloaders#Booting EFISTUB]].<br />
For the recommended rEFInd bootloader install the following packages:<br />
# pacman -S refind-efi efibootmgr<br />
<br />
4. Install rEFInd to the UEFISYS partition (summarized from [[UEFI Bootloaders#Using rEFInd]]):<br />
<br />
# mkdir -p /boot/efi/EFI/refind<br />
# cp /usr/lib/refind/refind_x64.efi /boot/efi/EFI/refind/refind_x64.efi<br />
# cp /usr/lib/refind/config/refind.conf /boot/efi/EFI/refind/refind.conf<br />
# cp -r /usr/share/refind/icons /boot/efi/EFI/refind/icons<br />
<br />
5. Create a {{ic|refind_linux.conf}} file with the kernel parameters to be used by rEFInd:<br />
<br />
{{hc|# nano /boot/efi/EFI/arch/refind_linux.conf|2=<br />
"Boot to X" "root=/dev/sdaX ro rootfstype=ext4 systemd.unit=graphical.target"<br />
"Boot to console" "root=/dev/sdaX ro rootfstype=ext4 systemd.unit=multi-user.target"}}<br />
<br />
{{Note|{{ic|refind_linux.conf}} is copied in the directory {{ic|/boot/efi/EFI/arch/}} where the initramfs and the kernel have been copied to in step 2. }}<br />
{{Note|In {{ic|refind_linux.conf}}, sdaX refers to your root file system, not your boot partition, if you created them separately. }}<br />
<br />
6. Add rEFInd to UEFI boot menu using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Warning|Using {{ic|efibootmgr}} on Apple Macs may brick the firmware and may need reflash of the motherboard ROM. For Macs, use {{AUR|mactel-boot}}, or "bless" from within Mac OS X.}}<br />
<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "rEFInd" -l '\EFI\refind\refind_x64.efi'<br />
<br />
{{Note|In the above command, X and Y denote the drive and partition of the UEFISYS partition. For example, in {{ic|/dev/sdc5}}, X is "c" and Y is "5".}}<br />
<br />
7. (Optional) As a fallback, in case {{ic|efibootmgr}} created boot entry does not work, copy {{ic|refind_x64.efi}} to {{ic|/boot/efi/EFI/boot/bootx64.efi}} as follows:<br />
<br />
# cp -r /boot/efi/EFI/refind/* /boot/efi/EFI/boot/<br />
# mv /boot/efi/EFI/boot/refind_x64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
===== GRUB =====<br />
<br />
{{Note|In case you have a system with 32-bit EFI, like pre-2008 Macs, install {{ic|grub-efi-i386}} instead, and use {{ic|1=--target=i386-efi}}.}}<br />
<br />
# pacman -S grub-efi-x86_64 efibootmgr<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
The next command creates a menu entry for GRUB in the UEFI boot menu. However, as of {{Pkg|grub-efi-x86_64}} version 2.00, {{ic|grub-install}} tries to create a menu entry, so running {{ic|efibootmgr}} may not be necessary. See [[UEFI#efibootmgr]] for more info.<br />
<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "Arch Linux (GRUB)" -l '\EFI\arch_grub\grubx64.efi'<br />
<br />
Next, while using a manually created {{ic|grub.cfg}} is absolutely fine, it's recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} ({{ic|pacman -S os-prober}}) before running the next command.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
=== Unmount the partitions and reboot ===<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
Since the partitions are mounted under {{ic|/mnt}}, we use the following command to unmount them:<br />
<br />
# umount /mnt/{boot,home,}<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
{{Tip|Be sure to remove the installation media, otherwise you will boot back into it.}}<noinclude><br />
{{Beginners' Guide navigation}}</noinclude></div>Madchinehttps://wiki.archlinux.org/index.php?title=Xmodmap&diff=230621Xmodmap2012-10-22T11:14:06Z<p>Madchine: /* Additional resources */ rollingrelease.com is some sort of content farm now... :-(</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:X Server]]<br />
[[fr:Xmodmap]]<br />
{{Article summary start}}<br />
{{Article summary text|A general overview of modifying keymaps and pointer mappings with xmodmap.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Xorg}}<br />
{{Article summary wiki|Extra Keyboard Keys}}<br />
{{Article summary wiki|Extra Keyboard Keys in Xorg}}<br />
{{Article summary wiki|Extra Keyboard Keys in Console}}<br />
{{Article summary end}}<br />
<br />
'''Xmodmap''' is a utility for modifying keymaps and pointer button mappings in [[Xorg]].<br />
<br />
== Introduction == <br />
The Linux kernel generates a code each time a key is pressed on a keyboard. That code is compared to a {{ic|table of keycodes}} defining a figure that is then displayed.<br />
<br />
This process is complicated by [[Xorg]], which starts its own table of keycodes. Each keycode can belong to a {{ic|keysym}}. A keysym is like a function, started by typing a key. Xmodmap allows you to edit these keycode-keysym relations.<br />
<br />
== Keymap table ==<br />
Print the current keymap table formatted into expressions:<br />
{{hc|$ xmodmap -pke|2=keycode 57 = n N}}<br />
<br />
Each keymap is followed by the {{Ic|keysyms}} it is mapped to. The above example indicates that the keycode {{ic|57}} is mapped to the lowercase ''n'', while the uppercase ''N'' is mapped to keycode {{Ic|57}} and {{Ic|Shift}}.<br />
<br />
Each keysym column in the table corresponds to a particular key combination:<br />
# {{Keypress|Key}}<br />
# {{Keypress|Shift+Key}}<br />
# {{Keypress|mode_switch+Key}}<br />
# {{Keypress|mode_switch+Shift+Key}}<br />
# {{Keypress|AltGr+Key}}<br />
# {{Keypress|AltGr+Shift+Key}}<br />
<br />
Not all keysyms have to be set, but if you want to assign a latter keysym without assigning earlier ones set them to {{ic|NoSymbol}}.<br />
<br />
You can check which keymap corresponds to a key on your keyboard with [[Extra Keyboard Keys#Using xev|xev]].<br />
<br />
{{tip|There are predefined descriptive keycodes that make mapping additional keys easier (e.g. {{ic|XF86AudioMute}}, {{ic|XF86Mail}}). Those keycodes can be found in: {{ic|/usr/include/X11/XF86keysym.h}}}}<br />
<br />
== Custom table ==<br />
You can create your own map and store it in your home directory (i.e. {{ic|~/.Xmodmap}}). Print the current keymap table into a configuration file:<br />
xmodmap -pke > ~/.Xmodmap<br />
<br />
Make the desired changes to {{ic|~/.Xmodmap}} and then test the new configuration with:<br />
xmodmap ~/.Xmodmap<br />
<br />
To activate your custom table when starting Xorg add the following:<br />
{{hc|~/.xinitrc|<br />
if [ -f $HOME/.Xmodmap ]; then<br />
/usr/bin/xmodmap $HOME/.Xmodmap<br />
fi}}<br />
<br />
Alternatively, edit the global startup script {{ic|/etc/X11/xinit/xinitrc}}.<br />
<br />
=== Test changes ===<br />
You can also make temporary changes for the current session. For example:<br />
xmodmap -e "keycode 46 = l L l L lstroke Lstroke lstroke"<br />
xmodmap -e "keysym a = e E"<br />
<br />
== Special keys/signals ==<br />
<br />
You can also also edit the keys: {{Keypress|Shift}}, {{Keypress|Ctrl}}, {{Keypress|Alt}} and {{Keypress|Super}} (there always exists a left and a right one (Alt_R=AltGr))<br />
<br />
At first you have to delete/clear the signals that should be edited. In the beginning of your {{ic|~/.Xmodmap}}:<br />
!clear Shift<br />
!clear Lock<br />
clear Control<br />
!clear Mod1<br />
!clear Mod2<br />
!clear Mod3<br />
clear Mod4<br />
!clear Mod5<br />
keycode 8 =<br />
...<br />
Remember, {{ic|!}} is a comment so only {{Keypress|Control}} and {{Keypress|Mod4}} (Standard: Super_L Super_R) get cleared.<br />
<br />
Write the new signals at the end of {{ic|~/.Xmodmap}}<br />
keycode 255 =<br />
!add Shift = Shift_L Shift_R<br />
!add Lock = Caps_Lock<br />
add Control = Super_L Super_R<br />
!add Mod1 = Alt_L Alt_R<br />
!add Mod2 = Mode_switch<br />
!add Mod3 =<br />
add Mod4 = Control_L Control_R<br />
!add Mod5 =<br />
The {{Keypress|Super}} keys have now been exchanged with the {{Keypress|Ctrl}} keys.<br />
<br />
== Reverse Scrolling ==<br />
The natural scrolling feature available in OS X Lion can be mimicked with xmodmap. Since the synaptics driver uses the buttons 4/5/6/7 for up/down/left/right scrolling, you simply need to swap the order of how the buttons are declared in {{ic|~/.Xmodmap}}.<br />
<br />
Open {{ic|~/.Xmodmap}} and append the following line to the file:<br />
pointer = 1 2 3 5 4 7 6 8 9 10 11 12<br />
Note how the 4 and 5 have been reversed.<br />
<br />
Then update xmodmap:<br />
xmodmap ~/.Xmodmap<br />
<br />
To return to regular scrolling simply reverse the order of the 4 and 5 or delete the line altogether. For more information check Peter Hutterer's post, [http://who-t.blogspot.com/2011/09/natural-scrolling-in-synaptics-driver.html Natural scrolling in the synaptics driver], or the [https://bbs.archlinux.org/viewtopic.php?id=126258 Reverse scrolling direction ala Mac OS X Lion?] forum thread.<br />
<br />
== Additional resources ==<br />
*[http://www.x.org/archive/current/doc/man/man1/xmodmap.1.xhtml Current man page] at X.Org Foundation<br />
*[http://cweiske.de/howto/xmodmap/allinone.html Multimediakeys with .Xmodmap HOWTO] by Christian Weiske<br />
*[http://dev-loki.blogspot.com/2006/04/mapping-unsupported-keys-with-xmodmap.html Mapping unsupported keys with xmodmap] by Pascal Bleser<br />
*[http://en.gentoo-wiki.com/wiki/Multimedia_Keys Multimedia Keys article] on the [http://en.gentoo-wiki.com/ Gentoo Wiki]<br />
*[http://keytouch.sourceforge.net/howto_keyboard/node4.html How to retrieve scancodes] by Marvin Raaijmakers<br />
*[http://wiki.linuxquestions.org/wiki/List_of_Keysyms_Recognised_by_Xmodmap List of Keysyms Recognised by Xmodmap] on [http://linuxquestions.org LinuxQuestions]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=229950Intel graphics2012-10-20T11:15:28Z<p>Madchine: /* H.264 decoding on GMA 4500 */ links</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[cs:Intel]]<br />
[[es:Intel]]<br />
[[fr:Intel]]<br />
[[hu:Intel]]<br />
[[it:Intel]]<br />
[[pl:Intel]]<br />
[[ru:Intel]]<br />
[[zh-CN:Intel]]<br />
[[zh-TW:Intel]]<br />
{{Article summary start}}<br />
{{Article summary text|Information on Intel graphics cards/chipsets and the ''intel'' video driver.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ATI}}<br />
{{Article summary wiki|NVIDIA}}<br />
{{Article summary wiki|Poulsbo}}<br />
{{Article summary wiki|Xorg}}<br />
{{Article summary wiki|Intel_gma3600}}<br />
{{Article summary end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are now essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:Comparison of Intel graphics processing units|this comparison on wikipedia]].<br />
<br />
{{Note|PowerVR based graphics ([[Poulsbo|GMA 500]] and [[Intel_gma3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
Prerequisite: [[Xorg]]<br />
<br />
[[pacman|Install]] the {{Pkg|xf86-video-intel}} package which is available in the [[Official Repositories|official repositories]]. It provides the DDX driver for 2D acceleration and an [[XvMC]] driver for video decoding on older GPUs. It pulls in {{Pkg|intel-dri}} as a dependency, providing the DRI driver for 3D acceleration.<br />
<br />
If you want to use hardware accelerated video decoding/encoding on newer GPUs, install the [[VA-API]] driver provided by {{pkg|libva-intel-driver}} package also, available in the official repositories.<br />
<br />
You may need to install {{Pkg|lib32-intel-dri}} in 64-bit systems to use 3D acceleration in 32-bit programs.<br />
<br />
== Configuration ==<br />
<br />
There is no need for any kind of configuration to get the X.Org running (an {{ic|xorg.conf}} is unneeded, but needs to be configured correctly if present).<br />
<br />
For the list of options, type {{ic|man intel}}.<br />
<br />
== KMS (Kernel Mode Setting) ==<br />
<br />
[[KMS]] is required in order to run X and a desktop environment such as [[GNOME]], [[KDE]], [[Xfce]], [[LXDE]], etc. KMS is supported by Intel chipsets that use the i915 DRM driver and is enabled by default as of kernel v2.6.32. Versions 2.10 and newer of the {{Pkg|xf86-video-intel}} driver no longer support UMS (except for the very old 810 chipset family), making the use of KMS mandatory<sup>[https://www.archlinux.org/news/484/]</sup>. KMS is typically initialized after the kernel is bootstrapped. It is possible, however, to enable KMS during bootstrap itself, allowing the entire boot process to run at the native resolution.<br />
<br />
{{Note|You '''must''' remove any deprecated references to {{ic|vga}} or {{ic|nomodeset}} from your boot configuration.}}<br />
<br />
To proceed, add the {{ic|i915}} module to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}:<br />
MODULES="'''i915'''"<br />
<br />
Now, regenerate the initramfs:<br />
# mkinitcpio -p linux<br />
<br />
and reboot the system. Everything should work now.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Choose acceleration method ===<br />
<br />
The DDX driver allows to preset your desired acceleration method. The default method is UXA, which is more stable but slower than SNA. SNA has improved performance, but still considered experimental. Check benchmarks done by Phoronix [http://www.phoronix.com/scan.php?page=news_item&px=MTEzOTE]. These can be found [http://www.phoronix.com/scan.php?page=article&item=intel_glamor_first&num=1 here for Sandy Bridge] and [http://www.phoronix.com/scan.php?page=article&item=intel_ivy_glamor&num=1 here for Ivy Bridge]. UXA is still a solid option, if experiencing trouble with SNA.<br />
<br />
If you want to use the new SNA method, create {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} with the following content:<br />
<br />
{{bc|Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "AccelMethod" "sna"<br />
EndSection}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
xrandr --output LVDS1 --set PANEL_FITTING param<br />
where {{ic|param}} can be:<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
If it does not work, you can try:<br />
xrandr --output LVDS1 --set "scaling mode" param<br />
where {{ic|param}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} as you kernel command line parameter in your bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, you may also try disabling TV1 or VGA1 instead of SVIDEO-1.<br />
<br />
=== H.264 decoding on GMA 4500 ===<br />
<br />
The {{pkg|libva-driver-intel}} package provides MPEG-2 decoding only for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-driver-intel-g45-h264}} package, available in the [[Arch User Repository]]. Note however that this support is experimental and not currently in active development. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [http://www.emmolution.org/?p=192&cpage=1#comment-12292].<br />
<br />
=== Setting gamma and brightness ===<br />
Intel offers no way to adjust these at the driver level. Luckily these can be set with {{ic|xgamma}} and {{ic|xrandr}}.<br />
<br />
Gamma can be set with:<br />
<br />
xgamma -gamma 1.0<br />
<br />
or:<br />
<br />
xrandr --output VGA1 --gamma 1.0:1.0:1.0<br />
<br />
Brightness can be set with:<br />
<br />
xrandr --output VGA1 --brightness 1.0<br />
<br />
== Troubleshooting ==<br />
<br />
=== Glxgears shows low performance results ===<br />
{{Note|{{ic|glxgears}} is not a benchmark tool for performance comparison between multiple systems.}}<br />
<br />
If you run {{ic|glxgears}} in order to check your system's graphics performance, you may notice it showing results around 60 FPS. For example:<br />
[...]<br />
311 frames in 5.0 seconds = 61.973 FPS<br />
311 frames in 5.0 seconds = 62.064 FPS<br />
311 frames in 5.0 seconds = 62.026 FPS<br />
[...]<br />
<br />
That is not caused by performance regression, but because the system graphics are using [[Wikipedia:Analog television#Vertical synchronization|vertical synchronization]], which is your display's native frames per second.<br />
<br />
==== Disable VSYNC ====<br />
To disable VSYNC just add in your {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} in {{ic|Section "Device"}} the string {{ic|Option "SwapbuffersWait" "false"}}.<br />
<br />
Alternatively, set {{ic|vblank_mode}} to {{ic|0}} in {{ic|~/.drirc}} and make sure that {{ic|driver}} is set to {{ic|dri2}}:<br />
{{hc|~/.drirc|2=<device screen="0" driver="dri2"><br />
<application name="Default"><br />
<option name="vblank_mode" value="0"/><br />
</application><br />
</device>}}<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If you are using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Intel#KMS (Kernel Mode Setting)|KMS]] above.<br />
<br />
Alternatively, appending the following to the kernel command line seems to work as well:<br />
video=SVIDEO-1:d<br />
<br />
=== Tear-free video ===<br />
If you are using the SNA acceleration method, you can get rid of video tearing by adding<br />
{{bc|Option "TearFree" "true"}} <br />
to the Device section of {{ic|/etc/X11/xorg.conf.d/20-intel.conf}}<br />
<br />
=== X freeze/crash with intel driver ===<br />
There is a [https://bugs.freedesktop.org/show_bug.cgi?id=26345 know problem with the i845G chipset], which causes that the GPU hangs after a while.<br />
<br />
If you have issue with X crashing, or GPU hang, or problem with frozen X, then the fix may be to disable the GPU usage with the "NoAccel" option:<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "old intel stuff"<br />
Driver "intel"<br />
Option "NoAccel" "True"<br />
EndSection}}<br />
<br />
=== Adding undetected resolutions ===<br />
This issue is covered on the [[Xrandr#Adding_undetected_resolutions|Xrandr page]].<br />
<br />
=== Slowness after an upgrade to libGL 9 and Intel-DRI 9 ===<br />
[https://wiki.archlinux.org/index.php/Downgrading_Packages#ARM Downgrade] to Intel-DRI 8 and libGL 8.<br />
<br />
==See also==<br />
* http://intellinuxgraphics.org/documentation.html (includes a list of supported hardware)<br />
* [[KMS]] &mdash; Arch wiki article on kernel mode setting<br />
* [[Xrandr]] &mdash; If you have problems setting the resolution<br />
* Arch Linux forums: [https://bbs.archlinux.org/viewtopic.php?pid=522665#p522665 Intel 945GM, Xorg, Kernel - performance]</div>Madchinehttps://wiki.archlinux.org/index.php?title=VA-API&diff=229949VA-API2012-10-20T10:59:12Z<p>Madchine: /* Supported formats */ Removed direct link to package, inserted link to wiki. The decoding support for 4500 is experimental and doesn't work perfectly. Best that a user knows this before getting his hopes up.</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
{{Article summary start}}<br />
{{Article summary text|Explains VA-API support in various hardware and software components}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|XvMC}}<br />
{{Article summary wiki|MPlayer}}<br />
{{Article summary end}}<br />
<br />
'''[http://www.freedesktop.org/wiki/Software/vaapi Video Acceleration API]''' is a specification and open source library to provide hardware accelerated video decode/encode.<br />
<br />
==Supported hardware==<br />
*[[NVIDIA]] GeForce 8 series and newer cards are supported by the {{pkg|libva-vdpau-driver}} package, available in the [[official repositories]]. It uses the proprietary {{pkg|nvidia-utils}} driver.<br />
*[[Intel]] GMA 4500 series and newer GPUs are supported by the open source {{pkg|libva-intel-driver}} package, available in the [[official repositories]].<br />
*[[ATI Catalyst|AMD]] Radeon HD 4000 series and newer GPUs are supported by {{pkg|xvba-video-open}} package, available in the [[official repositories]]. It uses the proprietary {{pkg|catalyst-utils}} driver for Radeon HD 5000 series and newer, and {{AUR|catalyst-legacy-utils}} for Radeon HD 4000 series. Recent {{Pkg|mesa}} versions together with [[ATI#Enabling video acceleration|AMD open source driver]] can decode some videos too, but number of formats supported is poor.<br />
<br />
===Supported formats===<br />
{| class="wikitable" border="1" cellpadding="2" style="width: 100%"<br />
! <br />
! {{pkg|libva-vdpau-driver}}<br />
! {{pkg|libva-intel-driver}}<br />
! {{pkg|xvba-video-open}}<br />
|-<br />
| MPEG2 decoding<br />
| Nvidia GeForce 8 and newer, AMD Radeon 9500 and newer<br />
| Intel GMA 4500 and newer<br />
| AMD Radeon HD 4000 and newer<br />
|-<br />
| MPEG4 decoding<br />
| Nvidia GeForce 200 and newer<br />
| -<br />
| -<br />
|-<br />
| H264 decoding<br />
| Nvidia GeForce 8 and newer<br />
| Intel GMA 4500<sup>1</sup>, Ironlake Graphics and newer<br />
| AMD Radeon HD 4000 and newer<br />
|-<br />
| VC1 decoding<br />
| Nvidia GeForce 8 and newer<br />
| Intel Sandy Bridge Graphics and newer<br />
| AMD Radeon HD 4000 and newer<br />
|-<br />
| H264 encoding<br />
| -<br />
| Intel Sandy Bridge Graphics and newer<br />
| -<br />
|}<br />
<sup>1</sup>Supported by the libva-driver-intel-g45-h264 package. See [[Intel_Graphics#H.264_decoding_on_GMA_4500|H.264 decoding on GMA 4500]] for instructions and caveats.<br />
<br />
In order to check what profiles (features) are supported by your GPU, run the following command, which provided by the {{pkg|libva}} package:<br />
{{bc|$ vainfo}}<br />
VAEntrypointVLD means that your card is capable to decode this format, VAEntrypointEncSlice means that you can encode to this format.<br />
<br />
==Supported software==<br />
=== [[MPlayer]] ===<br />
Install {{pkg|mplayer-vaapi}} package, available in the [[official repositories]].<br />
{{bc|$ mplayer -vo vaapi -fs ''foobar.mpeg''}}<br />
*'''-vo''' - Select vaapi video output driver<br />
*'''-fs''' - Fullscreen playback (optional)<br />
<br />
MPlayer based players:<br />
* {{pkg|gnome-mplayer}}: open preferences and set the video output to "vaapi".<br />
* {{pkg|smplayer}}: open preferences and set the video driver to "vaapi", and deselect "Enable screenshots".<br />
<br />
=== [[GStreamer]] ===<br />
Install {{AUR|gstreamer-vaapi}} package, available in the [[Arch User Repository]].<br />
{{bc|$ gst-launch-0.10 playbin2 uri&#61;file://''/path/to/foobar.mpeg''}}<br />
VA-API is used automatically, if supported format found.</div>Madchinehttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=229947Intel graphics2012-10-20T10:48:52Z<p>Madchine: /* H.264 decoding on GMA 4500 */</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[cs:Intel]]<br />
[[es:Intel]]<br />
[[fr:Intel]]<br />
[[hu:Intel]]<br />
[[it:Intel]]<br />
[[pl:Intel]]<br />
[[ru:Intel]]<br />
[[zh-CN:Intel]]<br />
[[zh-TW:Intel]]<br />
{{Article summary start}}<br />
{{Article summary text|Information on Intel graphics cards/chipsets and the ''intel'' video driver.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ATI}}<br />
{{Article summary wiki|NVIDIA}}<br />
{{Article summary wiki|Poulsbo}}<br />
{{Article summary wiki|Xorg}}<br />
{{Article summary wiki|Intel_gma3600}}<br />
{{Article summary end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are now essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:Comparison of Intel graphics processing units|this comparison on wikipedia]].<br />
<br />
{{Note|PowerVR based graphics ([[Poulsbo|GMA 500]] and [[Intel_gma3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
Prerequisite: [[Xorg]]<br />
<br />
[[pacman|Install]] the {{Pkg|xf86-video-intel}} package which is available in the [[Official Repositories|official repositories]]. It provides the DDX driver for 2D acceleration and an [[XvMC]] driver for video decoding on older GPUs. It pulls in {{Pkg|intel-dri}} as a dependency, providing the DRI driver for 3D acceleration.<br />
<br />
If you want to use hardware accelerated video decoding/encoding on newer GPUs, install the [[VA-API]] driver provided by {{pkg|libva-intel-driver}} package also, available in the official repositories.<br />
<br />
You may need to install {{Pkg|lib32-intel-dri}} in 64-bit systems to use 3D acceleration in 32-bit programs.<br />
<br />
== Configuration ==<br />
<br />
There is no need for any kind of configuration to get the X.Org running (an {{ic|xorg.conf}} is unneeded, but needs to be configured correctly if present).<br />
<br />
For the list of options, type {{ic|man intel}}.<br />
<br />
== KMS (Kernel Mode Setting) ==<br />
<br />
[[KMS]] is required in order to run X and a desktop environment such as [[GNOME]], [[KDE]], [[Xfce]], [[LXDE]], etc. KMS is supported by Intel chipsets that use the i915 DRM driver and is enabled by default as of kernel v2.6.32. Versions 2.10 and newer of the {{Pkg|xf86-video-intel}} driver no longer support UMS (except for the very old 810 chipset family), making the use of KMS mandatory<sup>[https://www.archlinux.org/news/484/]</sup>. KMS is typically initialized after the kernel is bootstrapped. It is possible, however, to enable KMS during bootstrap itself, allowing the entire boot process to run at the native resolution.<br />
<br />
{{Note|You '''must''' remove any deprecated references to {{ic|vga}} or {{ic|nomodeset}} from your boot configuration.}}<br />
<br />
To proceed, add the {{ic|i915}} module to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}:<br />
MODULES="'''i915'''"<br />
<br />
Now, regenerate the initramfs:<br />
# mkinitcpio -p linux<br />
<br />
and reboot the system. Everything should work now.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Choose acceleration method ===<br />
<br />
The DDX driver allows to preset your desired acceleration method. The default method is UXA, which is more stable but slower than SNA. SNA has improved performance, but still considered experimental. Check benchmarks done by Phoronix [http://www.phoronix.com/scan.php?page=news_item&px=MTEzOTE]. These can be found [http://www.phoronix.com/scan.php?page=article&item=intel_glamor_first&num=1 here for Sandy Bridge] and [http://www.phoronix.com/scan.php?page=article&item=intel_ivy_glamor&num=1 here for Ivy Bridge]. UXA is still a solid option, if experiencing trouble with SNA.<br />
<br />
If you want to use the new SNA method, create {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} with the following content:<br />
<br />
{{bc|Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "AccelMethod" "sna"<br />
EndSection}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
xrandr --output LVDS1 --set PANEL_FITTING param<br />
where {{ic|param}} can be:<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
If it does not work, you can try:<br />
xrandr --output LVDS1 --set "scaling mode" param<br />
where {{ic|param}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} as you kernel command line parameter in your bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, you may also try disabling TV1 or VGA1 instead of SVIDEO-1.<br />
<br />
=== H.264 decoding on GMA 4500 ===<br />
<br />
The {{pkg|libva-driver-intel}} package provides MPEG-2 decoding only for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-driver-intel-g45-h264}} package, available in the [[Arch User Repository]]. Note however that this is experimental. Using the VA-API witht this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well. Your mileage may vary.<br />
<br />
=== Setting gamma and brightness ===<br />
Intel offers no way to adjust these at the driver level. Luckily these can be set with {{ic|xgamma}} and {{ic|xrandr}}.<br />
<br />
Gamma can be set with:<br />
<br />
xgamma -gamma 1.0<br />
<br />
or:<br />
<br />
xrandr --output VGA1 --gamma 1.0:1.0:1.0<br />
<br />
Brightness can be set with:<br />
<br />
xrandr --output VGA1 --brightness 1.0<br />
<br />
== Troubleshooting ==<br />
<br />
=== Glxgears shows low performance results ===<br />
{{Note|{{ic|glxgears}} is not a benchmark tool for performance comparison between multiple systems.}}<br />
<br />
If you run {{ic|glxgears}} in order to check your system's graphics performance, you may notice it showing results around 60 FPS. For example:<br />
[...]<br />
311 frames in 5.0 seconds = 61.973 FPS<br />
311 frames in 5.0 seconds = 62.064 FPS<br />
311 frames in 5.0 seconds = 62.026 FPS<br />
[...]<br />
<br />
That is not caused by performance regression, but because the system graphics are using [[Wikipedia:Analog television#Vertical synchronization|vertical synchronization]], which is your display's native frames per second.<br />
<br />
==== Disable VSYNC ====<br />
To disable VSYNC just add in your {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} in {{ic|Section "Device"}} the string {{ic|Option "SwapbuffersWait" "false"}}.<br />
<br />
Alternatively, set {{ic|vblank_mode}} to {{ic|0}} in {{ic|~/.drirc}} and make sure that {{ic|driver}} is set to {{ic|dri2}}:<br />
{{hc|~/.drirc|2=<device screen="0" driver="dri2"><br />
<application name="Default"><br />
<option name="vblank_mode" value="0"/><br />
</application><br />
</device>}}<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If you are using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Intel#KMS (Kernel Mode Setting)|KMS]] above.<br />
<br />
Alternatively, appending the following to the kernel command line seems to work as well:<br />
video=SVIDEO-1:d<br />
<br />
=== Tear-free video ===<br />
If you are using the SNA acceleration method, you can get rid of video tearing by adding<br />
{{bc|Option "TearFree" "true"}} <br />
to the Device section of {{ic|/etc/X11/xorg.conf.d/20-intel.conf}}<br />
<br />
=== X freeze/crash with intel driver ===<br />
There is a [https://bugs.freedesktop.org/show_bug.cgi?id=26345 know problem with the i845G chipset], which causes that the GPU hangs after a while.<br />
<br />
If you have issue with X crashing, or GPU hang, or problem with frozen X, then the fix may be to disable the GPU usage with the "NoAccel" option:<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "old intel stuff"<br />
Driver "intel"<br />
Option "NoAccel" "True"<br />
EndSection}}<br />
<br />
=== Adding undetected resolutions ===<br />
This issue is covered on the [[Xrandr#Adding_undetected_resolutions|Xrandr page]].<br />
<br />
=== Slowness after an upgrade to libGL 9 and Intel-DRI 9 ===<br />
[https://wiki.archlinux.org/index.php/Downgrading_Packages#ARM Downgrade] to Intel-DRI 8 and libGL 8.<br />
<br />
==See also==<br />
* http://intellinuxgraphics.org/documentation.html (includes a list of supported hardware)<br />
* [[KMS]] &mdash; Arch wiki article on kernel mode setting<br />
* [[Xrandr]] &mdash; If you have problems setting the resolution<br />
* Arch Linux forums: [https://bbs.archlinux.org/viewtopic.php?pid=522665#p522665 Intel 945GM, Xorg, Kernel - performance]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=229946Intel graphics2012-10-20T10:47:43Z<p>Madchine: /* H.264 decoding on GMA 4500 */ A word of caution.</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[cs:Intel]]<br />
[[es:Intel]]<br />
[[fr:Intel]]<br />
[[hu:Intel]]<br />
[[it:Intel]]<br />
[[pl:Intel]]<br />
[[ru:Intel]]<br />
[[zh-CN:Intel]]<br />
[[zh-TW:Intel]]<br />
{{Article summary start}}<br />
{{Article summary text|Information on Intel graphics cards/chipsets and the ''intel'' video driver.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ATI}}<br />
{{Article summary wiki|NVIDIA}}<br />
{{Article summary wiki|Poulsbo}}<br />
{{Article summary wiki|Xorg}}<br />
{{Article summary wiki|Intel_gma3600}}<br />
{{Article summary end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are now essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:Comparison of Intel graphics processing units|this comparison on wikipedia]].<br />
<br />
{{Note|PowerVR based graphics ([[Poulsbo|GMA 500]] and [[Intel_gma3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
Prerequisite: [[Xorg]]<br />
<br />
[[pacman|Install]] the {{Pkg|xf86-video-intel}} package which is available in the [[Official Repositories|official repositories]]. It provides the DDX driver for 2D acceleration and an [[XvMC]] driver for video decoding on older GPUs. It pulls in {{Pkg|intel-dri}} as a dependency, providing the DRI driver for 3D acceleration.<br />
<br />
If you want to use hardware accelerated video decoding/encoding on newer GPUs, install the [[VA-API]] driver provided by {{pkg|libva-intel-driver}} package also, available in the official repositories.<br />
<br />
You may need to install {{Pkg|lib32-intel-dri}} in 64-bit systems to use 3D acceleration in 32-bit programs.<br />
<br />
== Configuration ==<br />
<br />
There is no need for any kind of configuration to get the X.Org running (an {{ic|xorg.conf}} is unneeded, but needs to be configured correctly if present).<br />
<br />
For the list of options, type {{ic|man intel}}.<br />
<br />
== KMS (Kernel Mode Setting) ==<br />
<br />
[[KMS]] is required in order to run X and a desktop environment such as [[GNOME]], [[KDE]], [[Xfce]], [[LXDE]], etc. KMS is supported by Intel chipsets that use the i915 DRM driver and is enabled by default as of kernel v2.6.32. Versions 2.10 and newer of the {{Pkg|xf86-video-intel}} driver no longer support UMS (except for the very old 810 chipset family), making the use of KMS mandatory<sup>[https://www.archlinux.org/news/484/]</sup>. KMS is typically initialized after the kernel is bootstrapped. It is possible, however, to enable KMS during bootstrap itself, allowing the entire boot process to run at the native resolution.<br />
<br />
{{Note|You '''must''' remove any deprecated references to {{ic|vga}} or {{ic|nomodeset}} from your boot configuration.}}<br />
<br />
To proceed, add the {{ic|i915}} module to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}:<br />
MODULES="'''i915'''"<br />
<br />
Now, regenerate the initramfs:<br />
# mkinitcpio -p linux<br />
<br />
and reboot the system. Everything should work now.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Choose acceleration method ===<br />
<br />
The DDX driver allows to preset your desired acceleration method. The default method is UXA, which is more stable but slower than SNA. SNA has improved performance, but still considered experimental. Check benchmarks done by Phoronix [http://www.phoronix.com/scan.php?page=news_item&px=MTEzOTE]. These can be found [http://www.phoronix.com/scan.php?page=article&item=intel_glamor_first&num=1 here for Sandy Bridge] and [http://www.phoronix.com/scan.php?page=article&item=intel_ivy_glamor&num=1 here for Ivy Bridge]. UXA is still a solid option, if experiencing trouble with SNA.<br />
<br />
If you want to use the new SNA method, create {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} with the following content:<br />
<br />
{{bc|Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "AccelMethod" "sna"<br />
EndSection}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
xrandr --output LVDS1 --set PANEL_FITTING param<br />
where {{ic|param}} can be:<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
If it does not work, you can try:<br />
xrandr --output LVDS1 --set "scaling mode" param<br />
where {{ic|param}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} as you kernel command line parameter in your bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, you may also try disabling TV1 or VGA1 instead of SVIDEO-1.<br />
<br />
=== H.264 decoding on GMA 4500 ===<br />
<br />
The {{pkg|libva-driver-intel}} package provides MPEG-2 decoding only for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-driver-intel-g45-h264}} package, available in the [[Arch User Repository]]. Note however that this is experimental. Using the VA-API witht this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load but resulted in very choppy playback, while 720p worked reasonably well. Your mileage may vary.<br />
<br />
=== Setting gamma and brightness ===<br />
Intel offers no way to adjust these at the driver level. Luckily these can be set with {{ic|xgamma}} and {{ic|xrandr}}.<br />
<br />
Gamma can be set with:<br />
<br />
xgamma -gamma 1.0<br />
<br />
or:<br />
<br />
xrandr --output VGA1 --gamma 1.0:1.0:1.0<br />
<br />
Brightness can be set with:<br />
<br />
xrandr --output VGA1 --brightness 1.0<br />
<br />
== Troubleshooting ==<br />
<br />
=== Glxgears shows low performance results ===<br />
{{Note|{{ic|glxgears}} is not a benchmark tool for performance comparison between multiple systems.}}<br />
<br />
If you run {{ic|glxgears}} in order to check your system's graphics performance, you may notice it showing results around 60 FPS. For example:<br />
[...]<br />
311 frames in 5.0 seconds = 61.973 FPS<br />
311 frames in 5.0 seconds = 62.064 FPS<br />
311 frames in 5.0 seconds = 62.026 FPS<br />
[...]<br />
<br />
That is not caused by performance regression, but because the system graphics are using [[Wikipedia:Analog television#Vertical synchronization|vertical synchronization]], which is your display's native frames per second.<br />
<br />
==== Disable VSYNC ====<br />
To disable VSYNC just add in your {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} in {{ic|Section "Device"}} the string {{ic|Option "SwapbuffersWait" "false"}}.<br />
<br />
Alternatively, set {{ic|vblank_mode}} to {{ic|0}} in {{ic|~/.drirc}} and make sure that {{ic|driver}} is set to {{ic|dri2}}:<br />
{{hc|~/.drirc|2=<device screen="0" driver="dri2"><br />
<application name="Default"><br />
<option name="vblank_mode" value="0"/><br />
</application><br />
</device>}}<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If you are using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Intel#KMS (Kernel Mode Setting)|KMS]] above.<br />
<br />
Alternatively, appending the following to the kernel command line seems to work as well:<br />
video=SVIDEO-1:d<br />
<br />
=== Tear-free video ===<br />
If you are using the SNA acceleration method, you can get rid of video tearing by adding<br />
{{bc|Option "TearFree" "true"}} <br />
to the Device section of {{ic|/etc/X11/xorg.conf.d/20-intel.conf}}<br />
<br />
=== X freeze/crash with intel driver ===<br />
There is a [https://bugs.freedesktop.org/show_bug.cgi?id=26345 know problem with the i845G chipset], which causes that the GPU hangs after a while.<br />
<br />
If you have issue with X crashing, or GPU hang, or problem with frozen X, then the fix may be to disable the GPU usage with the "NoAccel" option:<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "old intel stuff"<br />
Driver "intel"<br />
Option "NoAccel" "True"<br />
EndSection}}<br />
<br />
=== Adding undetected resolutions ===<br />
This issue is covered on the [[Xrandr#Adding_undetected_resolutions|Xrandr page]].<br />
<br />
=== Slowness after an upgrade to libGL 9 and Intel-DRI 9 ===<br />
[https://wiki.archlinux.org/index.php/Downgrading_Packages#ARM Downgrade] to Intel-DRI 8 and libGL 8.<br />
<br />
==See also==<br />
* http://intellinuxgraphics.org/documentation.html (includes a list of supported hardware)<br />
* [[KMS]] &mdash; Arch wiki article on kernel mode setting<br />
* [[Xrandr]] &mdash; If you have problems setting the resolution<br />
* Arch Linux forums: [https://bbs.archlinux.org/viewtopic.php?pid=522665#p522665 Intel 945GM, Xorg, Kernel - performance]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=215074Polkit2012-07-27T15:02:39Z<p>Madchine: /* Limitations */ link to sudo article, not beginner's guide</p>
<hr />
<div>[[Category:Security]]<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file.<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Action groups==<br />
The actions available to you via PolicyKit will depend on the packages you have installed. Some are used in multiple desktop environments (org.freedesktop.*), some are DE-specific (org.gnome.*) and some are specific to a single program (org.archlinux.pkexec.gparted.policy). The command{{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference. <br />
<br />
To get an idea of what PolicyKit can do, here are a few commonly used groups of actions:<br />
* '''[[ConsoleKit]]''' (''org.freedesktop.consolekit.policy'') actions regulated by PolicyKit include shutting down and restarting, including when other users may still be logged in.<br />
* '''[[Upower]]''' (''org.freedesktop.upower.policy'') actions regulated by PolicyKit include [[suspend_to_RAM|suspending]] and [[Pm-utils#Suspend.2FHibernate_as_regular_user|hibernating]].<br />
* '''[[udisks|Udisks2]]''' (''org.freedesktop.udisks2.policy'') actions regulated by PolicyKit include mounting file systems and unclocking encrypted devices.<br />
* '''[[NetworkManager]]''' (''org.freedesktop.NetworkManager.policy'') actions regulated by PolicyKit include turning on and off the network, wifi, or mobile broadband.<br />
<br />
==Limitations==<br />
PolicyKit operates on top of the exisiting permissions systems in linux -- group membership, administrator status -- it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect PolicyKit, e.g. the command line. Therefore it's probably better to use PolicyKit to expand access to priviledged services for unpriviledged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the [[Sudo|sudoers file]] is still the way to go.<br />
<br />
==Documentation==<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213790Polkit2012-07-20T19:09:52Z<p>Madchine: /* Action groups */ typo</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file.<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Action groups==<br />
The actions available to you via PolicyKit will depend on the packages you have installed. Some are used in multiple desktop environments (org.freedesktop.*), some are DE-specific (org.gnome.*) and some are specific to a single program (org.archlinux.pkexec.gparted.policy). The command{{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference. <br />
<br />
To get an idea of what PolicyKit can do, here are a few commonly used groups of actions:<br />
* '''[[ConsoleKit]]''' (''org.freedesktop.consolekit.policy'') actions regulated by PolicyKit include shutting down and restarting, including when other users may still be logged in.<br />
* '''[[Upower]]''' (''org.freedesktop.upower.policy'') actions regulated by PolicyKit include [[suspend_to_RAM|suspending]] and [[Pm-utils#Suspend.2FHibernate_as_regular_user|hibernating]].<br />
* '''[[udisks|Udisks2]]''' (''org.freedesktop.udisks2.policy'') actions regulated by PolicyKit include mounting file systems and unclocking encrypted devices.<br />
* '''[[NetworkManager]]''' (''org.freedesktop.NetworkManager.policy'') actions regulated by PolicyKit include turning on and off the network, wifi, or mobile broadband.<br />
<br />
==Limitations==<br />
PolicyKit operates on top of the exisiting permissions systems in linux -- group membership, administrator status -- it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect PolicyKit, e.g. the command line. Therefore it's probably better to use PolicyKit to expand access to priviledged services for unpriviledged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the [[Beginners'_Guide#Sudo|sudoers file]] is still the way to go.<br />
<br />
==Documentation==<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213788Polkit2012-07-20T19:07:59Z<p>Madchine: /* Action groups */ wikify</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file.<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Action groups==<br />
The actions available to you via PolicyKit will depend on the packages you have installed. Some are used in multiple desktop environments (org.freedesktop.*), some are DE-specific (org.gnome.*) and some are specific to a single program (org.archlinux.pkexec.gparted.policy). The command{{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference. <br />
<br />
To get an idea of what PolicyKit can do, here are a few commonly used groups of actions:<br />
* '''[[ConsoleKit]]''' (''org.freedesktop.consolekit.policy'') actions regulated by PolicyKit include shutting down and restarting, including when other users may still be logged in.<br />
* '''[[Upower]]''' (''org.freedesktop.upower.policy'') actions regulated by PolicyKit include [[suspend_to_RAM|suspending]] and [[Pm-utils#Suspend.2FHibernate_as_regular_user|hibernating]].<br />
* '''[[udisks|Udisks2|]]''' (''org.freedesktop.udisks2.policy'') actions regulated by PolicyKit include mounting file systems and unclocking encrypted devices.<br />
* '''[[NetworkManager]]''' (''org.freedesktop.NetworkManager.policy'') actions regulated by PolicyKit include turning on and off the network, wifi, or mobile broadband.<br />
<br />
==Limitations==<br />
PolicyKit operates on top of the exisiting permissions systems in linux -- group membership, administrator status -- it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect PolicyKit, e.g. the command line. Therefore it's probably better to use PolicyKit to expand access to priviledged services for unpriviledged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the [[Beginners'_Guide#Sudo|sudoers file]] is still the way to go.<br />
<br />
==Documentation==<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Udev&diff=213787Udev2012-07-20T19:02:17Z<p>Madchine: /* Mount internal drives as a normal user */ udisks2</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting]]<br />
[[cs:Udev]]<br />
[[es:Udev]]<br />
[[it:Udev]]<br />
[[ru:Udev]]<br />
[[zh-CN:Udev]]<br />
[[zh-TW:Udev]]<br />
{{Lowercase title}}<br />
<br />
{{ic|udev}} replaces the functionality of both {{Ic|hotplug}} and {{Ic|hwdetect}}.<br />
<br />
''"udev is the device manager for the Linux kernel. Primarily, it manages device nodes in {{ic|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{ic|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [[Wikipedia:Udev|Wikipedia article]]<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, {{ic|/dev/sda}} may randomly become {{ic|/dev/sdb}}. See below for more info on this.<br />
<br />
{{Note|1=Systemd and udev have been merged upstream. Udev will now be part of a package called {{pkg|systemd-tools}}. This package contains several other standalone tools which can be used without systemd. See [http://www.archlinux.org/news/systemd-tools-replaces-udev/ the announcement].}}<br />
<br />
== About udev rules ==<br />
udev rules written by the administrator go in {{ic|/etc/udev/rules.d/}}, their file name has to end with {{ic|.rules}}. The udev rules shipped with various packages are found in {{ic|/usr/lib/udev/rules.d/}}. If there are two files by the same name under {{ic|/usr/lib}} and {{ic|/etc}}, the ones in {{ic|/etc}} take precedence.<br />
<br />
If you want to learn how to write udev rules, see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all of the attributes of a device you can use to write rules, run this command:<br />
# udevadm info -a -n [device name]<br />
<br />
Replace {{ic|[device name]}} with the device present in the system, such as {{ic|/dev/sda}} or {{ic|/dev/ttyUSB0}}.<br />
<br />
udev automatically detects changes to rules files, so changes take effect immediately without requiring udev to be restarted. However, the rules are not re-triggered automatically on already existing devices, so hot-pluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
<br />
== UDisks ==<br />
Simply [[pacman|install]] the {{pkg|udisks}} package, and all of your media should be automatically mounted in [[GNOME]] and [[KDE]] SC 4.6. There is no need for any additional rules this way. Be aware that udisks2 is a compatibility-breaking rewrite of udisks and is the version currently [http://www.archlinux.org/packages/extra/x86_64/udisks2/ required] by GNOME, whereas XFCE and KDE seem to still [http://www.archlinux.org/packages/extra/x86_64/udisks/ require] udisks.<br />
<br />
As an extra bonus you can remove [[HAL]] if you were only using that for auto mounting purposes.<br />
<br />
=== Automounting UDisks Wrappers ===<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [http://igurublog.wordpress.com/downloads/script-devmon/ devmon] - {{AUR|devmon}} is a configuration-less Bash wrapper script for udisks which automatically mounts optical discs and removable drives. It can also selectively automatically start applications or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives. A git version called {{AUR|devmon-git}} is also available.<br />
* {{AUR|ldm}} - A lightweight daemon that mounts usb drives, cds, dvds or floppys automagically. [https://bbs.archlinux.org/viewtopic.php?id=125918]<br />
* [[udiskie]] - Written in Python. Enables automatic mounting and unmounting by any user.<br />
* {{AUR|udisksevt}} - Written in Haskell. Enables automatic mounting by any user. Designed to be integrated with {{AUR|traydevice}}.<br />
* {{AUR|udisksvm}} - A GUI UDisks wrapper which uses the udisks2 dbus interface. It calls a 'traydvm' script, included in the package. The 'traydvm' GUI utility is a script which displays a systray icon for a plugged-in device, with a right-click menu to perform simple actions on the device. As the automount function can be disabled, this tool should work with other automounting tools, to show system tray icons. It is independent of any file manager.<br />
<br />
* You can easily automount and eject removable devices with the combination of {{pkg|pmount}}, {{pkg|udisks2}} and {{pkg|spacefm}}. Note you have to run spacefm in daemon mode with {{ic|spacefm -d &}} in your startup scripts, {{ic|~/.xinitrc}} or {{ic|~/.xsession}}, to get automounting. You can also mount internal disks by adding them to {{ic|/etc/pmount.allow}}.<br />
<br />
=== UDisks Shell Functions ===<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - {{AUR|bashmount}} is a menu-driven Bash script with a configuration file that makes it easy to configure and extend.<br />
<br />
==Tips and tricks==<br />
<br />
=== Accessing Firmware Programmers and USB Virtual Comm Devices ===<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter and the [http://www.atmel.com/tools/AVRDRAGON.aspx?tab=overview Atmel AVR Dragon] programmer. Adjust the permissions accordingly. Verified as of 22-06-2012.<br />
<br />
{{hc|/etc/udev/rules.d/50-embedded_devices.rules|2=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
# USBasp Programmer rules http://www.fischl.de/usbasp/<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
<br />
#Atmel AVR Dragon (dragon_isp) rules<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2107", GROUP="users", MODE="0666"<br />
<br />
#Atmel AVR JTAGICEMKII rules<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2103", GROUP="users", MODE="0666"<br />
<br />
</nowiki>}}<br />
<br />
=== Execute on USB Insert ===<br />
See the [[Execute on USB insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].<br />
<br />
=== Mount internal drives as a normal user ===<br />
If you want to mount an internal drive in KDE or Gnome (maybe on other Desktop Environments too) as a normal user (without the need to type your superuser password), you just have to create one of the following file in [[PolicyKit]] Local Authority depending on whether you use udisks (KDE, XFCE) or udisks2 (newer GNOME) (if in doubt run a {{ic|pacman -Qi udisks2}} to see). The setting extends the privilege to all members of the 'users' group but you can substitute {{ic|unix-user:USERNAME}} for the group setting for individual privileges. See [[PolicyKit]] for details.<br />
<br />
'''udisks'''<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/50-filesystem-mount-system-internal.pkla|2=<nowiki><br />
[Mount a system-internal device]<br />
Identity=unix-group:users<br />
Action=org.freedesktop.udisks.filesystem-mount-system-internal<br />
ResultActive=yes<br />
</nowiki>}}<br />
'''udisks2'''<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/50-filesystem-mount-system-internal.pkla|2=<nowiki><br />
[Mount a system-internal device]<br />
Identity=unix-group:users<br />
Action=org.freedesktop.udisks2.filesystem-mount-system<br />
ResultActive=yes <br />
</nowiki>}}<br />
<br />
=== Mark internal SATA-Ports as eSATA-Ports ===<br />
If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. Gnome and KDE will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal Gnome user can connect their eSATA drives to that port like a USB drive, without any root password and so on.<br />
<br />
{{hc|/etc/udev/rules.d/10-esata.rules|2=<nowiki><br />
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM_INTERNAL}="0"<br />
</nowiki>}}<br />
<br />
{{Note| The DEVPATH can be found after connection the eSata drive with the following command (replace sdb to your needs):<br />
<br />
# find /sys/devices/ -name sdb<br />
/sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb<br />
<br />
}}<br />
<br />
=== Setting static device names ===<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. Udev rule can be added to use static device names.<br />
<br />
==== Network device ====<br />
For example, with two network cards, you may notice a switching of designations between {{Ic|eth0}} and {{Ic|eth1}}.<br />
<br />
One method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{hc|/etc/udev/rules.d/10-network.rules|2=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Ic|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* Some people have problems naming their interfaces after the old style: eth0, eth1, etc. Try something like "lan" or "wlan" if you experience this problem.<br />
<br />
Don't forget to update your {{ic|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
{{Note|With a recent version of udev, this problem should be solved automatically thanks to the {{ic|/usr/lib/udev/write_net_rules}} program which runs the {{ic|75-persistent-net-generator.rules}} script which produces a {{ic|70-persistent-net.rules}}.}}<br />
<br />
==== iscsi device ====<br />
Test the output from scsi_id:<br />
/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sdb<br />
3600601607db11e0013ab5a8e371ce111<br />
<br />
{{hc|/etc/udev/rules.d/75-iscsi.rules|<nowiki><br />
# the iscsi device rules<br />
# this will create an iscsi device for each of the targets<br />
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace /dev/$name", RESULT=="3600601607db11e0013ab5a8e371ce111",<br />
NAME="isda"<br />
</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
=== Blacklisting Modules ===<br />
In rare cases, udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== udevd hangs at boot ===<br />
After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.<br />
<br />
Extract the group names referenced in udev rules and the group names actually present on the system:<br />
<br />
# fgrep -r GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups<br />
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups<br />
<br />
To see the differences, do a side-by-side diff:<br />
<br />
# diff -y present_groups udev_groups<br />
...<br />
network <<br />
nobody <<br />
ntp <<br />
optical optical<br />
power | pcscd<br />
rfkill <<br />
root root<br />
scanner scanner<br />
smmsp <<br />
storage storage<br />
...<br />
<br />
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:<br />
<br />
# groupadd pcscd<br />
<br />
Also, make sure local resources are looked up before resorting to LDAP. {{ic|/etc/nsswitch.conf}} should contain the line<br />
<br />
group: files ldap<br />
<br />
=== Known Problems with Hardware ===<br />
==== BusLogic devices can be broken and will cause a freeze during startup ====<br />
This is a kernel bug and no fix has been provided yet.<br />
<br />
==== Some devices, that should be treated as removable, are not ====<br />
Create a custom udev rule, setting {{ic|UDISKS_SYSTEM_INTERNAL<nowiki>=</nowiki>0}}. For more details, see the manpage of udisks.<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use [[CPU Frequency Scaling]], load the proper module explicitly in your {{Ic|MODULES}} array in {{ic|/etc/rc.conf}}. Further reading: [[rc.conf]].<br />
<br />
==== Sound Problems or Some Modules Not Loaded Automatically ====<br />
Some users have traced this problem to old entries in {{ic|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.<br />
{{Note|Since {{Ic|udev>&#61;171}}, the OSS emulation modules ({{Ic|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) are not automatically loaded by default.}}<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.32. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
=== IDE CD/DVD-drive support ===<br />
Starting with version 170, udev doesn't support CD-ROM/DVD-ROM drives, which are loaded as traditional IDE drives with the {{Ic|ide_cd_mod}} module and show up as {{ic|/dev/hd*}}. The drive remains usable for tools which access the hardware directly, like cdparanoia, but is invisible for higher userspace programs, like KDE.<br />
<br />
A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your initramfs. In that case you can just replace it with ata_piix in your {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
=== Optical Drives Have Group ID Set To Disk ===<br />
If the group ID of your optical drive is set to ''disk'' and you want to have it set to ''optical'' you have to create a custom udev rule:<br />
{{hc|/etc/udev/rules.d|2=# permissions for IDE CD devices<br />
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"<br />
<br />
# permissions for SCSI CD devices<br />
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"}}<br />
<br />
==See also==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Udev&diff=213786Udev2012-07-20T18:54:19Z<p>Madchine: /* UDisks */ udisks2 vs udisks</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting]]<br />
[[cs:Udev]]<br />
[[es:Udev]]<br />
[[it:Udev]]<br />
[[ru:Udev]]<br />
[[zh-CN:Udev]]<br />
[[zh-TW:Udev]]<br />
{{Lowercase title}}<br />
<br />
{{ic|udev}} replaces the functionality of both {{Ic|hotplug}} and {{Ic|hwdetect}}.<br />
<br />
''"udev is the device manager for the Linux kernel. Primarily, it manages device nodes in {{ic|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{ic|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [[Wikipedia:Udev|Wikipedia article]]<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, {{ic|/dev/sda}} may randomly become {{ic|/dev/sdb}}. See below for more info on this.<br />
<br />
{{Note|1=Systemd and udev have been merged upstream. Udev will now be part of a package called {{pkg|systemd-tools}}. This package contains several other standalone tools which can be used without systemd. See [http://www.archlinux.org/news/systemd-tools-replaces-udev/ the announcement].}}<br />
<br />
== About udev rules ==<br />
udev rules written by the administrator go in {{ic|/etc/udev/rules.d/}}, their file name has to end with {{ic|.rules}}. The udev rules shipped with various packages are found in {{ic|/usr/lib/udev/rules.d/}}. If there are two files by the same name under {{ic|/usr/lib}} and {{ic|/etc}}, the ones in {{ic|/etc}} take precedence.<br />
<br />
If you want to learn how to write udev rules, see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all of the attributes of a device you can use to write rules, run this command:<br />
# udevadm info -a -n [device name]<br />
<br />
Replace {{ic|[device name]}} with the device present in the system, such as {{ic|/dev/sda}} or {{ic|/dev/ttyUSB0}}.<br />
<br />
udev automatically detects changes to rules files, so changes take effect immediately without requiring udev to be restarted. However, the rules are not re-triggered automatically on already existing devices, so hot-pluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
<br />
== UDisks ==<br />
Simply [[pacman|install]] the {{pkg|udisks}} package, and all of your media should be automatically mounted in [[GNOME]] and [[KDE]] SC 4.6. There is no need for any additional rules this way. Be aware that udisks2 is a compatibility-breaking rewrite of udisks and is the version currently [http://www.archlinux.org/packages/extra/x86_64/udisks2/ required] by GNOME, whereas XFCE and KDE seem to still [http://www.archlinux.org/packages/extra/x86_64/udisks/ require] udisks.<br />
<br />
As an extra bonus you can remove [[HAL]] if you were only using that for auto mounting purposes.<br />
<br />
=== Automounting UDisks Wrappers ===<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [http://igurublog.wordpress.com/downloads/script-devmon/ devmon] - {{AUR|devmon}} is a configuration-less Bash wrapper script for udisks which automatically mounts optical discs and removable drives. It can also selectively automatically start applications or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives. A git version called {{AUR|devmon-git}} is also available.<br />
* {{AUR|ldm}} - A lightweight daemon that mounts usb drives, cds, dvds or floppys automagically. [https://bbs.archlinux.org/viewtopic.php?id=125918]<br />
* [[udiskie]] - Written in Python. Enables automatic mounting and unmounting by any user.<br />
* {{AUR|udisksevt}} - Written in Haskell. Enables automatic mounting by any user. Designed to be integrated with {{AUR|traydevice}}.<br />
* {{AUR|udisksvm}} - A GUI UDisks wrapper which uses the udisks2 dbus interface. It calls a 'traydvm' script, included in the package. The 'traydvm' GUI utility is a script which displays a systray icon for a plugged-in device, with a right-click menu to perform simple actions on the device. As the automount function can be disabled, this tool should work with other automounting tools, to show system tray icons. It is independent of any file manager.<br />
<br />
* You can easily automount and eject removable devices with the combination of {{pkg|pmount}}, {{pkg|udisks2}} and {{pkg|spacefm}}. Note you have to run spacefm in daemon mode with {{ic|spacefm -d &}} in your startup scripts, {{ic|~/.xinitrc}} or {{ic|~/.xsession}}, to get automounting. You can also mount internal disks by adding them to {{ic|/etc/pmount.allow}}.<br />
<br />
=== UDisks Shell Functions ===<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - {{AUR|bashmount}} is a menu-driven Bash script with a configuration file that makes it easy to configure and extend.<br />
<br />
==Tips and tricks==<br />
<br />
=== Accessing Firmware Programmers and USB Virtual Comm Devices ===<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter and the [http://www.atmel.com/tools/AVRDRAGON.aspx?tab=overview Atmel AVR Dragon] programmer. Adjust the permissions accordingly. Verified as of 22-06-2012.<br />
<br />
{{hc|/etc/udev/rules.d/50-embedded_devices.rules|2=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
# USBasp Programmer rules http://www.fischl.de/usbasp/<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
<br />
#Atmel AVR Dragon (dragon_isp) rules<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2107", GROUP="users", MODE="0666"<br />
<br />
#Atmel AVR JTAGICEMKII rules<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2103", GROUP="users", MODE="0666"<br />
<br />
</nowiki>}}<br />
<br />
=== Execute on USB Insert ===<br />
See the [[Execute on USB insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].<br />
<br />
=== Mount internal drives as a normal user ===<br />
If you want to mount an internal drive in KDE or Gnome (maybe on other Desktop Environments too) as a normal user (without the need to type your superuser password), you just have to create the following file in [[PolicyKit]] Local Authority:<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/50-filesystem-mount-system-internal.pkla|2=<nowiki><br />
[Mount a system-internal device]<br />
Identity=*<br />
Action=org.freedesktop.udisks.filesystem-mount-system-internal<br />
ResultActive=yes<br />
</nowiki>}}<br />
{{Note|You might need to replace 'udisks' with 'udisks2' in case the newer version is used.}}<br />
<br />
=== Mark internal SATA-Ports as eSATA-Ports ===<br />
If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. Gnome and KDE will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal Gnome user can connect their eSATA drives to that port like a USB drive, without any root password and so on.<br />
<br />
{{hc|/etc/udev/rules.d/10-esata.rules|2=<nowiki><br />
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM_INTERNAL}="0"<br />
</nowiki>}}<br />
<br />
{{Note| The DEVPATH can be found after connection the eSata drive with the following command (replace sdb to your needs):<br />
<br />
# find /sys/devices/ -name sdb<br />
/sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb<br />
<br />
}}<br />
<br />
=== Setting static device names ===<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. Udev rule can be added to use static device names.<br />
<br />
==== Network device ====<br />
For example, with two network cards, you may notice a switching of designations between {{Ic|eth0}} and {{Ic|eth1}}.<br />
<br />
One method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{hc|/etc/udev/rules.d/10-network.rules|2=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Ic|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* Some people have problems naming their interfaces after the old style: eth0, eth1, etc. Try something like "lan" or "wlan" if you experience this problem.<br />
<br />
Don't forget to update your {{ic|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
{{Note|With a recent version of udev, this problem should be solved automatically thanks to the {{ic|/usr/lib/udev/write_net_rules}} program which runs the {{ic|75-persistent-net-generator.rules}} script which produces a {{ic|70-persistent-net.rules}}.}}<br />
<br />
==== iscsi device ====<br />
Test the output from scsi_id:<br />
/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sdb<br />
3600601607db11e0013ab5a8e371ce111<br />
<br />
{{hc|/etc/udev/rules.d/75-iscsi.rules|<nowiki><br />
# the iscsi device rules<br />
# this will create an iscsi device for each of the targets<br />
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace /dev/$name", RESULT=="3600601607db11e0013ab5a8e371ce111",<br />
NAME="isda"<br />
</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
=== Blacklisting Modules ===<br />
In rare cases, udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== udevd hangs at boot ===<br />
After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.<br />
<br />
Extract the group names referenced in udev rules and the group names actually present on the system:<br />
<br />
# fgrep -r GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups<br />
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups<br />
<br />
To see the differences, do a side-by-side diff:<br />
<br />
# diff -y present_groups udev_groups<br />
...<br />
network <<br />
nobody <<br />
ntp <<br />
optical optical<br />
power | pcscd<br />
rfkill <<br />
root root<br />
scanner scanner<br />
smmsp <<br />
storage storage<br />
...<br />
<br />
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:<br />
<br />
# groupadd pcscd<br />
<br />
Also, make sure local resources are looked up before resorting to LDAP. {{ic|/etc/nsswitch.conf}} should contain the line<br />
<br />
group: files ldap<br />
<br />
=== Known Problems with Hardware ===<br />
==== BusLogic devices can be broken and will cause a freeze during startup ====<br />
This is a kernel bug and no fix has been provided yet.<br />
<br />
==== Some devices, that should be treated as removable, are not ====<br />
Create a custom udev rule, setting {{ic|UDISKS_SYSTEM_INTERNAL<nowiki>=</nowiki>0}}. For more details, see the manpage of udisks.<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use [[CPU Frequency Scaling]], load the proper module explicitly in your {{Ic|MODULES}} array in {{ic|/etc/rc.conf}}. Further reading: [[rc.conf]].<br />
<br />
==== Sound Problems or Some Modules Not Loaded Automatically ====<br />
Some users have traced this problem to old entries in {{ic|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.<br />
{{Note|Since {{Ic|udev>&#61;171}}, the OSS emulation modules ({{Ic|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) are not automatically loaded by default.}}<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.32. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
=== IDE CD/DVD-drive support ===<br />
Starting with version 170, udev doesn't support CD-ROM/DVD-ROM drives, which are loaded as traditional IDE drives with the {{Ic|ide_cd_mod}} module and show up as {{ic|/dev/hd*}}. The drive remains usable for tools which access the hardware directly, like cdparanoia, but is invisible for higher userspace programs, like KDE.<br />
<br />
A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your initramfs. In that case you can just replace it with ata_piix in your {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
=== Optical Drives Have Group ID Set To Disk ===<br />
If the group ID of your optical drive is set to ''disk'' and you want to have it set to ''optical'' you have to create a custom udev rule:<br />
{{hc|/etc/udev/rules.d|2=# permissions for IDE CD devices<br />
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"<br />
<br />
# permissions for SCSI CD devices<br />
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"}}<br />
<br />
==See also==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213784Polkit2012-07-20T18:24:35Z<p>Madchine: Action groups replaces tools</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file.<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Action groups==<br />
The actions available to you via PolicyKit will depend on the packages you have installed. Some are used in multiple desktop environments (org.freedesktop.*), some are DE-specific (org.gnome.*) and some are specific to a single program (org.archlinux.pkexec.gparted.policy). The command{{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference. <br />
<br />
To get an idea of what PolicyKit can do, here are a few commonly used groups of actions:<br />
* '''ConsoleKit''' (''org.freedesktop.consolekit.policy'') actions regulated by PolicyKit include shutting down and restarting, including when other users may still be logged in.<br />
* '''Upower''' (''org.freedesktop.upower.policy'') actions regulated by PolicyKit include [[suspend_to_RAM|suspending]] and [[Pm-utils#Suspend.2FHibernate_as_regular_user|hibernating]].<br />
* '''Udisks2''' (''org.freedesktop.udisks2.policy'') actions regulated by PolicyKit include mounting file systems and unclocking encrypted devices.<br />
* '''NetworkManager''' (''org.freedesktop.NetworkManager.policy'') actions regulated by PolicyKit include turning on and off the network, wifi, or mobile broadband.<br />
<br />
==Limitations==<br />
PolicyKit operates on top of the exisiting permissions systems in linux -- group membership, administrator status -- it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect PolicyKit, e.g. the command line. Therefore it's probably better to use PolicyKit to expand access to priviledged services for unpriviledged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the [[Beginners'_Guide#Sudo|sudoers file]] is still the way to go.<br />
<br />
==Documentation==<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Policykit&diff=213775Policykit2012-07-20T16:42:00Z<p>Madchine: Creation</p>
<hr />
<div>#REDIRECT [[PolicyKit]]</div>Madchinehttps://wiki.archlinux.org/index.php?title=User_talk:Pointone&diff=213773User talk:Pointone2012-07-20T16:38:36Z<p>Madchine: /* PolicyKit article */ wikified link</p>
<hr />
<div>You reverted my changes to Beginners'_Guide/Extra#Message_bus, saying "rc.d script is preferred method of interacting with daemons)". Please correct me if I'm wrong, but I believe the correct call for the rc.d script is '/etc/rc.d/dbus start', not the current '/etc/rc.d start dbus'.<br />
<br />
[[User:Wake|Wake]] 21:09, 3 February 2012 (EST)<br />
<br />
:Since May 2011, Arch Linux includes the {{ic|/usr/sbin/rc.d}} script that can be used to interface with so-called "rc.d" scripts in {{ic|/etc/rc.d}}. Running {{ic|/etc/rc.d/dbus start}} is functionally equivalent to running {{ic|/usr/sbin/rc.d start dbus}}. See also: [http://www.archlinux.org/news/initscripts-update-1/ initcripts-update-1], [http://www.archlinux.org/news/initscripts-update-2/ initscripts-update-2], [http://projects.archlinux.org/initscripts.git/tree/rc.d rc.d @ initscripts.git].<br />
<br />
:In the name of consistency, all daemon operations on the wiki should use the rc.d executable.<br />
<br />
:-- [[User:Pointone|pointone]] 12:29, 4 February 2012 (EST)<br />
<br />
:: Thanks for the explanation. I added the full path (/usr/sbin/rc.d) so it won't trip other Arch newbies up.<br />
::[[User:Wake|Wake]] 08:35, 9 February 2012 (EST)<br />
<br />
----<br />
Thank you for pointing that out, I can't believe I missed the Romanian ArchWiki. I just went straight to the English version. <br />
<br />
Sorry for my late reply , I had some problems with my Internet supplier and couldn't check my e-mails.<br />
<br />
<br />
<br />
--[[User:Thras0|Thras0]] 02:02, 14 November 2011 (EST)<br />
<br />
<br />
Thanks for your remind about blank page deletion.<br />
<br />
[[User:warren|warren]] 13:00,18 May 2011 (TW, Asia)<br />
<br />
----<br />
<br />
Thanks for your work on the netcfg documentation!<br />
<br />
[[User:Iphitus|Iphitus]] 20:18, 6 March 2010 (EST)<br />
<br />
----<br />
<br />
Hi and thanks for the good work wrt templates.<br />
I wanted first to get the green/red light for my idea and then proceed w/ adding the templates to the articles that beg for them. Many wiki pages are just a wall of grey text.<br />
<br />
[[User:Karol|Karol]] 17:05, 31 May 2009 (EDT)<br />
<br />
----<br />
<br />
Thanks for fixing Compact TOC! I don't know much about templates/markup. [[User:Manolo|manolo]] 18:49, 10 November 2009 (EST)<br />
<br />
----<br />
<br />
Kudos for cleaning up package-building articles! --[[User:Bhobbit|Bhobbit]] 00:57, 26 November 2009 (EST)<br />
<br />
----<br />
<br />
Really good cleanup and update on Fake RAID article. Thanks. --[[User:Loosec|Loosec]] 12:28, 4 December 2009 (CET)<br />
<br />
----<br />
<br />
I noticed your user page the list of potential protected pages, and was wondering if [[Irc]] has been considered?<br />
--[[User:Gen2ly|Gen2ly]] 10:12, 11 December 2009 (EST)<br />
<br />
:For clarification; my list of consists of protected pages I've wished to edit -- not a complete list of protected pages ([[Special:ProtectedPages]]). [[IRC Channel]] is tagged with an ominous warning against editing! ;)<br />
<br />
:-- [[User:Pointone|pointone]] 18:01, 11 December 2009 (EST)<br />
<br />
----<br />
<br />
Got dayum, pointione. Good work ;) [[User:Pwd|pwd]] 23:01, 15 December 2009 (EST)<br />
<br />
==2 reports==<br />
*What do you think about the usefulness of [[Template:Article_summary_link_1x|this template]]? ([[Template_talk:Article_summary_link_1x|discussion]])<br />
*I just wanted to point out that the [[Official Arch Linux Install Guide]] article still uses an obsolete i18n_entry template.<br />
:-- [[User:Kynikos|Kynikos]] 10:01, 11 March 2011 (EST)<br />
<br />
:I've had a number of users contact me regarding the i18n links on the Official Arch Linux Install Guide. It is maintained in AIF git; I will not edit the wiki page directly. However, I've just finally gotten around to submitting a patch to the arch-releng mailing list. <br />
<br />
:Thanks for the gentle prodding. <tt>;)</tt> -- [[User:Pointone|pointone]] 17:54, 11 March 2011 (EST)<br />
<br />
==Section-specific request templates==<br />
:"''e.g. Template:ExpandSection, Template:MoveSection? Would such templates be useful?''"<br />
Splitting templates like that adds to more work when keeping up with the wiki's status on what needs to be done. Simply alter the existing expand/move article templates so that they refer to ''article/section'' instead of just ''article''. [[User:Pwd|pwd]] 22:43, 17 December 2009 (EST)<br />
<br />
==Padding==<br />
By padding I mean the space to right that renders on every single article on this wiki, and this is ''still'' there. This has less to do with suggestions to the [[Main Page]] but it seems like the central place for suggestions that affect everything, the same with the link captions. [[User:Dres|Dres]] 17:54, 14 January 2010 (EST)<br />
<br />
==To wiki or not to wiki?==<br />
Please unlock [[AUR User Guidelines]].<br />
I hope that "high traffic/semi official" isn't the only reason that you locked it. The AUR is not even officially supported. Was there a history of vandalism or anything? It seems that pages are getting locked more often. It's difficult to get community participation if they are locked out. Thanks for reading. - [[User:Louipc|louipc]] 22:31, 4 February 2010 (EST)<br />
<br />
:Sorry; I re-protected the page upon restoration after being overwritten by [[AUR - uživatelský průvodce (Česky)]] (it was protected prior to this incident). I agree that the page should be unlocked, though; this was an oversight.<br />
<br />
:-- [[User:Pointone|pointone]] 23:41, 4 February 2010 (EST)<br />
<br />
::Well, I don't blame you for maintaining the status quo. Thanks for the quick response unlocking it. I appreciate it. - [[User:Louipc|louipc]] 18:43, 5 February 2010 (EST)<br />
<br />
==Category:Laptops==<br />
This was already done with a pywikipedia bot, check the history in most of the laptop articles. heh, [[User:Dres|Dres]] 22:42, 4 February 2010 (EST)<br />
<br />
==Please unlock==<br />
I noticed you were the last to edit. [[AUR Trusted User Guidelines]] Are you able to unlock, or perhaps grant me privileges to edit it? Thanks. - [[User:Louipc|louipc]] 15:00, 12 March 2010 (EST)<br />
<br />
== Please restore "Maven" page ==<br />
<br />
Your reason for deleting was no content; (pacman -S maven). That's not entirely true, though. I wanted to have the "jre" package and suns java packages, not openjdk, in which case I needed to install maven by hand, which is what the wiki page you deleted explained how to do.<br />
<br />
:Page content was:<br />
<br />
<pre><br />
Maven is a software project build automation tool.<br />
<br />
== Installing ==<br />
<br />
=== With openjdk ===<br />
<br />
pacman -S maven<br />
<br />
=== With Sun's jdk ===<br />
<br />
See this guide: http://usingmaven.bachew.net/manually-install-maven-on-linux<br />
</pre><br />
<br />
:#Users should not be recommended to manually install software; let pacman track it for you.<br />
:#The page needs more content. Perhaps a more detailed description of what Maven can do.<br />
:#The <tt>maven</tt> package from [community] works fine for me with the <tt>jre</tt> package (Sun) from [community] -- are you sure manual installation is necessary?<br />
:#Please categorize new pages.<br />
<br />
:Feel free to recreate the page with these notes in mind.<br />
<br />
:-- [[User:Pointone|pointone]] 08:09, 22 April 2010 (EDT)<br />
----<br />
pointone, is there some mechanism for reporting abuse? Jheena789 added [http://wiki.archlinux.org/index.php?title=ArchTrack&oldid=112550|unrelated link spam to a page]. Perhaps the account should be deleted? I have already undid the change, but wanted to be proactive. Thanks! -- [[User:Ryooichi|Ryooichi]] 06:30, 23 July 2010 (EDT)<br />
<br />
:You can report vandalism using the [[Spammers]] page, or by contacting one of the [[ContactList|admins]] directly. Thanks for reporting this incident.<br />
<br />
:-- [[User:Pointone|pointone]] 09:33, 23 July 2010 (EDT)<br />
<br />
== Thanks for the pointer ==<br />
<br />
Thanks for making me aware of my biased edits. I've fixed them so they are neutral and simply inform users of different possibilities so that they can make the best decision based on what they like. [[User:Trusktr|Trusktr]] 02:18, 31 August 2010 (EDT)<br />
<br />
== Thanks for the tips ==<br />
<br />
Thanks for the pointers, I was feeling a little lost regarding the headings and syntax and so forth.<br />
<br />
Regarding the slim options, I didn't cut and paste them, I downloaded the latest source code, looked at it a bit, and ran this command to get the options:<br />
<nowiki>sed -n 's/^.*option("\([^"]*\)","\([^"]*\)".*$/\1\t\2/p' slim-1.3.2/cfg.cpp</nowiki><br />
And I don't think slim is updated very often, it's just a port of login.app to begin with, and it's very simple code-wise. The syslog-ng page I copied much of from the gentoo wiki, but I helped write the article on the gentoo wiki. Anyway, appreciate you taking the time!<br />
<br />
Also, not sure if I am supposed to reply to your note here or on my talk page.. <br />
<br />
[[User:AskApache|AskApache]] 01:39, 2 November 2010 (EDT)<br />
<br />
<br />
=== Any editing suggestions ===<br />
Hey if you want to you could go through my wiki contributions real quick and help me to fix my bad wiki habits.. Or any other suggestions about what I should do differently would be a great help to me.. just if you notice anything, thanks. [[User:AskApache|AskApache]] 17:49, 16 November 2010 (EST)<br />
<br />
== Do we accept usernames like [[User:ArchisForFaggots|this one]]? ==<br />
<br />
[[User:Karol|Karol]] 09:18, 8 April 2011 (EDT)<br />
<br />
:No. Thanks for reporting it. -- [[User:Pointone|pointone]] 18:11, 8 April 2011 (EDT)<br />
<br />
== Templates: love them or hate them? ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=GNOME_3&diff=136095&oldid=prev +1 for [[Template:Cli]] hate] -- [[User:Karol|Karol]] 09:24, 8 April 2011 (EDT)<br />
:What do you propose? Removing the template altogether? What about [[Template:Command]]? -- [[User:Kynikos|Kynikos]] 13:40, 8 April 2011 (EDT)<br />
::Why do we have [[Template:Cli]] anyway? To get white letters on a dark background? You can add formatting and blinking cursor inside the code parts using the old way (prefixing the code line with a space):<br />
'''<font color=red>[</font><font color=green>user@host</font><font color=red> ~]$ <nowiki>{{Cursor}}</nowiki></font>'''<br />
::[[Template:Cli]] is not rendered using <nowiki><pre></nowiki> tags so it won't behave as expected with user-defined rules like <tt>pre { font-size:1.3em !important; }</tt>.<br />
::[[Template:Command]] has some sense to it so it can stay. I view it as the commandline equivalent of [[Template:File]].<br />
::If we decide that e.g. a template is OK, do we need to revert edits such as this one? It's not a personal wiki, so you can't remove things just because you don't like it. -- [[User:Karol|Karol]] 14:23, 8 April 2011 (EDT)<br />
:::Well, with respect to that specific article, it seems [https://wiki.archlinux.org/index.php?title=GNOME_3&diff=next&oldid=136089 he put that template in first], and he himself then removed it, so in my opinion it's completely forgivable. -- [[User:Kynikos|Kynikos]] 15:55, 8 April 2011 (EDT)<br />
::::That's what happens when you don't e-mail the author of the discussed edit ... Consider that part of the case closed. -- [[User:Karol|Karol]] 16:16, 8 April 2011 (EDT)<br />
:::About Cli, I happen to quite like it, and I would have many other positive or negative opinions on other templates, but I think that users could never come to a point of agreement over aesthetic matters: either a coherent style is imposed by the admins, or we will have to get definitively used to style variations among the articles (which is not necessarily a bad thing, to some extent). -- [[User:Kynikos|Kynikos]] 15:55, 8 April 2011 (EDT)<br />
::::I am not personally a fan of [[Template:Cli]] but as you say, style is a tricky subject. In cases like this, I defer to the primary/most active maintainer of a page to determine its style. -- [[User:Pointone|pointone]] 18:21, 8 April 2011 (EDT)<br />
::::I'm not using the wiki a lot so it doesn't overly bother me and I can always use a firefox boomkarklet to zap the colors but the only benefit I can see of using it over the one-space-at-the-beginning-of-the-line-style is you can indent it easily:<br />
::::<nowiki>{{Cli|foo}}</nowiki> -- [[User:Karol|Karol]] 16:16, 8 April 2011 (EDT)<br />
:::::See? There's always a good side to everything! ^^ In my opinion, the problem is not directly about templates, but about font/box style: for what I have seen, there are 2 main "things" that still need to be styled in a much more coherent way: cli code and file text. Cli code has &lt;pre&gt;, Cli, Command and Codeline (4 different styles) while file text has &lt;pre&gt;, File and I would also add Filename in this list. I think that these 2 groups should be immediately identifiable and distinguishable at first sight: for cli code my proposal would be a similar style to that at stackoverflow.com (both block and inline, this would require 2 templates, but with the same background and font style); for file text I would try a yellowish background for the file name (both inline and block) and very light grey for the content; if filename were to be omitted, only the grey part should be showed (this would be 2/3 templates: inline for filename, block for filename + content and possibly another block for content only). Man, all this would be easier to do than to explain XD Maybe I will reword it better tomorrow -- [[User:Kynikos|Kynikos]] 18:15, 8 April 2011 (EDT)<br />
Sorry, I'm doing this very rapidly, anyway these examples should explain my idea better than 10^9 words:<br />
<br />
This is an example of inline style for code and file text:<br />
<br />
bla bla bla bla bla <span style="padding: 1px 4px; background-color:#ddddff; font-family:monospace; font-size:1.1em; color:#222;">codeline args</span> bla bla bla bla <span style="padding: 1px 4px; background-color:#ffff99; font-family:monospace; font-size:1.1em; color:#222;">/path/to/filename</span> bla bla bla bla bla.<br />
<br />
This is a block element for cli code:<br />
<br />
<p style="padding:6px; border: 1px solid #bbbbff; background-color:#ddddff; font-family:monospace; font-size:1.1em; color:#222;">$ code code<br><br />
dbe56v ne4g5fe4 eg45e<br><br />
xdrtgd g5edeht gddgdr</p><br />
<br />
This is a block element for file text with file name:<br />
<br />
<p style="padding:6px; border: 1px solid #bbbbff; margin-bottom:0; background-color:#ffff99; font-family:monospace; font-size:1.1em; color:#222;">/path/to/filename<br />
</p><br />
<p style="padding:6px; border: 1px dashed #bbbbff; margin-top:0; border-top:none; background-color:#f5f5f5; font-family:monospace; font-size:1.1em; color:#222;">1 sf5se de4g5ed4<br><br />
2 de56e e5gt<br><br />
3 d45ge d45her5<br><br />
...</p><br />
<br />
...and this is file text without file name:<br />
<br />
<p style="padding:6px; border: 1px dashed #bbbbff; background-color:#f5f5f5; font-family:monospace; font-size:1.1em; color:#222;">1 sf5se de4g5ed4<br><br />
2 de56e e5gt<br><br />
3 d45ge d45her5<br><br />
...</p><br />
<br />
Please, '''note that these are just examples''', take them as bare brainstorming ideas, nothing even close to be definitive, ok? ;) -- [[User:Kynikos|Kynikos]] 06:24, 9 April 2011 (EDT)<br />
<br />
Sorry, I forgot to mention that this idea follows my previous post, and would make sense only if a precise style were defined by the admins and had to be respected through all the articles -- [[User:Kynikos|Kynikos]] 06:30, 9 April 2011 (EDT)<br />
:I'm not sure I like the colors but as I know how to disable them, I don't mind (I know those are only examples). Just make sure it doesn't look too much like Box BLUE template: {{Box BLUE||foo: bar}} -- [[User:Karol|Karol]] 08:08, 9 April 2011 (EDT)<br />
::I don't want to talk about colors, borders..., those would be the last things to choose: what do you think of the idea of having standard color association for code (in the example blueish) and file text (in the example yellowish), both for block and inline elements? I absolutely don't want to create other templates, that'd be completely nonsense: I am trying to propose the implementation of a standard official style for the articles. -- [[User:Kynikos|Kynikos]] 09:42, 9 April 2011 (EDT)<br />
:::I think it's a great idea, as long as the colors differ from ones used in the other templates, like Note or Box. -- [[User:Karol|Karol]] 10:19, 9 April 2011 (EDT)<br />
::::Well, now we can wait to see if Pointone or other admins release an official style guide, and in that case this formatting could be discussed further. -- [[User:Kynikos|Kynikos]] 12:34, 11 April 2011 (EDT)<br />
:::::Thinking in more detail about templates and formatting, I wonder: do we need to separate "code" and "file" formatting? Originally (that is, before I started updating and reorganizing the template namespace) there was codeline, filename, command, file, and kernel. These were all created at the beginning of 2008. I see the need for only three distinct forms of code formatting: <code>inline code,</code> <pre>block elements,</pre> and "combo" boxes like templates command, file, and kernel.<br />
:::::Would you be opposed to the consolidation of code formatting templates? -- [[User:Pointone|pointone]] 12:07, 13 April 2011 (EDT)<br />
::::::Of course you have the last word, but yes, I would oppose unless "combo" boxes are "consolidated" too, otherwise that would look incoherent to me: this solution could lead to a very KISS approach, keeping only 3 templates, but only if, as I've said, combo boxes are involved too.<br />
::::::My approach was completely different, not differentiating formatting depending on *where* (inline/block) or *how* (simple/combo) a piece of code appears in the article, but basing all the (visual) differences '''mainly''' on *what* that code is: that's why I was asking for consolidating block code formattings with their respective inline counterparts. This solution would prioritize merging '''styles''' before '''templates'''.<br />
::::::Anyway, whether you choose officially one solution or the other, it will be a nice improvement to the current situation. -- [[User:Kynikos|Kynikos]] 13:11, 13 April 2011 (EDT)<br />
:::::::Both solutions are valid, and, as Kynikos wrote, both would be a step forward from the current situation. I don't mind Pointone's version but I don't think we have to limit ourselves that much as some people might like visually differentiating editing a file from typing a command.<br />
:::::::I would like to see some order and consistency in templates and [[User:pointone/Style Guide | general (visual?) style]] but I'm not against either of the proposed solutions. -- [[User:Karol|Karol]] 13:52, 13 April 2011 (EDT)<br />
::::::::@Pointone: seeing your attempt in the [[Sandbox]] I try to report again the example of [http://stackoverflow.com/ stackoverflow.com], which originally inspired me the idea of inline/block code style similarity; by the way, I don't know if this behaviour can be enabled in the wiki, but there inline code is automatically formatted by enclosing it in backticks (`inline code`). -- [[User:Kynikos|Kynikos]] 20:12, 13 April 2011 (EDT)<br />
:::::::::I've taken a look to [[User:pointone|your attempts]], and tried something by myself too: [[User:Kynikos/Random formatting ideas]]. To be honest, I find your version of the "combo" box still incoherent, because it changes the default color for code, which should be that light blue/cyan. I've come up with some alternatives. -- [[User:Kynikos|Kynikos]] 13:31, 14 April 2011 (EDT)<br />
<br />
=="pacman -Syu package"==<br />
[https://wiki.archlinux.org/index.php?title=GNOME_3&diff=prev&oldid=136237 This could be a result] of not having an official package installation syntax after the introduction of "pacman -Syu package": pepole could start forgetting what "y" and "u" even mean, and always repeat them unnecessarily... Also, [[GNOME 3#Upgrade from the current gnome 2.32 |in the previous section]], pacman -Syu is used separately from the package: is it ok? -- [[User:Kynikos|Kynikos]] 13:40, 8 April 2011 (EDT)<br />
:I suppose a basic style guide is in order. Along the same lines, I'd also like for wiki editors to stop assuming yaourt as the de facto AUR helper and perhaps something regarding template use/etiquette. (Continues musing...) Any thoughts? -- [[User:Pointone|pointone]] 20:45, 8 April 2011 (EDT)<br />
::You already know my thoughts on "pacman -Syu": keep it separate from "pacman -S package", even at the cost of writing to "first update the system with pacman -Syu" at the beginning of each article.<br />
::About AUR packages, I would force the use of makepkg and pacman -U on all wiki articles (ok, I'm using yaourt too, but users should be aware that the U in AUR means ''unsupported'').<br />
::About templates read the previous discussion. -- [[User:Kynikos|Kynikos]] 06:36, 9 April 2011 (EDT)<br />
<br />
== Deleted Cmd Template? ==<br />
<br />
Hey I went to look at the [https://wiki.archlinux.org/index.php?title=Template:Cmd&action=edit&redlink=1 cmd template we made] and it was deleted, I would really like to be able to recover the source from that template, is there any way you can undelete it or send me the source code from it? Also, I still could really use a template like that and the cli and command templates don't cut it for reasons listed on the deleted Cmd templates talk page. I'd also like to get the source code from the examples I added to the talk.<br />
[[User:AskApache|AskApache]] 09:55, 9 April 2011 (EDT)<br />
<br />
:Recovered. -- [[User:Pointone|pointone]] 13:06, 10 April 2011 (EDT)<br />
::Since this is practically a duplicate template, couldn't you just <tt>&lt;nowiki&gt;</tt> the template code (thus making it a normal page and not polluting the templates namespace) and invite him to use the [[Template:Sandbox]] page? -- [[User:Kynikos|Kynikos]] 12:30, 11 April 2011 (EDT)<br />
<br />
== Start [[Help:Style]]? (the Style Guide saga) ==<br />
(this is a continuation of the various discussions on a possible style guide) What if we started contributing to a [[Help:Style]] page? At the moment we could mark it as unofficial at the top, but we could find agreements there on article styles and once you think it can go official we can start applying it to the wiki. -- [[User:Kynikos|Kynikos]] 05:01, 2 May 2011 (EDT)<br />
:Please, do! I feel like this is something that could be combined with [[Help:Reading]] which deals primarily with style, as well. -- [[User:Pointone|pointone]] 20:43, 2 May 2011 (EDT)<br />
::Done, maybe until the page itself has not reached a sufficient level of organization it shouldn't be publicized much, not to involve too many users and rushing things excessively. -- [[User:Kynikos|Kynikos]] 09:37, 3 May 2011 (EDT)<br />
<br />
== i18n category naming ==<br />
<br />
Both English category names and localized category names are using in my language's(SimpChinese) wiki.<br />
<br />
Is it better to use "English Title (Language)" as artical naming? --[[User:Cuihao|Cuihao]] 05:34, 2 May 2011 (EDT)<br />
<br />
:Short answer: Yes. I responded to your [https://bbs.archlinux.org/viewtopic.php?id=117961 forum thread] in more detail. -- [[User:Pointone|pointone]] 20:44, 2 May 2011 (EDT)<br />
<br />
== GNOME 3 talk page? ==<br />
What happened to GNOME 3 talk page, which now should be in [[Talk:GNOME]]? -- [[User:Kynikos|Kynikos]] 04:55, 11 May 2011 (EDT)<br />
:Looks like you've just solved it. -- [[User:Kynikos|Kynikos]] 09:05, 11 May 2011 (EDT)<br />
<br />
== Sorry ==<br />
<br />
I have not read the page cited, now translated to facilitate it. [[Help:I18n (Português)]]<br />
<br />
== PolicyKit article ==<br />
<br />
I have put in some work on the [[PolicyKit]] article which you flagged as needing expansion back in april 2011. I am not sure if I should go ahead and remove the flagging (or if it can reasonably be said to no longer need it?) or ask you to do it? Thanks. [[User:Madchine|Madchine]] ([[User talk:Madchine|talk]]) 16:38, 20 July 2012 (UTC)</div>Madchinehttps://wiki.archlinux.org/index.php?title=User_talk:Pointone&diff=213772User talk:Pointone2012-07-20T16:38:04Z<p>Madchine: /* PolicyKit article */ new section</p>
<hr />
<div>You reverted my changes to Beginners'_Guide/Extra#Message_bus, saying "rc.d script is preferred method of interacting with daemons)". Please correct me if I'm wrong, but I believe the correct call for the rc.d script is '/etc/rc.d/dbus start', not the current '/etc/rc.d start dbus'.<br />
<br />
[[User:Wake|Wake]] 21:09, 3 February 2012 (EST)<br />
<br />
:Since May 2011, Arch Linux includes the {{ic|/usr/sbin/rc.d}} script that can be used to interface with so-called "rc.d" scripts in {{ic|/etc/rc.d}}. Running {{ic|/etc/rc.d/dbus start}} is functionally equivalent to running {{ic|/usr/sbin/rc.d start dbus}}. See also: [http://www.archlinux.org/news/initscripts-update-1/ initcripts-update-1], [http://www.archlinux.org/news/initscripts-update-2/ initscripts-update-2], [http://projects.archlinux.org/initscripts.git/tree/rc.d rc.d @ initscripts.git].<br />
<br />
:In the name of consistency, all daemon operations on the wiki should use the rc.d executable.<br />
<br />
:-- [[User:Pointone|pointone]] 12:29, 4 February 2012 (EST)<br />
<br />
:: Thanks for the explanation. I added the full path (/usr/sbin/rc.d) so it won't trip other Arch newbies up.<br />
::[[User:Wake|Wake]] 08:35, 9 February 2012 (EST)<br />
<br />
----<br />
Thank you for pointing that out, I can't believe I missed the Romanian ArchWiki. I just went straight to the English version. <br />
<br />
Sorry for my late reply , I had some problems with my Internet supplier and couldn't check my e-mails.<br />
<br />
<br />
<br />
--[[User:Thras0|Thras0]] 02:02, 14 November 2011 (EST)<br />
<br />
<br />
Thanks for your remind about blank page deletion.<br />
<br />
[[User:warren|warren]] 13:00,18 May 2011 (TW, Asia)<br />
<br />
----<br />
<br />
Thanks for your work on the netcfg documentation!<br />
<br />
[[User:Iphitus|Iphitus]] 20:18, 6 March 2010 (EST)<br />
<br />
----<br />
<br />
Hi and thanks for the good work wrt templates.<br />
I wanted first to get the green/red light for my idea and then proceed w/ adding the templates to the articles that beg for them. Many wiki pages are just a wall of grey text.<br />
<br />
[[User:Karol|Karol]] 17:05, 31 May 2009 (EDT)<br />
<br />
----<br />
<br />
Thanks for fixing Compact TOC! I don't know much about templates/markup. [[User:Manolo|manolo]] 18:49, 10 November 2009 (EST)<br />
<br />
----<br />
<br />
Kudos for cleaning up package-building articles! --[[User:Bhobbit|Bhobbit]] 00:57, 26 November 2009 (EST)<br />
<br />
----<br />
<br />
Really good cleanup and update on Fake RAID article. Thanks. --[[User:Loosec|Loosec]] 12:28, 4 December 2009 (CET)<br />
<br />
----<br />
<br />
I noticed your user page the list of potential protected pages, and was wondering if [[Irc]] has been considered?<br />
--[[User:Gen2ly|Gen2ly]] 10:12, 11 December 2009 (EST)<br />
<br />
:For clarification; my list of consists of protected pages I've wished to edit -- not a complete list of protected pages ([[Special:ProtectedPages]]). [[IRC Channel]] is tagged with an ominous warning against editing! ;)<br />
<br />
:-- [[User:Pointone|pointone]] 18:01, 11 December 2009 (EST)<br />
<br />
----<br />
<br />
Got dayum, pointione. Good work ;) [[User:Pwd|pwd]] 23:01, 15 December 2009 (EST)<br />
<br />
==2 reports==<br />
*What do you think about the usefulness of [[Template:Article_summary_link_1x|this template]]? ([[Template_talk:Article_summary_link_1x|discussion]])<br />
*I just wanted to point out that the [[Official Arch Linux Install Guide]] article still uses an obsolete i18n_entry template.<br />
:-- [[User:Kynikos|Kynikos]] 10:01, 11 March 2011 (EST)<br />
<br />
:I've had a number of users contact me regarding the i18n links on the Official Arch Linux Install Guide. It is maintained in AIF git; I will not edit the wiki page directly. However, I've just finally gotten around to submitting a patch to the arch-releng mailing list. <br />
<br />
:Thanks for the gentle prodding. <tt>;)</tt> -- [[User:Pointone|pointone]] 17:54, 11 March 2011 (EST)<br />
<br />
==Section-specific request templates==<br />
:"''e.g. Template:ExpandSection, Template:MoveSection? Would such templates be useful?''"<br />
Splitting templates like that adds to more work when keeping up with the wiki's status on what needs to be done. Simply alter the existing expand/move article templates so that they refer to ''article/section'' instead of just ''article''. [[User:Pwd|pwd]] 22:43, 17 December 2009 (EST)<br />
<br />
==Padding==<br />
By padding I mean the space to right that renders on every single article on this wiki, and this is ''still'' there. This has less to do with suggestions to the [[Main Page]] but it seems like the central place for suggestions that affect everything, the same with the link captions. [[User:Dres|Dres]] 17:54, 14 January 2010 (EST)<br />
<br />
==To wiki or not to wiki?==<br />
Please unlock [[AUR User Guidelines]].<br />
I hope that "high traffic/semi official" isn't the only reason that you locked it. The AUR is not even officially supported. Was there a history of vandalism or anything? It seems that pages are getting locked more often. It's difficult to get community participation if they are locked out. Thanks for reading. - [[User:Louipc|louipc]] 22:31, 4 February 2010 (EST)<br />
<br />
:Sorry; I re-protected the page upon restoration after being overwritten by [[AUR - uživatelský průvodce (Česky)]] (it was protected prior to this incident). I agree that the page should be unlocked, though; this was an oversight.<br />
<br />
:-- [[User:Pointone|pointone]] 23:41, 4 February 2010 (EST)<br />
<br />
::Well, I don't blame you for maintaining the status quo. Thanks for the quick response unlocking it. I appreciate it. - [[User:Louipc|louipc]] 18:43, 5 February 2010 (EST)<br />
<br />
==Category:Laptops==<br />
This was already done with a pywikipedia bot, check the history in most of the laptop articles. heh, [[User:Dres|Dres]] 22:42, 4 February 2010 (EST)<br />
<br />
==Please unlock==<br />
I noticed you were the last to edit. [[AUR Trusted User Guidelines]] Are you able to unlock, or perhaps grant me privileges to edit it? Thanks. - [[User:Louipc|louipc]] 15:00, 12 March 2010 (EST)<br />
<br />
== Please restore "Maven" page ==<br />
<br />
Your reason for deleting was no content; (pacman -S maven). That's not entirely true, though. I wanted to have the "jre" package and suns java packages, not openjdk, in which case I needed to install maven by hand, which is what the wiki page you deleted explained how to do.<br />
<br />
:Page content was:<br />
<br />
<pre><br />
Maven is a software project build automation tool.<br />
<br />
== Installing ==<br />
<br />
=== With openjdk ===<br />
<br />
pacman -S maven<br />
<br />
=== With Sun's jdk ===<br />
<br />
See this guide: http://usingmaven.bachew.net/manually-install-maven-on-linux<br />
</pre><br />
<br />
:#Users should not be recommended to manually install software; let pacman track it for you.<br />
:#The page needs more content. Perhaps a more detailed description of what Maven can do.<br />
:#The <tt>maven</tt> package from [community] works fine for me with the <tt>jre</tt> package (Sun) from [community] -- are you sure manual installation is necessary?<br />
:#Please categorize new pages.<br />
<br />
:Feel free to recreate the page with these notes in mind.<br />
<br />
:-- [[User:Pointone|pointone]] 08:09, 22 April 2010 (EDT)<br />
----<br />
pointone, is there some mechanism for reporting abuse? Jheena789 added [http://wiki.archlinux.org/index.php?title=ArchTrack&oldid=112550|unrelated link spam to a page]. Perhaps the account should be deleted? I have already undid the change, but wanted to be proactive. Thanks! -- [[User:Ryooichi|Ryooichi]] 06:30, 23 July 2010 (EDT)<br />
<br />
:You can report vandalism using the [[Spammers]] page, or by contacting one of the [[ContactList|admins]] directly. Thanks for reporting this incident.<br />
<br />
:-- [[User:Pointone|pointone]] 09:33, 23 July 2010 (EDT)<br />
<br />
== Thanks for the pointer ==<br />
<br />
Thanks for making me aware of my biased edits. I've fixed them so they are neutral and simply inform users of different possibilities so that they can make the best decision based on what they like. [[User:Trusktr|Trusktr]] 02:18, 31 August 2010 (EDT)<br />
<br />
== Thanks for the tips ==<br />
<br />
Thanks for the pointers, I was feeling a little lost regarding the headings and syntax and so forth.<br />
<br />
Regarding the slim options, I didn't cut and paste them, I downloaded the latest source code, looked at it a bit, and ran this command to get the options:<br />
<nowiki>sed -n 's/^.*option("\([^"]*\)","\([^"]*\)".*$/\1\t\2/p' slim-1.3.2/cfg.cpp</nowiki><br />
And I don't think slim is updated very often, it's just a port of login.app to begin with, and it's very simple code-wise. The syslog-ng page I copied much of from the gentoo wiki, but I helped write the article on the gentoo wiki. Anyway, appreciate you taking the time!<br />
<br />
Also, not sure if I am supposed to reply to your note here or on my talk page.. <br />
<br />
[[User:AskApache|AskApache]] 01:39, 2 November 2010 (EDT)<br />
<br />
<br />
=== Any editing suggestions ===<br />
Hey if you want to you could go through my wiki contributions real quick and help me to fix my bad wiki habits.. Or any other suggestions about what I should do differently would be a great help to me.. just if you notice anything, thanks. [[User:AskApache|AskApache]] 17:49, 16 November 2010 (EST)<br />
<br />
== Do we accept usernames like [[User:ArchisForFaggots|this one]]? ==<br />
<br />
[[User:Karol|Karol]] 09:18, 8 April 2011 (EDT)<br />
<br />
:No. Thanks for reporting it. -- [[User:Pointone|pointone]] 18:11, 8 April 2011 (EDT)<br />
<br />
== Templates: love them or hate them? ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=GNOME_3&diff=136095&oldid=prev +1 for [[Template:Cli]] hate] -- [[User:Karol|Karol]] 09:24, 8 April 2011 (EDT)<br />
:What do you propose? Removing the template altogether? What about [[Template:Command]]? -- [[User:Kynikos|Kynikos]] 13:40, 8 April 2011 (EDT)<br />
::Why do we have [[Template:Cli]] anyway? To get white letters on a dark background? You can add formatting and blinking cursor inside the code parts using the old way (prefixing the code line with a space):<br />
'''<font color=red>[</font><font color=green>user@host</font><font color=red> ~]$ <nowiki>{{Cursor}}</nowiki></font>'''<br />
::[[Template:Cli]] is not rendered using <nowiki><pre></nowiki> tags so it won't behave as expected with user-defined rules like <tt>pre { font-size:1.3em !important; }</tt>.<br />
::[[Template:Command]] has some sense to it so it can stay. I view it as the commandline equivalent of [[Template:File]].<br />
::If we decide that e.g. a template is OK, do we need to revert edits such as this one? It's not a personal wiki, so you can't remove things just because you don't like it. -- [[User:Karol|Karol]] 14:23, 8 April 2011 (EDT)<br />
:::Well, with respect to that specific article, it seems [https://wiki.archlinux.org/index.php?title=GNOME_3&diff=next&oldid=136089 he put that template in first], and he himself then removed it, so in my opinion it's completely forgivable. -- [[User:Kynikos|Kynikos]] 15:55, 8 April 2011 (EDT)<br />
::::That's what happens when you don't e-mail the author of the discussed edit ... Consider that part of the case closed. -- [[User:Karol|Karol]] 16:16, 8 April 2011 (EDT)<br />
:::About Cli, I happen to quite like it, and I would have many other positive or negative opinions on other templates, but I think that users could never come to a point of agreement over aesthetic matters: either a coherent style is imposed by the admins, or we will have to get definitively used to style variations among the articles (which is not necessarily a bad thing, to some extent). -- [[User:Kynikos|Kynikos]] 15:55, 8 April 2011 (EDT)<br />
::::I am not personally a fan of [[Template:Cli]] but as you say, style is a tricky subject. In cases like this, I defer to the primary/most active maintainer of a page to determine its style. -- [[User:Pointone|pointone]] 18:21, 8 April 2011 (EDT)<br />
::::I'm not using the wiki a lot so it doesn't overly bother me and I can always use a firefox boomkarklet to zap the colors but the only benefit I can see of using it over the one-space-at-the-beginning-of-the-line-style is you can indent it easily:<br />
::::<nowiki>{{Cli|foo}}</nowiki> -- [[User:Karol|Karol]] 16:16, 8 April 2011 (EDT)<br />
:::::See? There's always a good side to everything! ^^ In my opinion, the problem is not directly about templates, but about font/box style: for what I have seen, there are 2 main "things" that still need to be styled in a much more coherent way: cli code and file text. Cli code has &lt;pre&gt;, Cli, Command and Codeline (4 different styles) while file text has &lt;pre&gt;, File and I would also add Filename in this list. I think that these 2 groups should be immediately identifiable and distinguishable at first sight: for cli code my proposal would be a similar style to that at stackoverflow.com (both block and inline, this would require 2 templates, but with the same background and font style); for file text I would try a yellowish background for the file name (both inline and block) and very light grey for the content; if filename were to be omitted, only the grey part should be showed (this would be 2/3 templates: inline for filename, block for filename + content and possibly another block for content only). Man, all this would be easier to do than to explain XD Maybe I will reword it better tomorrow -- [[User:Kynikos|Kynikos]] 18:15, 8 April 2011 (EDT)<br />
Sorry, I'm doing this very rapidly, anyway these examples should explain my idea better than 10^9 words:<br />
<br />
This is an example of inline style for code and file text:<br />
<br />
bla bla bla bla bla <span style="padding: 1px 4px; background-color:#ddddff; font-family:monospace; font-size:1.1em; color:#222;">codeline args</span> bla bla bla bla <span style="padding: 1px 4px; background-color:#ffff99; font-family:monospace; font-size:1.1em; color:#222;">/path/to/filename</span> bla bla bla bla bla.<br />
<br />
This is a block element for cli code:<br />
<br />
<p style="padding:6px; border: 1px solid #bbbbff; background-color:#ddddff; font-family:monospace; font-size:1.1em; color:#222;">$ code code<br><br />
dbe56v ne4g5fe4 eg45e<br><br />
xdrtgd g5edeht gddgdr</p><br />
<br />
This is a block element for file text with file name:<br />
<br />
<p style="padding:6px; border: 1px solid #bbbbff; margin-bottom:0; background-color:#ffff99; font-family:monospace; font-size:1.1em; color:#222;">/path/to/filename<br />
</p><br />
<p style="padding:6px; border: 1px dashed #bbbbff; margin-top:0; border-top:none; background-color:#f5f5f5; font-family:monospace; font-size:1.1em; color:#222;">1 sf5se de4g5ed4<br><br />
2 de56e e5gt<br><br />
3 d45ge d45her5<br><br />
...</p><br />
<br />
...and this is file text without file name:<br />
<br />
<p style="padding:6px; border: 1px dashed #bbbbff; background-color:#f5f5f5; font-family:monospace; font-size:1.1em; color:#222;">1 sf5se de4g5ed4<br><br />
2 de56e e5gt<br><br />
3 d45ge d45her5<br><br />
...</p><br />
<br />
Please, '''note that these are just examples''', take them as bare brainstorming ideas, nothing even close to be definitive, ok? ;) -- [[User:Kynikos|Kynikos]] 06:24, 9 April 2011 (EDT)<br />
<br />
Sorry, I forgot to mention that this idea follows my previous post, and would make sense only if a precise style were defined by the admins and had to be respected through all the articles -- [[User:Kynikos|Kynikos]] 06:30, 9 April 2011 (EDT)<br />
:I'm not sure I like the colors but as I know how to disable them, I don't mind (I know those are only examples). Just make sure it doesn't look too much like Box BLUE template: {{Box BLUE||foo: bar}} -- [[User:Karol|Karol]] 08:08, 9 April 2011 (EDT)<br />
::I don't want to talk about colors, borders..., those would be the last things to choose: what do you think of the idea of having standard color association for code (in the example blueish) and file text (in the example yellowish), both for block and inline elements? I absolutely don't want to create other templates, that'd be completely nonsense: I am trying to propose the implementation of a standard official style for the articles. -- [[User:Kynikos|Kynikos]] 09:42, 9 April 2011 (EDT)<br />
:::I think it's a great idea, as long as the colors differ from ones used in the other templates, like Note or Box. -- [[User:Karol|Karol]] 10:19, 9 April 2011 (EDT)<br />
::::Well, now we can wait to see if Pointone or other admins release an official style guide, and in that case this formatting could be discussed further. -- [[User:Kynikos|Kynikos]] 12:34, 11 April 2011 (EDT)<br />
:::::Thinking in more detail about templates and formatting, I wonder: do we need to separate "code" and "file" formatting? Originally (that is, before I started updating and reorganizing the template namespace) there was codeline, filename, command, file, and kernel. These were all created at the beginning of 2008. I see the need for only three distinct forms of code formatting: <code>inline code,</code> <pre>block elements,</pre> and "combo" boxes like templates command, file, and kernel.<br />
:::::Would you be opposed to the consolidation of code formatting templates? -- [[User:Pointone|pointone]] 12:07, 13 April 2011 (EDT)<br />
::::::Of course you have the last word, but yes, I would oppose unless "combo" boxes are "consolidated" too, otherwise that would look incoherent to me: this solution could lead to a very KISS approach, keeping only 3 templates, but only if, as I've said, combo boxes are involved too.<br />
::::::My approach was completely different, not differentiating formatting depending on *where* (inline/block) or *how* (simple/combo) a piece of code appears in the article, but basing all the (visual) differences '''mainly''' on *what* that code is: that's why I was asking for consolidating block code formattings with their respective inline counterparts. This solution would prioritize merging '''styles''' before '''templates'''.<br />
::::::Anyway, whether you choose officially one solution or the other, it will be a nice improvement to the current situation. -- [[User:Kynikos|Kynikos]] 13:11, 13 April 2011 (EDT)<br />
:::::::Both solutions are valid, and, as Kynikos wrote, both would be a step forward from the current situation. I don't mind Pointone's version but I don't think we have to limit ourselves that much as some people might like visually differentiating editing a file from typing a command.<br />
:::::::I would like to see some order and consistency in templates and [[User:pointone/Style Guide | general (visual?) style]] but I'm not against either of the proposed solutions. -- [[User:Karol|Karol]] 13:52, 13 April 2011 (EDT)<br />
::::::::@Pointone: seeing your attempt in the [[Sandbox]] I try to report again the example of [http://stackoverflow.com/ stackoverflow.com], which originally inspired me the idea of inline/block code style similarity; by the way, I don't know if this behaviour can be enabled in the wiki, but there inline code is automatically formatted by enclosing it in backticks (`inline code`). -- [[User:Kynikos|Kynikos]] 20:12, 13 April 2011 (EDT)<br />
:::::::::I've taken a look to [[User:pointone|your attempts]], and tried something by myself too: [[User:Kynikos/Random formatting ideas]]. To be honest, I find your version of the "combo" box still incoherent, because it changes the default color for code, which should be that light blue/cyan. I've come up with some alternatives. -- [[User:Kynikos|Kynikos]] 13:31, 14 April 2011 (EDT)<br />
<br />
=="pacman -Syu package"==<br />
[https://wiki.archlinux.org/index.php?title=GNOME_3&diff=prev&oldid=136237 This could be a result] of not having an official package installation syntax after the introduction of "pacman -Syu package": pepole could start forgetting what "y" and "u" even mean, and always repeat them unnecessarily... Also, [[GNOME 3#Upgrade from the current gnome 2.32 |in the previous section]], pacman -Syu is used separately from the package: is it ok? -- [[User:Kynikos|Kynikos]] 13:40, 8 April 2011 (EDT)<br />
:I suppose a basic style guide is in order. Along the same lines, I'd also like for wiki editors to stop assuming yaourt as the de facto AUR helper and perhaps something regarding template use/etiquette. (Continues musing...) Any thoughts? -- [[User:Pointone|pointone]] 20:45, 8 April 2011 (EDT)<br />
::You already know my thoughts on "pacman -Syu": keep it separate from "pacman -S package", even at the cost of writing to "first update the system with pacman -Syu" at the beginning of each article.<br />
::About AUR packages, I would force the use of makepkg and pacman -U on all wiki articles (ok, I'm using yaourt too, but users should be aware that the U in AUR means ''unsupported'').<br />
::About templates read the previous discussion. -- [[User:Kynikos|Kynikos]] 06:36, 9 April 2011 (EDT)<br />
<br />
== Deleted Cmd Template? ==<br />
<br />
Hey I went to look at the [https://wiki.archlinux.org/index.php?title=Template:Cmd&action=edit&redlink=1 cmd template we made] and it was deleted, I would really like to be able to recover the source from that template, is there any way you can undelete it or send me the source code from it? Also, I still could really use a template like that and the cli and command templates don't cut it for reasons listed on the deleted Cmd templates talk page. I'd also like to get the source code from the examples I added to the talk.<br />
[[User:AskApache|AskApache]] 09:55, 9 April 2011 (EDT)<br />
<br />
:Recovered. -- [[User:Pointone|pointone]] 13:06, 10 April 2011 (EDT)<br />
::Since this is practically a duplicate template, couldn't you just <tt>&lt;nowiki&gt;</tt> the template code (thus making it a normal page and not polluting the templates namespace) and invite him to use the [[Template:Sandbox]] page? -- [[User:Kynikos|Kynikos]] 12:30, 11 April 2011 (EDT)<br />
<br />
== Start [[Help:Style]]? (the Style Guide saga) ==<br />
(this is a continuation of the various discussions on a possible style guide) What if we started contributing to a [[Help:Style]] page? At the moment we could mark it as unofficial at the top, but we could find agreements there on article styles and once you think it can go official we can start applying it to the wiki. -- [[User:Kynikos|Kynikos]] 05:01, 2 May 2011 (EDT)<br />
:Please, do! I feel like this is something that could be combined with [[Help:Reading]] which deals primarily with style, as well. -- [[User:Pointone|pointone]] 20:43, 2 May 2011 (EDT)<br />
::Done, maybe until the page itself has not reached a sufficient level of organization it shouldn't be publicized much, not to involve too many users and rushing things excessively. -- [[User:Kynikos|Kynikos]] 09:37, 3 May 2011 (EDT)<br />
<br />
== i18n category naming ==<br />
<br />
Both English category names and localized category names are using in my language's(SimpChinese) wiki.<br />
<br />
Is it better to use "English Title (Language)" as artical naming? --[[User:Cuihao|Cuihao]] 05:34, 2 May 2011 (EDT)<br />
<br />
:Short answer: Yes. I responded to your [https://bbs.archlinux.org/viewtopic.php?id=117961 forum thread] in more detail. -- [[User:Pointone|pointone]] 20:44, 2 May 2011 (EDT)<br />
<br />
== GNOME 3 talk page? ==<br />
What happened to GNOME 3 talk page, which now should be in [[Talk:GNOME]]? -- [[User:Kynikos|Kynikos]] 04:55, 11 May 2011 (EDT)<br />
:Looks like you've just solved it. -- [[User:Kynikos|Kynikos]] 09:05, 11 May 2011 (EDT)<br />
<br />
== Sorry ==<br />
<br />
I have not read the page cited, now translated to facilitate it. [[Help:I18n (Português)]]<br />
<br />
== PolicyKit article ==<br />
<br />
I have put in some work on the PolicyKit article which you flagged as needing expansion back in april 2011. I am not sure if I should go ahead and remove the flagging (or if it can reasonably be said to no longer need it?) or ask you to do it? Thanks. [[User:Madchine|Madchine]] ([[User talk:Madchine|talk]]) 16:38, 20 July 2012 (UTC)</div>Madchinehttps://wiki.archlinux.org/index.php?title=Talk:Polkit&diff=213771Talk:Polkit2012-07-20T16:30:58Z<p>Madchine: Creation</p>
<hr />
<div>==Expansion objection==<br />
I have tried expanding the article after spending time figuring out how PolicyKit works and I would like to think that the article as it is now is fairly decent and useable. As a final touch I would like to remove the <nowiki>{{Expansion}}</nowiki> box but I am unsure if the objection originally was to the article as a whole or the introduction (which I haven't really touched) and if I should remove it or ask an editor to do so? [[User:Madchine|Madchine]] ([[User talk:Madchine|talk]]) 16:30, 20 July 2012 (UTC)h</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213769Polkit2012-07-20T16:21:30Z<p>Madchine: Added: Limitations</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file.<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Tools==<br />
* {{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference.<br />
<br />
==Limitations==<br />
PolicyKit operates on top of the exisiting permissions systems in linux -- group membership, administrator status -- it does not replace them. The example above prohibited the user jack from using the GParted action, but it does not preclude him running GParted by some means that do not respect PolicyKit, e.g. the command line. Therefore it's probably better to use PolicyKit to expand access to priviledged services for unpriviledged users, rather than to try using it to curtail the rights of (semi-)privileged users. For security purposes, the [[Beginners'_Guide#Sudo|sudoers file]] is still the way to go.<br />
<br />
==Documentation==<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213753Polkit2012-07-20T14:08:53Z<p>Madchine: /* Admin identities */ style</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file.<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Tools==<br />
* {{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference.<br />
<br />
==Documentation==<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213752Polkit2012-07-20T14:07:33Z<p>Madchine: Cleared up old article relics, added 'tools'</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file. {{ic|50-localauthority.conf}} looks like this:<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==Tools==<br />
* {{ic|pkaction}} lists alle the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference.<br />
<br />
==Documentation==<br />
For a more thorough introduction and more advanced features, including globbing, see the man pages of polkit and pklocalauthority:<br />
man polkit<br />
<br />
man pklocalauthority<br />
<br />
==See also==<br />
* [[ConsoleKit]]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213751Polkit2012-07-20T13:56:37Z<p>Madchine: /* Structure */ Added: Admin identities</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute in {{ic|/usr/share/polkit-1/actions}}. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
===Admin identities===<br />
Like the authorities files, configuration works by letting the last read file take precedence over earlier ones. The default configuration for admin identities is contained in the file {{ic|50-localauthority.conf}} so any changes to that configuration should be made by copying the file to, say, {{ic|60-localauthority.conf}} and editing that file. {{ic|50-localauthority.conf}} looks like this:<br />
{{hc|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf|2=<nowiki><br />
# Configuration file for the PolicyKit Local Authority.<br />
#<br />
# DO NOT EDIT THIS FILE, it will be overwritten on update.<br />
#<br />
# See the pklocalauthority(8) man page for more information<br />
# about configuring the Local Authority.<br />
#<br />
<br />
[Configuration]<br />
AdminIdentities=unix-group:wheel<br />
</nowiki>}}<br />
The only part to edit (once copied) is the right part of the equation: As whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root's password. The format of the user identification is the same as the one used in designating authorities. The Arch default is to make all members of the group '''wheel''' administrators.<br />
<br />
==ConsoleKit==<br />
Please note: to correct issues with automount and shutdown, please check the [[ConsoleKit]] page.<br />
<br />
==Practical examples==<br />
How to let all users in the [[Users and Groups|group]] {{ic|wheel}} have the same privileges as root (so you do not have to enter the root password, but the wheel user's password):<br />
<br />
Installing {{AUR|polkit-use-wheel-group}} from the [[Arch User Repository|AUR]] will create this file automatically.<br />
<br />
Create the following file:<br />
{{hc|/etc/polkit-1/localauthority.conf.d/60-localauthority.conf|<nowiki><br />
[Configuration]<br />
AdminIdentities=unix-user:0;unix-group:wheel<br />
</nowiki>}}<br />
<br />
{{Note|Higher numbers are prioritized over lower numbers.}}<br />
<br />
To let users alice and bob perform all [[PackageKit]] actions (but not necessarily other PolicyKit actions), create the following file:<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/10-my-pkgkit-policy.pkla|<nowiki><br />
[Let Wheel Use PackageKit]<br />
Identity=unix-user:alice;unix-user:bob<br />
Action=org.freedesktop.packagekit.*<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=auth_self_keep<br />
</nowiki>}}<br />
<br />
{{Note|You can use the command {{ic|pkaction}} to list all actions defined in your system.}}</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213745Polkit2012-07-20T13:16:15Z<p>Madchine: /* Structure */ Added: Authorities</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
===Authorities===<br />
Authorizations that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/localauthority/50-local.d}} should be used. The authority files are read in alphabetical/numerical order, where later files take precedence, so that one configuration file can be relied upon to overrule another, e.g. <br />
10_allow_all_users_group_members_to_automount_without_authentification.pkla<br />
15_but_not_jack.pkla<br />
The layout of the .pkla files is fairly self-explanatory:<br />
[Ban users jack and jill from using gparted]<br />
Identity=unix-user:jack;unix-user:jill<br />
Action=org.archlinux.pkexec.gparted<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=no<br />
An authorization needs to be preceded by a heading enclosed in square paratheses. The follows an identification with pairs of '''unix-user''' or '''unix-group''' and the name. Use semicolons to separate the pairs to include more than one user or group. The designating name of the action is the one from the action's id attribute. The three Result-settings mirror those from the action definition. Here we have overruled the default auth_admin setting and disallowed jack and jill from running gparted.<br />
<br />
==ConsoleKit==<br />
Please note: to correct issues with automount and shutdown, please check the [[ConsoleKit]] page.<br />
<br />
==Practical examples==<br />
How to let all users in the [[Users and Groups|group]] {{ic|wheel}} have the same privileges as root (so you do not have to enter the root password, but the wheel user's password):<br />
<br />
Installing {{AUR|polkit-use-wheel-group}} from the [[Arch User Repository|AUR]] will create this file automatically.<br />
<br />
Create the following file:<br />
{{hc|/etc/polkit-1/localauthority.conf.d/60-localauthority.conf|<nowiki><br />
[Configuration]<br />
AdminIdentities=unix-user:0;unix-group:wheel<br />
</nowiki>}}<br />
<br />
{{Note|Higher numbers are prioritized over lower numbers.}}<br />
<br />
To let users alice and bob perform all [[PackageKit]] actions (but not necessarily other PolicyKit actions), create the following file:<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/10-my-pkgkit-policy.pkla|<nowiki><br />
[Let Wheel Use PackageKit]<br />
Identity=unix-user:alice;unix-user:bob<br />
Action=org.freedesktop.packagekit.*<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=auth_self_keep<br />
</nowiki>}}<br />
<br />
{{Note|You can use the command {{ic|pkaction}} to list all actions defined in your system.}}</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213742Polkit2012-07-20T12:48:37Z<p>Madchine: /* Structure */ Added: Actions</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML .policy files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Authorities''' are defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, an authority file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
===Actions===<br />
Each action is defined in an <action> tag in a .policy file. The {{ic|org.archlinux.pkexec.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"><br />
<policyconfig><br />
<br />
<action id="org.archlinux.pkexec.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[dbus]], the '''message''' tag is the explanation to the user when authentification is required and the '''icon_name''' is sort of obvious. <br />
<br />
The default tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. Allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* '''no''': The user is not authorized to carry out the action. There is therefore no need for authentification.<br />
* '''yes''': The user is authorized to carry out the action without any authentification.<br />
* '''auth_self''': Authentication is required but the user need not be an administrative user.<br />
* '''auth_admin''': Authentication as an administrative user is require.<br />
* '''auth_self_keep''': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* '''auth_admin_keep''': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
==ConsoleKit==<br />
Please note: to correct issues with automount and shutdown, please check the [[ConsoleKit]] page.<br />
<br />
==Practical examples==<br />
How to let all users in the [[Users and Groups|group]] {{ic|wheel}} have the same privileges as root (so you do not have to enter the root password, but the wheel user's password):<br />
<br />
Installing {{AUR|polkit-use-wheel-group}} from the [[Arch User Repository|AUR]] will create this file automatically.<br />
<br />
Create the following file:<br />
{{hc|/etc/polkit-1/localauthority.conf.d/60-localauthority.conf|<nowiki><br />
[Configuration]<br />
AdminIdentities=unix-user:0;unix-group:wheel<br />
</nowiki>}}<br />
<br />
{{Note|Higher numbers are prioritized over lower numbers.}}<br />
<br />
To let users alice and bob perform all [[PackageKit]] actions (but not necessarily other PolicyKit actions), create the following file:<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/10-my-pkgkit-policy.pkla|<nowiki><br />
[Let Wheel Use PackageKit]<br />
Identity=unix-user:alice;unix-user:bob<br />
Action=org.freedesktop.packagekit.*<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=auth_self_keep<br />
</nowiki>}}<br />
<br />
{{Note|You can use the command {{ic|pkaction}} to list all actions defined in your system.}}</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213741Polkit2012-07-20T11:57:46Z<p>Madchine: /* Structure */</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Policies''' ared defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, a policy file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration for deciding if the user trying to carry out an action is or is not an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default).<br />
<br />
==ConsoleKit==<br />
Please note: to correct issues with automount and shutdown, please check the [[ConsoleKit]] page.<br />
<br />
==Practical examples==<br />
How to let all users in the [[Users and Groups|group]] {{ic|wheel}} have the same privileges as root (so you do not have to enter the root password, but the wheel user's password):<br />
<br />
Installing {{AUR|polkit-use-wheel-group}} from the [[Arch User Repository|AUR]] will create this file automatically.<br />
<br />
Create the following file:<br />
{{hc|/etc/polkit-1/localauthority.conf.d/60-localauthority.conf|<nowiki><br />
[Configuration]<br />
AdminIdentities=unix-user:0;unix-group:wheel<br />
</nowiki>}}<br />
<br />
{{Note|Higher numbers are prioritized over lower numbers.}}<br />
<br />
To let users alice and bob perform all [[PackageKit]] actions (but not necessarily other PolicyKit actions), create the following file:<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/10-my-pkgkit-policy.pkla|<nowiki><br />
[Let Wheel Use PackageKit]<br />
Identity=unix-user:alice;unix-user:bob<br />
Action=org.freedesktop.packagekit.*<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=auth_self_keep<br />
</nowiki>}}<br />
<br />
{{Note|You can use the command {{ic|pkaction}} to list all actions defined in your system.}}</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213733Polkit2012-07-20T11:09:34Z<p>Madchine: Added: 'Structure'</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==Structure==<br />
PolicyKit definitions can be divided into three kinds:<br />
* '''Actions''' are defined in XML files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way (see [http://askubuntu.com/a/1399 askubuntu.com] for a bad example)<br />
* '''Policies''' ared defined in INI-like .pkla files. They are found in two places: 3rd party packages can use {{ic|/var/lib/polkit-1}} (though few if any do) and {{ic|/etc/polkit-1}} is for local configuration. The .pkla files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, a policy file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.<br />
* '''Admin identities''' are set in {{ic|/etc/polkit-1/localauthority.conf.d}} One of the basic points of using PolicyKit is determining whether or not a user needs to authenticate (possibly as an administrative user) or not in order to get permission to carry out the action. PolicyKit therefore has a specific configuration to determine who is an administrative user. Common definitions are 'only root user' or 'all members of wheel' (the Arch default)<br />
<br />
==ConsoleKit==<br />
Please note: to correct issues with automount and shutdown, please check the [[ConsoleKit]] page.<br />
<br />
==Practical examples==<br />
How to let all users in the [[Users and Groups|group]] {{ic|wheel}} have the same privileges as root (so you do not have to enter the root password, but the wheel user's password):<br />
<br />
Installing {{AUR|polkit-use-wheel-group}} from the [[Arch User Repository|AUR]] will create this file automatically.<br />
<br />
Create the following file:<br />
{{hc|/etc/polkit-1/localauthority.conf.d/60-localauthority.conf|<nowiki><br />
[Configuration]<br />
AdminIdentities=unix-user:0;unix-group:wheel<br />
</nowiki>}}<br />
<br />
{{Note|Higher numbers are prioritized over lower numbers.}}<br />
<br />
To let users alice and bob perform all [[PackageKit]] actions (but not necessarily other PolicyKit actions), create the following file:<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/10-my-pkgkit-policy.pkla|<nowiki><br />
[Let Wheel Use PackageKit]<br />
Identity=unix-user:alice;unix-user:bob<br />
Action=org.freedesktop.packagekit.*<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=auth_self_keep<br />
</nowiki>}}<br />
<br />
{{Note|You can use the command {{ic|pkaction}} to list all actions defined in your system.}}</div>Madchinehttps://wiki.archlinux.org/index.php?title=Polkit&diff=213724Polkit2012-07-20T10:17:36Z<p>Madchine: Added: "PolicyKit vs. polkit"</p>
<hr />
<div>[[Category:Security]]<br />
{{Expansion}}<br />
<br />
From [http://hal.freedesktop.org/docs/PolicyKit/introduction.html PolicyKit Library Reference Manual]:<br />
<br />
:''PolicyKit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. It does not imply or rely on any exotic kernel features.''<br />
<br />
PolicyKit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy. <br />
<br />
PolicyKit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how -- if at all -- those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
==PolicyKit vs. polkit==<br />
In the development of PolicyKit, major changes were introduced around version 0.92. In order to make the distinction clear between the way the old and the new versions worked, the new ones are referred to as 'polkit' rather than PolicyKit. Searching for PolicyKit on the web will mostly point to outdated documentation and lead to confusion and frustration, e.g. [http://mdzlog.alcor.net/2010/06/27/navigating-the-policykit-maze/]. The main distinction between PolicyKit and polkit is the abandonment of single-file configuration in favour of directory-based configuration, i.e. there is no PolicyKit.conf.<br />
<br />
==ConsoleKit==<br />
Please note: to correct issues with automount and shutdown, please check the [[ConsoleKit]] page.<br />
<br />
==Practical examples==<br />
How to let all users in the [[Users and Groups|group]] {{ic|wheel}} have the same privileges as root (so you do not have to enter the root password, but the wheel user's password):<br />
<br />
Installing {{AUR|polkit-use-wheel-group}} from the [[Arch User Repository|AUR]] will create this file automatically.<br />
<br />
Create the following file:<br />
{{hc|/etc/polkit-1/localauthority.conf.d/60-localauthority.conf|<nowiki><br />
[Configuration]<br />
AdminIdentities=unix-user:0;unix-group:wheel<br />
</nowiki>}}<br />
<br />
{{Note|Higher numbers are prioritized over lower numbers.}}<br />
<br />
To let users alice and bob perform all [[PackageKit]] actions (but not necessarily other PolicyKit actions), create the following file:<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/10-my-pkgkit-policy.pkla|<nowiki><br />
[Let Wheel Use PackageKit]<br />
Identity=unix-user:alice;unix-user:bob<br />
Action=org.freedesktop.packagekit.*<br />
ResultAny=no<br />
ResultInactive=no<br />
ResultActive=auth_self_keep<br />
</nowiki>}}<br />
<br />
{{Note|You can use the command {{ic|pkaction}} to list all actions defined in your system.}}</div>Madchinehttps://wiki.archlinux.org/index.php?title=Talk:ConsoleKit&diff=213643Talk:ConsoleKit2012-07-19T20:16:56Z<p>Madchine: Created page with "===Non sequitur=== I wanna write a screenplay called 'Children of Compiz'. Think 'Children of the corn' but with flashier graphics. ~~~~"</p>
<hr />
<div>===Non sequitur===<br />
I wanna write a screenplay called 'Children of Compiz'. Think 'Children of the corn' but with flashier graphics.<br />
[[User:Madchine|Madchine]] ([[User talk:Madchine|talk]]) 20:16, 19 July 2012 (UTC)</div>Madchinehttps://wiki.archlinux.org/index.php?title=Ampache&diff=188765Ampache2012-03-11T11:38:48Z<p>Madchine: /* Configuration */ wiki-syntax</p>
<hr />
<div>{{i18n|Ampache}}<br />
[[Category:Web Server (English)]]<br />
<br />
This document describes how to set up Ampache on an Arch Linux LAMP server. Ampache is a Web-based Audio file manager. It is implemented with MySQL, and PHP. It allows you to view, edit, and play your audio files via the web. It has support for playlists, artist and album views, album art, random play, playback via Http/On the Fly Transcoding and Downsampling, Ampache is excellent if you want to be able to listen to your music collection anywhere. <br />
<br />
== Installation ==<br />
<br />
You'll need three things to run Ampache. A webserver, PHP and MySQL. Please refere to the [[LAMP]] wiki for more information.<br />
<br />
Ampache is available in the AUR, if you haven't had any experience using the AUR the [[AUR User Guidelines]] is recommended reading.<br />
<br />
=== Currently maintained packages ===<br />
<br />
There are currently two Ampache packages.<br />
<br />
* [http://aur.archlinux.org/packages.php?ID=23128 Ampache's latest stable release]<br />
<br />
* [http://aur.archlinux.org/packages.php?ID=7241 Ampache's latest development release]<br />
<br />
== Configuration ==<br />
PHP will be installed as a dependency of ampache. You will need to edit the PHP configuration file /etc/php/php.ini in order to enable iconv support for ampache.<br />
<br />
Uncomment (remove the initial semi-colon from) the following line in the php.ini file:<br />
<br />
;extension=iconv.so<br />
<br />
When Ampache is installed, point your browser to [http://localhost/ampache http://localhost/ampache] (substitute the address of your Ampache server for localhost if you didn't install it locally).<br />
<br />
If you encounter any problems here, use http://localhost/ampache/test.php to double check your configuration. <br />
<br />
* On the first page choose your the installation language.<br />
<br />
* On the second page enter the following:<br />
** Desired Database Name - Choose a uniquer name the you'll recognize when you edit your mysql databases.<br />
** MySQL Hostname - localhost is fine.<br />
** MySQL Administrative Username - root is the default<br />
** MySQL Administrative Password - root's password.<br />
** Create Database User for New Database? - Yes.<br />
** Ampache Database Username - Same thing here, unique and recognizable.<br />
** Ampache Database User Password - Please note that this is only MySQL info, this is not your Ampache user account<br />
**Overwrite Existing <br />
**Use Existing Database<br />
<br />
* On the third page you're going to edit the ampache.cfg.php file<br />
** Web Path - Your patch to ampache.<br />
** Desired Database Name - Same as on the second page.<br />
** MySQL Hostname - localhost.<br />
** MySQL Username - Same as Ampache Database Username, or root if you didn't create a database user.<br />
** MySQL Password - MySQL Username's password.<br />
* Press write config<br />
* Move the ampache.cfg.php to the ampache/config directory.<br />
* Press check for config.<br />
<br />
* On the fourth page you're going to create an admin account. This step is self explanatory.<br />
** Username<br />
** Password<br />
** Confirm Password<br />
<br />
== Troubleshooting ==<br />
<br />
If you're having problems adding catalogs, please check your permission settings. More catalog toubleshooting [http://ampache.org/wiki/install:catalog#permissions here].<br />
<br />
If you're still having problems check your Open basedir setting in php.ini. You can either comment out the open_basedir all together or add the directory in which your files reside. The second option is preferred. To comment out a line all you need to do is add a semicolon at the beginning of the line.<br />
<pre><br />
;open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/<br />
</pre><br />
<br />
== Tips & Tricks ==<br />
<br />
=== Logging ===<br />
<br />
Is something not working as intended? Let's get some logging going!<br />
<br />
There are five levels of logging in Ampache, 5 being the highest.<br />
<br />
To enable logging you just need to set the debug value to true and set debug_level to your desired level.<br />
<br />
<pre><br />
; Debug<br />
; If this is enabled Ampache will get really chatty<br />
; warning this can crash browser during catalog builds due to <br />
; the amount of text that is dumped out this will also cause <br />
; ampache to write to the log file<br />
; DEFAULT: false<br />
debug = "true"<br />
<br />
; Debug Level<br />
; This should always be set in conjunction with the<br />
; debug option, it defines how prolific you want the<br />
; debugging in ampache to be. values are 1-5. <br />
; 1 == Errors only<br />
; 2 == Error + Failures (login attempts etc.)<br />
; 3 == ??<br />
; 4 == ?? (Profit!)<br />
; 5 == Information (cataloging progress etc.)<br />
; DEFAULT: 5<br />
debug_level = 5<br />
</pre><br />
<br />
Last thing you'll have to do is specify where you want the log to reside. Remember that the http user needs write permissons to the file.<br />
<br />
<pre><br />
; Path to Log File<br />
; This defines where you want ampache to log events to<br />
; this will only happen if debug is turned on. Do not<br />
; include trailing slash. You will need to make sure that<br />
; your HTTP server has write access to the specified directory<br />
; DEFAULT: NULL<br />
log_path = "/var/log/ampache"<br />
</pre><br />
<br />
=== Transcoding ===<br />
<br />
If you want to use Ampache's on the fly transcoding you'll need the packages specified in config/ampache.cfg, the packages needed for transcoding the most common audio file formats are listed in Ampache stable's .install file. You'll also need to configure the specific lines in ampache.cfg.<br />
<br />
The following example enables m4a transcoding to mp3.<br />
<br />
Please note that you'll need both lame, used for all audio file formats, and faad, m4a specific, installed.<br />
<br />
<pre><br />
; List of filetypes to transcode<br />
transcode_m4a = true<br />
transcode_m4a_target = mp3 <br />
<br />
; These are the commands that will be run to transcode the file<br />
transcode_cmd_m4a = "faad -f 2 -w %FILE% | lame -r -b %SAMPLE% -S - -"<br />
</pre><br />
<br />
=== Downsampling ===<br />
<br />
Downsampling requires the same packages as transcoding so follow the steps above for each audio file format you need. The example above enables downsampling of m4a files.<br />
<br />
You'll also need to uncomment and specify the minimum and maximum bitrate you prefer.<br />
<br />
<pre><br />
max_bit_rate = 576<br />
<br />
min_bit_rate = 48<br />
</pre><br />
<br />
== Using with Amarok==<br />
* [http://ampache.org/wiki/config:amarok Amarok and Ampache] <br />
<br />
Using the ampache web interface, we need to allow API access to Ampache from our local network. To do this go to the Admin tab and then click on Show Acls. Find Add API / RPC Host and click on it. <br />
Name your ACL Entry, ("My Network" for ex). If you want API + Streaming + Web Interface access pick RPC + All under type. <br />
<br />
In amarok, go to Settings and then Services. Make sure the Ampache Service is enabled and then click Settings button on Ampache plugin. <br />
* Name : This is an internal name for Amarok, up to you.<br />
* Server : This is the fully qualified address for your Ampache server including the http://. For example, a valid server would look like http://ampache.org/demo.<br />
* Username : This is your username to the Ampache web interface.<br />
* Password : This is your password to the Ampache web interface<br />
<br />
== More Resources ==<br />
<br />
A useful link to the Ampache [http://www.ampache.org/wiki/ wiki]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Ampache&diff=188764Ampache2012-03-11T11:37:36Z<p>Madchine: /* Configuration */ clarification and cleanup</p>
<hr />
<div>{{i18n|Ampache}}<br />
[[Category:Web Server (English)]]<br />
<br />
This document describes how to set up Ampache on an Arch Linux LAMP server. Ampache is a Web-based Audio file manager. It is implemented with MySQL, and PHP. It allows you to view, edit, and play your audio files via the web. It has support for playlists, artist and album views, album art, random play, playback via Http/On the Fly Transcoding and Downsampling, Ampache is excellent if you want to be able to listen to your music collection anywhere. <br />
<br />
== Installation ==<br />
<br />
You'll need three things to run Ampache. A webserver, PHP and MySQL. Please refere to the [[LAMP]] wiki for more information.<br />
<br />
Ampache is available in the AUR, if you haven't had any experience using the AUR the [[AUR User Guidelines]] is recommended reading.<br />
<br />
=== Currently maintained packages ===<br />
<br />
There are currently two Ampache packages.<br />
<br />
* [http://aur.archlinux.org/packages.php?ID=23128 Ampache's latest stable release]<br />
<br />
* [http://aur.archlinux.org/packages.php?ID=7241 Ampache's latest development release]<br />
<br />
== Configuration ==<br />
PHP will be installed as a dependency of ampache. You will need to edit the PHP configuration file /etc/php/php.ini in order to enable iconv support for ampache.<br />
<br />
Uncomment (remove the initial semi-colon from) the following line in the php.ini file:<br />
<br />
# ;extension=iconv.so<br />
<br />
When Ampache is installed, point your browser to [http://localhost/ampache http://localhost/ampache] (substitute the address of your Ampache server for localhost if you didn't install it locally).<br />
<br />
If you encounter any problems here, use http://localhost/ampache/test.php to double check your configuration. <br />
<br />
* On the first page choose your the installation language.<br />
<br />
* On the second page enter the following:<br />
** Desired Database Name - Choose a uniquer name the you'll recognize when you edit your mysql databases.<br />
** MySQL Hostname - localhost is fine.<br />
** MySQL Administrative Username - root is the default<br />
** MySQL Administrative Password - root's password.<br />
** Create Database User for New Database? - Yes.<br />
** Ampache Database Username - Same thing here, unique and recognizable.<br />
** Ampache Database User Password - Please note that this is only MySQL info, this is not your Ampache user account<br />
**Overwrite Existing <br />
**Use Existing Database<br />
<br />
* On the third page you're going to edit the ampache.cfg.php file<br />
** Web Path - Your patch to ampache.<br />
** Desired Database Name - Same as on the second page.<br />
** MySQL Hostname - localhost.<br />
** MySQL Username - Same as Ampache Database Username, or root if you didn't create a database user.<br />
** MySQL Password - MySQL Username's password.<br />
* Press write config<br />
* Move the ampache.cfg.php to the ampache/config directory.<br />
* Press check for config.<br />
<br />
* On the fourth page you're going to create an admin account. This step is self explanatory.<br />
** Username<br />
** Password<br />
** Confirm Password<br />
<br />
== Troubleshooting ==<br />
<br />
If you're having problems adding catalogs, please check your permission settings. More catalog toubleshooting [http://ampache.org/wiki/install:catalog#permissions here].<br />
<br />
If you're still having problems check your Open basedir setting in php.ini. You can either comment out the open_basedir all together or add the directory in which your files reside. The second option is preferred. To comment out a line all you need to do is add a semicolon at the beginning of the line.<br />
<pre><br />
;open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/<br />
</pre><br />
<br />
== Tips & Tricks ==<br />
<br />
=== Logging ===<br />
<br />
Is something not working as intended? Let's get some logging going!<br />
<br />
There are five levels of logging in Ampache, 5 being the highest.<br />
<br />
To enable logging you just need to set the debug value to true and set debug_level to your desired level.<br />
<br />
<pre><br />
; Debug<br />
; If this is enabled Ampache will get really chatty<br />
; warning this can crash browser during catalog builds due to <br />
; the amount of text that is dumped out this will also cause <br />
; ampache to write to the log file<br />
; DEFAULT: false<br />
debug = "true"<br />
<br />
; Debug Level<br />
; This should always be set in conjunction with the<br />
; debug option, it defines how prolific you want the<br />
; debugging in ampache to be. values are 1-5. <br />
; 1 == Errors only<br />
; 2 == Error + Failures (login attempts etc.)<br />
; 3 == ??<br />
; 4 == ?? (Profit!)<br />
; 5 == Information (cataloging progress etc.)<br />
; DEFAULT: 5<br />
debug_level = 5<br />
</pre><br />
<br />
Last thing you'll have to do is specify where you want the log to reside. Remember that the http user needs write permissons to the file.<br />
<br />
<pre><br />
; Path to Log File<br />
; This defines where you want ampache to log events to<br />
; this will only happen if debug is turned on. Do not<br />
; include trailing slash. You will need to make sure that<br />
; your HTTP server has write access to the specified directory<br />
; DEFAULT: NULL<br />
log_path = "/var/log/ampache"<br />
</pre><br />
<br />
=== Transcoding ===<br />
<br />
If you want to use Ampache's on the fly transcoding you'll need the packages specified in config/ampache.cfg, the packages needed for transcoding the most common audio file formats are listed in Ampache stable's .install file. You'll also need to configure the specific lines in ampache.cfg.<br />
<br />
The following example enables m4a transcoding to mp3.<br />
<br />
Please note that you'll need both lame, used for all audio file formats, and faad, m4a specific, installed.<br />
<br />
<pre><br />
; List of filetypes to transcode<br />
transcode_m4a = true<br />
transcode_m4a_target = mp3 <br />
<br />
; These are the commands that will be run to transcode the file<br />
transcode_cmd_m4a = "faad -f 2 -w %FILE% | lame -r -b %SAMPLE% -S - -"<br />
</pre><br />
<br />
=== Downsampling ===<br />
<br />
Downsampling requires the same packages as transcoding so follow the steps above for each audio file format you need. The example above enables downsampling of m4a files.<br />
<br />
You'll also need to uncomment and specify the minimum and maximum bitrate you prefer.<br />
<br />
<pre><br />
max_bit_rate = 576<br />
<br />
min_bit_rate = 48<br />
</pre><br />
<br />
== Using with Amarok==<br />
* [http://ampache.org/wiki/config:amarok Amarok and Ampache] <br />
<br />
Using the ampache web interface, we need to allow API access to Ampache from our local network. To do this go to the Admin tab and then click on Show Acls. Find Add API / RPC Host and click on it. <br />
Name your ACL Entry, ("My Network" for ex). If you want API + Streaming + Web Interface access pick RPC + All under type. <br />
<br />
In amarok, go to Settings and then Services. Make sure the Ampache Service is enabled and then click Settings button on Ampache plugin. <br />
* Name : This is an internal name for Amarok, up to you.<br />
* Server : This is the fully qualified address for your Ampache server including the http://. For example, a valid server would look like http://ampache.org/demo.<br />
* Username : This is your username to the Ampache web interface.<br />
* Password : This is your password to the Ampache web interface<br />
<br />
== More Resources ==<br />
<br />
A useful link to the Ampache [http://www.ampache.org/wiki/ wiki]</div>Madchinehttps://wiki.archlinux.org/index.php?title=Talk:Wine&diff=187269Talk:Wine2012-03-03T01:42:40Z<p>Madchine: /* Clarification */ new section</p>
<hr />
<div>== WINEARCH=win32 ==<br />
<br />
Wine seems to treat empty folders as win64 prefix folders, making it confusing to create win32 prefixes in empty folders. It gives the error [wine: WINEARCH set to win32 but '/home/wine/photoshop' is a 64-bit installation].<br />
Perhaps we should add a note about this? See this bugreport http://bugs.winehq.org/show_bug.cgi?id=29661 -- [[User:JKAbrams|JKAbrams]] 14:35, 20 Jan 2012 (EDT)<br />
<br />
Yup, feel free to add that note. --[[User:Svenstaro|Svenstaro]] 12:24, 20 January 2012 (EST)<br />
<br />
== Clarification ==<br />
<br />
"To clarify the above, the i686 package Wine will work exactly like a x86_64 package Wine with a win32 WINEPREFIX with no ill effects." <br />
<br />
This confused me omre than clarified anything. My suspicion - if i had any - would be that 64 bit system posing as a 32 bit system might be problematic. But this sentence seems to 'reassure' readers that things will work -- even if you're not using the elaborate method mentioned above. Huh? Clarification, please...<br />
--[[User:Madchine|Madchine]] 20:42, 2 March 2012 (EST)</div>Madchinehttps://wiki.archlinux.org/index.php?title=User:Madchine&diff=145649User:Madchine2011-06-11T15:14:23Z<p>Madchine: </p>
<hr />
<div>A linux user since Ubuntu 6.06 and an arch user for some three years, I couldn't swear off linux if 'ping' was the only functionality left. After going back and forth between Arch and Ubuntu, I finally (and, I suspect, irrevocably) defected when 10.10 turned out to be incompatible with my preferred tty-auto-login method. The last straw, so to speak. <br />
<br />
I have in a previous life and guise contributed (to) some articles on startup files but decided on a new account to get it into line with my overall internet presence. I am not planning on any great contributions but it's nice to be logged in and ready to edit just-in-case :)<br />
<br />
A few key words:<br />
* A lover of all things ncurses (ncmpcpp, vim, htop, myman, mc being particular favourites)<br />
* A TTY aesthethics fan (you know ctrl+alt+Fx....) <br />
* An enthusiastic Openbox user, a less so GNOME 3 user<br />
* An occasional Python programmer<br />
<br />
<br />
"''Futhermore, I think terminus should be the default arch TTY font...''"</div>Madchinehttps://wiki.archlinux.org/index.php?title=User:Madchine&diff=145648User:Madchine2011-06-11T15:12:55Z<p>Madchine: creation</p>
<hr />
<div>A linux user since Ubuntu 6.06 and an arch user for some three years, I couldn't swear off linux if 'ping' was the only functionality left. After going back and forth between Arch and Ubuntu, I finally (and, I suspect, irrevocably) defected when 10.10 turned out to be incompatible with my preferred tty-auto-login method. The final drop, so to speak. <br />
<br />
I have in a previous life and guise contributed (to) some articles on startup files but decided on a new account to get it into line with my overall internet presence. I am not planning on any great contributions but it's nice to be logged in and ready to edit just-in-case :)<br />
<br />
A few key words:<br />
* A lover of all things ncurses (ncmpcpp, vim, htop, myman, mc being particular favourites)<br />
* A TTY aesthethics fan (you know ctrl+alt+Fx....) <br />
* An enthusiastic Openbox user, a less so GNOME 3 user<br />
* An occasional Python programmer<br />
<br />
<br />
"''Futhermore, I think terminus should be the default arch TTY font...''"</div>Madchinehttps://wiki.archlinux.org/index.php?title=ASUS_Eee_PC_901&diff=143203ASUS Eee PC 9012011-05-30T20:29:26Z<p>Madchine: /* Speedstep */ info for eee 900 and 904 users</p>
<hr />
<div>[[Category:ASUS (English)]]<br />
This page contains instructions, tips, pointers, and links for installing and configuring Arch Linux on the ASUS EEE 901 PC.<br />
<br />
Most of the article can also be applied to eeepc-models which are similar to the 901 such the 901H, 1000 and 1000H. If you discover a configuration or software option applicable to a certain model that differs from what is described in this article, please add it, with a note about which model the suggestion pertains to.<br />
<br />
== Install Tips for the Asus Eee PC ==<br />
<br />
This wiki page supplements these pages: '''[[Beginners Guide]]''', the '''[[Official Arch Linux Install Guide|Official Install Guide]]''', and '''[[Installing Arch Linux on the Asus EEE PC]]'''. Please refer to those guides ''first'' before following the eeepc-specific pointers on this page.<br />
<br />
Most of this information is from the Arch Forum EEE 901 [http://bbs.archlinux.org/viewtopic.php?id=53464 thread]. Consult this thread, and other resources on the Arch forum, for more details and discussion.<br />
<br />
== Kernel Installation and configuration == <br />
<br />
Follow the Arch Linux installation Guide to install the latest stock distribution from USB media or CDROM. Install the '''BASE''' and '''DEVEL''' package categories. Reboot your PC.<br />
<br />
'''Note''': The wireless driver (rt2860sta) does not seem to work with the latest linux kernel (2.26.32). The current arch release (2009-8) still uses the 2.26.30 kernel. Install arch using the '''core''' images, rather than netinstall. This will install the 2.26.30 linux kernel, rather than downloading the latest kernel from the repositories. Then, after rebooting, and before upgrading any package, include <br />
IgnorePkg=kernel26<br />
in /etc/pacman.conf, to avoid upgrading the kernel.<br />
<br />
As of the advent of kernel 2.6.30, all drivers needed for the EEE 901 are included in the Arch Linux stock kernel. In case you would like to compile your own kernel, make sure that you build the following modules:<br />
<br />
Network card:<br />
Device Drivers - Ethernet (1000Mbit) - Atheros L1E Gigabit Ethernet support<br />
WiFi card:<br />
Device Drivers - Staging Drivers - Ralink 2860<br />
Eee Hotkey stuff:<br />
Device Drivers - X86 Platform Specific Device Drivers - EeePC Hotkey Driver<br />
Video Camera:<br />
Device Drivers - Multimedia Devices - Video Capture adapters - V4L USB devices - USB Video Class (UVC)<br />
Sound Card:<br />
Device Drivers - Sound card support - ALSA - PCI Sound devices - Intel HDA - Build Realtek HDA codec<br />
Touchpad:<br />
Device Drivers - Input Device support - Mice - PS/2 mouse - Synaptics & Elantech PS/2 protocol ext.<br />
<br />
For flawless operation with the eee-control FSB frequency changing mechanism, you have to compile<br />
Device Drivers - I2C support - I2C Hardware Bus support - Intel 82801 (ICH)<br />
as a _module_ (thanks for the hint, dieghen89, even though I never got to include it...)<br />
<br />
For some tricks to speed up udev boot time, see below.<br />
<br />
Blind<br />
<br />
=== Using the Stock kernel ===<br />
This section gives some hints and clues about how to tweak the stock Arch Linux kernel for the EeePC 901. For more general information about building custom Arch Linux kernels, see [[Kernel Compilation]]. <br />
<br />
The stock kernel has some advantages over the custom kernel:<br />
<br />
* The ethernet driver is now available in stock kernel (called: ''Atheros L1E Gigabit Ethernet support''), so no external modules or patching needed<br />
<br />
* As of kernel 2.6.29 the Ralink wireless driver is [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=91980990527258a075361490cecadbb7356fc0d2 included] in the stock kernel (though it is still a work in progress). Just add the '''rt2860sta''' module to /etc/rc.conf and it works out of the box.<br />
<br />
* From kernel '''2.6.33''' on you only need to blacklist rt2800pci in /etc/rc.conf and wireless works flawlessly<br />
<br />
* It is likely that more Asus and EeePC-specific features will be included in future versions of the stock kernel, and current drivers will improve with each kernel release. (Word has it that Linus Torvalds himself bought an EeePc). Chances are that the stock kernel now includes the drivers and features you need for your EeePC.<br />
<br />
* The stock kernel, as part of the core repository, is always available and maintained in a number of mirror repositories.<br />
<br />
==== example .config ====<br />
Here is a sample kernel .config file created for the 1000H with the stock 2.6.27.7 kernel: [http://nopaste.info/3daf27d4f3_nl.html .config].<br />
<br />
You can take it as starting point to build your own kernel. Make sure that the filesystem types you want to use are configured (at the moment this configuration only contains ext2, compiled in, and ext3 as module).<br />
<br />
== OS Configuration ==<br />
<br />
To support the devices listed below, make sure the module '''eeepc_laptop''' is loaded on boot.<br />
<br />
To automatically all the modules needed (including bluetooth, if it is enabled in BIOS, and the ALSA sound drivers), enable autoloading in your /etc/rc.conf:<br />
<br />
MOD_AUTOLOAD="yes"<br />
<br />
=== Networking: Ethernet ===<br />
<br />
Ethernet (wired) network access should work right out of the box with precompiled kernels, or with '''atl1e''' module you built from AUR.<br />
<br />
=== Networking: Wireless ===<br />
After a bios-upgrade the wireless-card of the Eee PC will be disabled by default, so if you have any troubles with wlan check that it is enabled in the bios.<br />
<br />
To enable/disable the wireless card from the command line:<br />
<br />
# enable<br />
echo 1 > /sys/devices/platform/eeepc/wlan<br />
# disable<br />
echo 0 > /sys/devices/platform/eeepc/wlan<br />
<br />
For newer kernels enable/disable wireless the following way:<br />
<br />
# enable<br />
echo 1 > /sys/devices/platform/eeepc/rfkill/rfkill0/state<br />
# disable<br />
echo 0 > /sys/devices/platform/eeepc/rfkill/rfkill0/state<br />
<br />
The precompiled kernels listed above contain a [http://www.itwriting.com/blog/778-fixing-wi-fi-on-asus-eee-pc-901-with-linux.html patched] version of the wifi driver '''rt2860sta''' and it should work with both WEP and WPA. <br />
<br />
If you are compiling the '''rt2860sta''' kernel driver yourself, use the newest (1.8) version of the driver in AUR: http://aur.archlinux.org/packages.php?ID=14557. <br />
<br />
Make sure you have the '''wireless_tools''' package installed, also. You may need to manually download the package from a [[Mirror]] (look in ''core/os/i686/'') and install it locally (e.g. after moving it with a usb-stick to your eeePC) using [[Pacman#Other_Usage|Pacman]].<br />
<br />
There are reported some problems associating an AP with netcfg2 (WEP and open, WPA-PSK works ok). If you experience problems, try another connection manager, for example wicd works fine.<br />
pacman -S wicd<br />
<br />
If you experience problems with the Ralink driver and your connection manager, try using the following script to connect:<br />
<br />
#!/bin/bash<br />
<br />
case "$1" in<br />
start)<br />
sudo ifconfig ra0 up<br />
sudo wpa_supplicant -B -Dwext -ira0 -cwifi_up.conf<br />
sleep 3<br />
sudo dhcpcd ra0<br />
;;<br />
stop)<br />
sudo kill -15 `cat /var/run/dhcpcd-ra0.pid`<br />
sudo rm /var/run/wpa_supplicant/ra0<br />
sudo ifconfig ra0 down<br />
;;<br />
list)<br />
sudo ifconfig ra0 up<br />
sleep 1<br />
sudo iwlist ra0 scanning<br />
sudo ifconfig ra0 down<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|list|restart}" <br />
esac<br />
<br />
exit 0<br />
<br />
Here's a working example wpa_supplicant config file:<br />
<br />
ctrl_interface=/var/run/wpa_supplicant<br />
# change ap_scan to 2 if running into problems<br />
ap_scan=1<br />
fast_reauth=1<br />
eapol_version=1<br />
<br />
network={<br />
key_mgmt=NONE<br />
}<br />
<br />
network={<br />
ssid="WPA"<br />
scan_ssid=1<br />
proto=WPA<br />
key_mgmt=WPA-PSK<br />
pairwise=TKIP<br />
group=TKIP<br />
#psk="passphrase"<br />
psk=hexkey<br />
}<br />
<br />
network={<br />
ssid="WEP"<br />
scan_ssid=1<br />
key_mgmt=NONE<br />
#wep_key0="passphrase"<br />
wep_key0=hexkey<br />
wep_tx_keyidx=0<br />
}<br />
<br />
Your mileage may vary, but experience seems to show that the '''ap_scan=1''' parameter is critical. Try tweaking the other "header" settings, too, if you continue to experience problems.<br />
<br />
=== ACPI (Hotkeys) ===<br />
<br />
==== Option 1: Install the '''[http://aur.archlinux.org/packages.php?ID=23318 acpi-eeepc-generic]''' package from AUR ====<br />
<br />
For this package to work, make sure the '''eeepc_laptop''' and '''rfkill''' modules are loaded at boot.<br />
<br />
Consult the notes included with the install for instructions on configuring <tt>/etc/conf.d/acpi-eeepc-generic.conf</tt>.<br />
<br />
This will enable all the ''Fn + xx'' keys and the four silver hotkey buttons buttons as configured in the default Xandros distribution, with some minor variations. Edit the <tt>/etc/conf.d/acpi-eeepc-generic.conf</tt> file to change or modify the behavior of the function keys.<br />
<br />
==== Option 2: Configure the stock kernel ACPI features ====<br />
<br />
Enable the ASUS_LAPTOP (Device Drivers -> Misc Devices) switch in your kernel config and turn off ACPI_ASUS switch (Power managment options -> ACPI).<br />
<br />
To enable the FN keys, the WLAN and Camera on/off toggles, etc., activate the EEEPC_LAPTOP switch also (Device Drivers -> Misc Devices). <br />
<br />
You can use Robertek's PKGBUILD and files for '''acpi-www901''' at http://robertek.brevnov.net/files/linux/arch/acpi-eee901/ as a base to incorporate the stock kernel modules and ASUS OSD into the ACPI system.<br />
<br />
Note: The kernel interfaces <tt>/proc/acpi/asus</tt> or <tt>/proc/acpi/eee</tt> are not available with the '''eeepc_laptop''' module. The corresponding '''eeepc_laptop''' interfaces are files in: <tt>/sys/devices/platform/eeepc/</tt>. You may need to edit some of the scripts under <tt>/etc/acpi/</tt> to point to the correct paths.<br />
<br />
==== ASUS OSD ====<br />
<br />
Asus OSD is included as part of the '''acpi-eee901''' package. Simply add the command <tt>asusosd &</tt> to your desktop manager startup script, or create the file <tt>/etc/xdg/autostart/asusosd.desktop</tt> with these contents:<br />
<br />
[Desktop Entry]<br />
Encoding=UTF-8<br />
Name=ASUS OSD<br />
Comment=ASUS OSD<br />
Exec=/usr/bin/asusosd<br />
Terminal=false<br />
Type=Application<br />
StartupNotify=false<br />
Hidden=false<br />
<br />
=== Bluetooth ===<br />
<br />
Currently, Bluetooth is not enabled with the ''Fn + F2'' hotkey. To communicate with Bluetooth devices, make sure Bluetooth has been enabled in the BIOS.<br />
<br />
To enable/disable bluetooth from the command line :<br />
<br />
# enable<br />
echo 1 > /sys/devices/platform/eeepc/bt<br />
# disable<br />
echo 0 > /sys/devices/platform/eeepc/bt<br />
<br />
Install the '''bluez''' package. Make sure the '''bluetooth''' module is loaded.<br />
<br />
See the Arch Linux [[Bluetooth]] and [[Bluetooth Mouse]] wiki pages for more information about configuring and using Bluetooth devices.<br />
<br />
=== Webcam ===<br />
<br />
To enable/disable the camera:<br />
<br />
# enable<br />
echo 1 > /sys/devices/platform/eeepc/camera<br />
# disable<br />
echo 0 > /sys/devices/platform/eeepc/camera<br />
<br />
To record video and take photos, you may use '''cheese''' or the '''wxcam''' package (available in the ''edgy'' repository or AUR).<br />
<br />
pacman -S wxcam<br />
<br />
To simply test the camera, you may use <tt>mplayer</tt>:<br />
<br />
mplayer -fps 15 tv://<br />
<br />
The webcam is reported to work with Skype.<br />
<br />
=== Audio ===<br />
<br />
Audio output is enabled with the default ALSA drivers distributed with the kernels. You may need to install the '''alsa-lib''' and '''alsa-utils''' packages to get full functionality.<br />
Make sure the '''snd-hda-intel''' module is loaded.<br />
<br />
Both the microphone and PC speakers should work out-of-the-box with current versions of the kernel and ALSA drivers. A common gotcha: if you're not getting any sound, did you run <tt>alsamixer</tt> and unmute your channels?<br />
<br />
See the Arch Linux [[ALSA]] wiki page for more information about configuring and using ALSA.<br />
<br />
=== X ===<br />
<br />
''<font color="red">This section is out-of-date, and needs to be cleaned up.</font>''<br />
<br />
==== Video ====<br />
<br />
You will need the xf86-video-intel video driver:<br />
pacman -S xf86-video-intel<br />
<br />
To set-up the touchpad, (including two-fingers scrolling & tapping), just install xf86-input-synaptics (no xorg.conf required):<br />
pacman -S xf86-input-synaptics<br />
<br />
Some users have reported problems with vsync and the '''xf86-video-intel''' driver. These problems may be partially solved in the application (see this forum [http://bbs.archlinux.org/viewtopic.php?pid=416645#p416645 post].)<br />
<br />
===== Connecting an external Monitor =====<br />
<br />
The xrandr utility (part of Xorg) can be used to switch into screen modes appropriate either for the EeePC's LCD or an externally connected monitor. Running "xrandr -q" will show you the available output devices and the supported modes. Then run the tool as follows:<br />
<br />
xrandr --output LVDS --off --output VGA --auto # disable LCD, enable monitor<br />
xrandr --output LVDS --auto --output VGA --auto # enable both<br />
etc.<br />
<br />
Your monitor will probably support a bigger resolution than the LCD. To make use of that additional screen space, tell the X server to create an appropriately large framebuffer by adding the "Virtual" directive to the Screen/Display section in /etc/X11/xorg.conf:<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "Card0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Viewport 0 0<br />
Depth 24<br />
Virtual 1600 1200 # max resolution is 1600x1200<br />
EndSubSection<br />
EndSection<br />
<br />
On the LCD, the additional space will be unused, but when switching to the external monitor, the screen will be. Note that some window managers (such as ratpoison) might need to be restarted to realize that the visible screen size has changed.<br />
<br />
===== Letterboxing with XRandR =====<br />
<br />
If you have set up your X server and kernel to use KMS you might have some trouble getting a 800x600 resolution letterboxed (centered) rather than stretched, which might be unpleasant in some programs that don't support 1024x600 such as older games. This is because with KMS the xrandr syntax is a bit different [https://bugs.freedesktop.org/show_bug.cgi?id=24331].<br />
To get a centered 800x600 visual field on your 1024x600 panel run:<br />
$ xrandr --output LVDS1 --set "scaling mode" "Center"<br />
$ xrandr -s 800x600<br />
Replace "800x600" with "1024x600" to go back to the native resolution.<br />
<br />
==== Mouse and Synaptics driver ====<br />
<br />
To enable the Synaptics drivers, first install the synaptics package:<br />
<br />
pacman -S synaptics<br />
<br />
You also need the evdev driver for Xorg:<br />
<br />
pacman -S xf86-input-evdev<br />
<br />
Then make these changes to <tt>/etc/X11/xorg.conf</tt>:<br />
<br />
Section "ServerLayout"<br />
Identifier "ArchLinux"<br />
Screen 0 "Screen0"<br />
InputDevice "keyboard"<br />
InputDevice "mouse"<br />
'''InputDevice "synaptics"'''<br />
EndSection<br />
<br />
[...]<br />
<br />
Section "Files"<br />
'''# RgbPath "/usr/share/X11/rgb"'''<br />
ModulePath "/usr/lib/xorg/modules"<br />
FontPath "/usr/share/fonts/misc"<br />
FontPath "/usr/share/fonts/100dpi:unscaled"<br />
FontPath "/usr/share/fonts/75dpi:unscaled"<br />
FontPath "/usr/share/fonts/TTF"<br />
FontPath "/usr/share/fonts/Type1"<br />
EndSection<br />
<br />
Section "Module"<br />
Load "GLcore"<br />
Load "glx"<br />
Load "record"<br />
Load "dri"<br />
Load "extmod"<br />
Load "xtrap"<br />
Load "dbe"<br />
Load "freetype"<br />
'''Load "synaptics"'''<br />
EndSection<br />
<br />
[...]<br />
<br />
Section "InputDevice"<br />
Identifier "mouse"<br />
Driver "mouse"<br />
Option "Device" "/dev/input/mice"<br />
Option "Protocol" "IMPS/2"<br />
Option "Emulate3Buttons" "yes"<br />
Option "ZAxisMapping" "4 5"<br />
Option "CorePointer"<br />
EndSection<br />
<br />
'''Section "InputDevice"'''<br />
'''Identifier "synaptics"'''<br />
'''Driver "synaptics"'''<br />
'''Option "Device" "/dev/psaux"'''<br />
'''Option "Protocol" "auto-dev"'''<br />
'''Option "PalmDetect" "0"'''<br />
'''Option "SHMConfig" "true"'''<br />
'''Option "SendCoreEvents" "yes"'''<br />
'''Option "RBCornerButton" "0"'''<br />
'''Option "RTCornerButtom" "0"'''<br />
'''Option "TapButton1" "1"'''<br />
'''Option "TapButton2" "2"'''<br />
'''Option "TapButton3" "3"'''<br />
'''Option "AccelFactor" "0.0320"'''<br />
'''Option "MaxSpeed" "0.72"'''<br />
'''Option "MinSpeed" "0.6"'''<br />
'''Option "Emulate3Buttons" "true"'''<br />
'''Option "TouchPadOff" "0"'''<br />
'''Option "LBCornerButton" "2"'''<br />
'''Option "LeftEdge" "60"'''<br />
'''Option "RightEdge" "1070"'''<br />
'''Option "TopEdge" "90"'''<br />
'''Option "BottomEdge" "680"'''<br />
'''Option "VertTwoFingerScroll" "1"'''<br />
'''Option "HorizTwoFingerScroll" "1"'''<br />
'''Option "HorizScrollDelta" "20"'''<br />
'''Option "LockedDrags" "1"'''<br />
'''Option "CoastingSpeed" "0.13"'''<br />
'''Option "CircularScrolling" "1"'''<br />
'''Option "CircScrollTrigger" "8" # 8=Top Left Corner'''<br />
'''EndSection'''<br />
<br />
The latest version of the Elantech touchpad driver patch is available at http://arjan.opmeer.net/elantech/ or here [http://www.mac-how.net/ mac how to] You'll need to apply this patch to your kernel source, then recompile the kernel. This patch has been tested on the 2.6.27.6 and 2.6.27.7 kernels.<br />
<br />
====A complete working set Xorg/HAL config files====<br />
<br />
The latest version of <tt>xserver</tt> recommends using the HAL subsystem to manage X device configurations, in place of <tt>xorg.conf</tt>.<br />
<br />
If it isn't installed already, install HAL, then add '''hal''' to the list of daemons in your <tt>/etc/rc.conf</tt> file:<br />
<br />
pacman -s hal<br />
<br />
Create the following HAL device configuration files for X:<br />
<br />
'''File:''' /etc/hal/fdi/policy/10-keymap.fdi (configure the '''input.xkb.layout''' parameter to match your locale)<br />
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --><br />
<deviceinfo version="0.2"><br />
<device><br />
<match key="info.capabilities" contains="input.keymap"><br />
<append key="info.callouts.add" type="strlist">hal-setup-keymap</append><br />
</match><br />
<br />
<match key="info.capabilities" contains="input.keys"><br />
<merge key="input.xkb.rules" type="string">base</merge><br />
<br />
<merge key="input.xkb.model" type="string">keyboard</merge><br />
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux"><br />
<merge key="input.xkb.model" type="string">evdev</merge><br />
</match><br />
<br />
<merge key="input.xkb.layout" type="string">se</merge><br />
<merge key="input.xkb.variant" type="string" /><br />
<merge key="input.xkb.options" type="string">ctrl:nocaps</merge><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
<br />
'''File:''' /etc/hal/fdi/policy/9-x11-elantech.fdi (configuration for the Elantech touchpad -- <font color="red">could be improved</font>)<br />
<?xml version="1.0" encoding="ISO-8859-1"?><br />
<deviceinfo version="0.2"><br />
<device><br />
<match key="info.capabilities" contains="input.touchpad"><br />
<match key="info.product" contains="Elantech Touchpad"><br />
<merge key="input.x11_driver" type="string">synaptics</merge><br />
<merge key="input.x11_options.SHMConfig" type="string">on</merge><br />
<merge key="input.x11_options.MaxSpeed" type="string">1.00</merge><br />
<merge key="input.x11_options.MinSpeed" type="string">0.75</merge><br />
<merge key="input.x11_options.Emulate3Buttons" type="string">on</merge><br />
<merge key="input.x11_options.VertTwoFingerScroll" type="string">1</merge><br />
<merge key="input.x11_options.HorizTwoFingerScroll" type="string">1</merge><br />
<merge key="input.x11_options.TapButton1" type="string">1</merge><br />
<merge key="input.x11_options.TapButton2" type="string">2</merge><br />
<merge key="input.x11_options.TapButton3" type="string">3</merge><br />
<merge key="input.x11_options.LockedDrags" type="string">1</merge><br />
</match><br />
</match><br />
</device><br />
</deviceinfo><br />
<br />
'''File:''' /etc/X11/xorg.conf<br />
Section "ServerLayout"<br />
Identifier "ArchLinux"<br />
Screen "Screen0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device0"<br />
Driver "intel"<br />
Option "XAANoOffScreenPixmaps" "true"<br />
Option "AccelMethod" "XAA"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "Device0"<br />
EndSection<br />
The <tt>xorg.conf</tt> file is no longer strictly necessary, but some features, such as windowtitles in wmii, run faster if configured here.<br />
<br />
==== Miscellaneous ====<br />
If you don't have an xorg.conf file, and want to configure the keyboard layout on the fly:<br />
<br />
# Set keyboard to cz with qwerty<br />
setxkbmap cz qwerty<br />
<br />
To configure the mouse speed:<br />
# Set mouse movement and acceleration (you need to tweak this to your needs)<br />
xset m 2 1<br />
<br />
== Performance Tips ==<br />
<br />
The following tweaks can be used to improve performance and/or power consumption.<br />
<br />
=== Speedstep ===<br />
<br />
Speedstep is included by default in the Linux 2.6.x kernel.<br />
<br />
The '''zen-eee901''' kernels contain the Speedstep modules. Add '''acpi-cpufreq''' to your MODULES list in <tt>/etc/rc.conf</tt> to enable it on boot, or execute:<br />
<br />
modprobe acpi-cpufreq<br />
<br />
See http://rffr.de/acpi for more information.<br />
<br />
For more information on overclocking the Asus EEE PC line, see http://wiki.eeeuser.com/howto:overclockfsb<br />
<br />
{{Note|Speedstep is applicable to the 901 as it's CPU is of the Intel Atom family. The eee 900 and 904 use an Intel Celeron M CPU and so should use the p4-clockmod module instead. }}<br />
<br />
=== Faster boot and udev ===<br />
To safe a little time with udev during boot, you can edit your '''/etc/rc.conf''' and disable MOD_AUTOLOAD. It should look like this<br />
<br />
MOD_AUTOLOAD="no"<br />
MODULES=(atl1e rt2860sta rfkill acpi-cpufreq pciehp intel_agp snd-hda-intel !snd-pcsp bluetooth)<br />
<br />
In addition, it may be helpful to do the following:<br />
<br />
MODULES=( ... !eeepc_laptop ... )<br />
<br />
and then load that module in the background in '''rc.local''':<br />
<br />
modprobe eeepc_laptop &<br />
<br />
(insert that line)<br />
<br />
=== Boot Booster ===<br />
<br />
Enable Asus Boot Booster feature in BIOS to skip some tests during boot.<br />
<br />
"Boot">"Boot Settings Configuration">"Quick Boot">[Enabled]<br />
<br />
== Appendix ==<br />
=== Hardware Overview for 901 ===<br />
<br />
The following hardware is used in the Asus EEE 901:<br />
<br />
* CPU: 1.6GHz N270 Intel Atom<br />
* RAM: 1024 MB, DDR2 667<br />
* ports: 3x USB, VGA<br />
* LAN/ethernet: Atheros L1e 1000 Mbit<br />
* WLAN: Ralink rt2860 802.11b/g/n<br />
* Bluetooth, webcam 1.3 Mpix<br />
* Card reader: SD, SDHC, MMC<br />
* touchpad: "Multi-touch" elantech<br />
* display: 1024x600 8.9"<br />
* weight: 1 kg<br />
* battery: Li-ion, 6600mAh<br />
* HDD: 4 + 8GB, empty slot for 1,8" (remove of the 8GB module needed)<br />
* Graphics: Intel GM950 core, 945GME chipset<br />
<br />
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)<br />
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)<br />
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)<br />
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)<br />
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)<br />
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)<br />
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)<br />
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)<br />
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)<br />
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) <br />
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)<br />
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)<br />
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)<br />
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)<br />
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)<br />
01:00.0 Network controller: RaLink Device 0781</div>Madchinehttps://wiki.archlinux.org/index.php?title=Brother_HL-2030&diff=142659Brother HL-20302011-05-24T15:27:10Z<p>Madchine: /* Brother drivers */ fix wiki syntax error</p>
<hr />
<div>[[Category:Printers_(English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
This is a small tutorial to make the printer Brother HL-2030 work on Arch.<br />
There are no drivers available from Openprinting.org at the moment for this printer to work in [[CUPS]].<br />
If you previously tried to install the printer in CUPS, remove it.<br />
<br />
=Foomatic: an alternative to the official drivers=<br />
<br />
Note that there is an alternative to the official, Brother-supplied drivers. Using this method, my Brother HL-2030 worked instantly and without any problems. (The following steps are copied from the forum. Thanks to thayer!)<br />
# pacman -S cups foomatic-{db,db-engine,filters}<br />
<br />
Go to http://localhost:631<br />
* Add printer<br />
* Give name<br />
* Select HL-2030 on USB from Device menu<br />
* Select HL-2030/hl1250 foomatic driver (PPD)<br />
* Done<br />
<br />
=Brother drivers=<br />
Brother supplies official linux drivers for the HL-2030. These, however come in the form of RPM packages. They can be installed on Arch in two ways: Either using the [http://aur.archlinux.org/packages.php?ID=14131 AUR PKGBUILD] or manually following these instructions.<br />
<br />
==Download drivers==<br />
First create a temporary directory. Then you must download the official LPR drivers from the Brother website in that directory. Click [http://www.brother.com/cgi-bin/agreement/agreement.cgi?dlfile=http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/lpr_others/brhl2030lpr-2.0.1-1.i386.rpm&lang=English_lpr here] . This is a RPM archive. You have to download the cupswrapper file. Right [http://www.brother.com/cgi-bin/agreement/agreement.cgi?dlfile=http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/cups_wrapper/cupswrapperHL2030-2.0.1-1.i386.rpm&lang=English_gpl here]. This script creates the filters and PPD file for CUPS automatically. It's an RPM archive too.<br />
<br />
==Extracting the RPM files==<br />
Now you need a small script called rpmextract which allows you to get the files included in the RPM you've just downloaded.<br />
Log in as root and execute :<br />
# pacman -S rpmextract<br />
Extract both RPM files :<br />
$ rpmextract.sh brhl2030lpr-2.0.1-1.i386.rpm<br />
$ rpmextract.sh cupswrapperHL2030-2.0.1-1.i386.rpm<br />
It should give you two directories : usr and var.<br />
<br />
==Editing files to make them work with Arch==<br />
Arch Linux uses its own file system organisation, so you have to edit some files. Use your favorite text editor (i.e. vi) to open the file named cupswrapperHL2030-2.0.1. If you created the temporary directory "tmp" in your home, it must be in /home/user/tmp/usr/local/Brother/cupswrapper. In this file, you must replace all the <i>/etc/init.d/</i> occurences by <i>/etc/rc.d/</i>.<br />
Then you have to edit the file usr/local/Brother/inf/setupPrintcap, and replace <i>/etc/printcap.local</i> by <i>/etc/printcap</i>.<br />
<br />
When it's done, copy all the files in their corresponding directories :<br />
# cp -r /home/user/tmp/usr/* /usr<br />
# cp -r /home/user/tmp/var/* /var<br />
<br />
==Installing the driver and printer==<br />
Go into /usr/local/Brother/cupswrapper/ and run the cupswrapper file :<br />
# cd /usr/local/Brother/cupswrapper/<br />
# ./cupswrapperHL2030-2.0.1<br />
It will stop the cups daemon if it's running, and restart it. Now go to the CUPS page - http://localhost:631/ - and in the Administartion category, choose Manage printers. There you should see a HL2030 printer <b>automatically</b> installed and configured. Click to print the test page, and you can hear the sweet sound of your printer.<br />
<br />
==Compatibility with Brother HL-2035==<br />
Brother does not (yet) provide specific drivers for the HL-2035, but the HL-2030 drivers seem to work fine for this model as well. Use at your own risk, though.<br />
<br />
==Common Issues==<br />
If you have done all the steps above, and the printer will either not appear in your [http://localhost:631/ cups interface] or if you want to print sth. the printer will just warm up and then not print anything, the following is reported to have helped:<br />
# install the hal cups utils: <code>pacman -S hal-cups-utils</code><br />
# visit your [http://localhost:631/ cups interface], and under "administration" hit "find new printer". Surprisingly, it should be found. In the next step, choose the ppd file (found in /usr/share/cups/model/HL2030.ppd) and everything should work just fine ...</div>Madchinehttps://wiki.archlinux.org/index.php?title=Brother_HL-2030&diff=142658Brother HL-20302011-05-24T15:25:07Z<p>Madchine: /* Brother drivers */</p>
<hr />
<div>[[Category:Printers_(English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
This is a small tutorial to make the printer Brother HL-2030 work on Arch.<br />
There are no drivers available from Openprinting.org at the moment for this printer to work in [[CUPS]].<br />
If you previously tried to install the printer in CUPS, remove it.<br />
<br />
=Foomatic: an alternative to the official drivers=<br />
<br />
Note that there is an alternative to the official, Brother-supplied drivers. Using this method, my Brother HL-2030 worked instantly and without any problems. (The following steps are copied from the forum. Thanks to thayer!)<br />
# pacman -S cups foomatic-{db,db-engine,filters}<br />
<br />
Go to http://localhost:631<br />
* Add printer<br />
* Give name<br />
* Select HL-2030 on USB from Device menu<br />
* Select HL-2030/hl1250 foomatic driver (PPD)<br />
* Done<br />
<br />
=Brother drivers=<br />
Brother supplies official linux drivers for the HL-2030. These, however come in the form of RPM packages. These can be installed on Arch in two ways: Either using the [url=http://aur.archlinux.org/packages.php?ID=14131]AUR PKGBUILD[/url] or manually following these instructions.<br />
<br />
==Download drivers==<br />
First create a temporary directory. Then you must download the official LPR drivers from the Brother website in that directory. Click [http://www.brother.com/cgi-bin/agreement/agreement.cgi?dlfile=http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/lpr_others/brhl2030lpr-2.0.1-1.i386.rpm&lang=English_lpr here] . This is a RPM archive. You have to download the cupswrapper file. Right [http://www.brother.com/cgi-bin/agreement/agreement.cgi?dlfile=http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/cups_wrapper/cupswrapperHL2030-2.0.1-1.i386.rpm&lang=English_gpl here]. This script creates the filters and PPD file for CUPS automatically. It's an RPM archive too.<br />
<br />
==Extracting the RPM files==<br />
Now you need a small script called rpmextract which allows you to get the files included in the RPM you've just downloaded.<br />
Log in as root and execute :<br />
# pacman -S rpmextract<br />
Extract both RPM files :<br />
$ rpmextract.sh brhl2030lpr-2.0.1-1.i386.rpm<br />
$ rpmextract.sh cupswrapperHL2030-2.0.1-1.i386.rpm<br />
It should give you two directories : usr and var.<br />
<br />
==Editing files to make them work with Arch==<br />
Arch Linux uses its own file system organisation, so you have to edit some files. Use your favorite text editor (i.e. vi) to open the file named cupswrapperHL2030-2.0.1. If you created the temporary directory "tmp" in your home, it must be in /home/user/tmp/usr/local/Brother/cupswrapper. In this file, you must replace all the <i>/etc/init.d/</i> occurences by <i>/etc/rc.d/</i>.<br />
Then you have to edit the file usr/local/Brother/inf/setupPrintcap, and replace <i>/etc/printcap.local</i> by <i>/etc/printcap</i>.<br />
<br />
When it's done, copy all the files in their corresponding directories :<br />
# cp -r /home/user/tmp/usr/* /usr<br />
# cp -r /home/user/tmp/var/* /var<br />
<br />
==Installing the driver and printer==<br />
Go into /usr/local/Brother/cupswrapper/ and run the cupswrapper file :<br />
# cd /usr/local/Brother/cupswrapper/<br />
# ./cupswrapperHL2030-2.0.1<br />
It will stop the cups daemon if it's running, and restart it. Now go to the CUPS page - http://localhost:631/ - and in the Administartion category, choose Manage printers. There you should see a HL2030 printer <b>automatically</b> installed and configured. Click to print the test page, and you can hear the sweet sound of your printer.<br />
<br />
==Compatibility with Brother HL-2035==<br />
Brother does not (yet) provide specific drivers for the HL-2035, but the HL-2030 drivers seem to work fine for this model as well. Use at your own risk, though.<br />
<br />
==Common Issues==<br />
If you have done all the steps above, and the printer will either not appear in your [http://localhost:631/ cups interface] or if you want to print sth. the printer will just warm up and then not print anything, the following is reported to have helped:<br />
# install the hal cups utils: <code>pacman -S hal-cups-utils</code><br />
# visit your [http://localhost:631/ cups interface], and under "administration" hit "find new printer". Surprisingly, it should be found. In the next step, choose the ppd file (found in /usr/share/cups/model/HL2030.ppd) and everything should work just fine ...</div>Madchinehttps://wiki.archlinux.org/index.php?title=Brother_HL-2030&diff=142657Brother HL-20302011-05-24T15:18:59Z<p>Madchine: Adding AUR option</p>
<hr />
<div>[[Category:Printers_(English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
This is a small tutorial to make the printer Brother HL-2030 work on Arch.<br />
There are no drivers available from Openprinting.org at the moment for this printer to work in [[CUPS]].<br />
If you previously tried to install the printer in CUPS, remove it.<br />
<br />
=Foomatic: an alternative to the official drivers=<br />
<br />
Note that there is an alternative to the official, Brother-supplied drivers. Using this method, my Brother HL-2030 worked instantly and without any problems. (The following steps are copied from the forum. Thanks to thayer!)<br />
# pacman -S cups foomatic-{db,db-engine,filters}<br />
<br />
Go to http://localhost:631<br />
* Add printer<br />
* Give name<br />
* Select HL-2030 on USB from Device menu<br />
* Select HL-2030/hl1250 foomatic driver (PPD)<br />
* Done<br />
<br />
=Brother drivers=<br />
Brother supplies official linux drivers for the HL-2030. These, however come in the form of RPM packages. These can be installed on Arch in two ways: Either using the [url=http://aur.archlinux.org/packages.php?ID=14131]AUR PKGBUILD[/url] or manually following these instructions.<br />
<br />
==Download drivers==<br />
First create a temporary directory. Then you must download the official LPR drivers from the Brother website in that directory. Click [http://www.brother.com/cgi-bin/agreement/agreement.cgi?dlfile=http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/lpr_others/brhl2030lpr-2.0.1-1.i386.rpm&lang=English_lpr here] . This is a RPM archive. You have to download the cupswrapper file. Right [http://www.brother.com/cgi-bin/agreement/agreement.cgi?dlfile=http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/cups_wrapper/cupswrapperHL2030-2.0.1-1.i386.rpm&lang=English_gpl here]. This script creates the filters and PPD file for CUPS automatically. It's an RPM archive too.<br />
<br />
<br />
==Extracting the RPM files==<br />
Now you need a small script called rpmextract which allows you to get the files included in the RPM you've just downloaded.<br />
Log in as root and execute :<br />
# pacman -S rpmextract<br />
Extract both RPM files :<br />
$ rpmextract.sh brhl2030lpr-2.0.1-1.i386.rpm<br />
$ rpmextract.sh cupswrapperHL2030-2.0.1-1.i386.rpm<br />
It should give you two directories : usr and var.<br />
<br />
<br />
==Editing files to make them work with Arch==<br />
Arch Linux uses its own file system organisation, so you have to edit some files.<br />
Use your favorite text editor (i.e. vi) to open the file named cupswrapperHL2030-2.0.1<br />
If you created the temporary directory "tmp" in your home, it must be in /home/user/tmp/usr/local/Brother/cupswrapper .<br />
In this file, you must replace all the <i>/etc/init.d/</i> occurences by <i>/etc/rc.d/</i>.<br />
Then you have to edit the file usr/local/Brother/inf/setupPrintcap, and replace <i>/etc/printcap.local</i> by <i>/etc/printcap</i>.<br />
When it's done, copy all the files in their corresponding directories :<br />
# cp -r /home/user/tmp/usr/* /usr<br />
# cp -r /home/user/tmp/var/* /var<br />
<br />
==Installing the driver and printer==<br />
Last step !<br />
Go into /usr/local/Brother/cupswrapper/ and run the cupswrapper file :<br />
# cd /usr/local/Brother/cupswrapper/<br />
# ./cupswrapperHL2030-2.0.1<br />
It will stop the cups daemon if it's running, and restart it.<br />
Now go to the CUPS page : http://localhost:631/<br />
In the Administartion category, choose Manage printers. There you should see a HL2030 printer <b>automatically</b> installed and configured.<br />
Click to print the test page, and you can hear the sweet sound of your printer.<br />
<br />
==Compatibility with Brother HL-2035==<br />
Brother does not (yet) provide specific drivers for the HL-2035, but the HL-2030 drivers seem to work fine for this model as well. Use at your own risk, though.<br />
<br />
==Common Issues==<br />
If you have done all the steps above, and the printer will either not appear in your [http://localhost:631/ cups interface] or if you want to print sth. the printer will just warm up and then not print anything, the following is reported to have helped:<br />
# install the hal cups utils: <code>pacman -S hal-cups-utils</code><br />
# visit your [http://localhost:631/ cups interface], and under "administration" hit "find new printer". Surprisingly, it should be found. In the next step, choose the ppd file (found in /usr/share/cups/model/HL2030.ppd) and everything should work just fine ...</div>Madchinehttps://wiki.archlinux.org/index.php?title=Brother_HL-2030&diff=142656Brother HL-20302011-05-24T15:13:23Z<p>Madchine: Thought the two methods (foomatic vs. brother) should be clearly separated.</p>
<hr />
<div>[[Category:Printers_(English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
This is a small tutorial to make the printer Brother HL-2030 work on Arch.<br />
There are no drivers available from Openprinting.org at the moment for this printer to work in [[CUPS]].<br />
If you previously tried to install the printer in CUPS, remove it.<br />
<br />
=Foomatic: an alternative to the official drivers=<br />
<br />
Note that there is an alternative to the official, Brother-supplied drivers. Using this method, my Brother HL-2030 worked instantly and without any problems. (The following steps are copied from the forum. Thanks to thayer!)<br />
# pacman -S cups foomatic-{db,db-engine,filters}<br />
<br />
Go to http://localhost:631<br />
* Add printer<br />
* Give name<br />
* Select HL-2030 on USB from Device menu<br />
* Select HL-2030/hl1250 foomatic driver (PPD)<br />
* Done<br />
<br />
=Brother drivers=<br />
<br />
First create a temporary directory.<br />
Then you must download the official LPR drivers from the Brother website in that directory. Click [http://www.brother.com/cgi-bin/agreement/agreement.cgi?dlfile=http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/lpr_others/brhl2030lpr-2.0.1-1.i386.rpm&lang=English_lpr here] . This is a RPM archive.<br />
You have to download the cupswrapper file. Right [http://www.brother.com/cgi-bin/agreement/agreement.cgi?dlfile=http://solutions.brother.com/Library/sol/printer/linux/rpmfiles/cups_wrapper/cupswrapperHL2030-2.0.1-1.i386.rpm&lang=English_gpl here]. This script creates the filters and PPD file for CUPS automatically. It's an RPM archive too.<br />
<br />
<br />
==Extracting the RPM files==<br />
Now you need a small script called rpmextract which allows you to get the files included in the RPM you've just downloaded.<br />
Log in as root and execute :<br />
# pacman -S rpmextract<br />
Extract both RPM files :<br />
$ rpmextract.sh brhl2030lpr-2.0.1-1.i386.rpm<br />
$ rpmextract.sh cupswrapperHL2030-2.0.1-1.i386.rpm<br />
It should give you two directories : usr and var.<br />
<br />
<br />
==Editing files to make them work with Arch==<br />
Arch Linux uses its own file system organisation, so you have to edit some files.<br />
Use your favorite text editor (i.e. vi) to open the file named cupswrapperHL2030-2.0.1<br />
If you created the temporary directory "tmp" in your home, it must be in /home/user/tmp/usr/local/Brother/cupswrapper .<br />
In this file, you must replace all the <i>/etc/init.d/</i> occurences by <i>/etc/rc.d/</i>.<br />
Then you have to edit the file usr/local/Brother/inf/setupPrintcap, and replace <i>/etc/printcap.local</i> by <i>/etc/printcap</i>.<br />
When it's done, copy all the files in their corresponding directories :<br />
# cp -r /home/user/tmp/usr/* /usr<br />
# cp -r /home/user/tmp/var/* /var<br />
<br />
==Installing the driver and printer==<br />
Last step !<br />
Go into /usr/local/Brother/cupswrapper/ and run the cupswrapper file :<br />
# cd /usr/local/Brother/cupswrapper/<br />
# ./cupswrapperHL2030-2.0.1<br />
It will stop the cups daemon if it's running, and restart it.<br />
Now go to the CUPS page : http://localhost:631/<br />
In the Administartion category, choose Manage printers. There you should see a HL2030 printer <b>automatically</b> installed and configured.<br />
Click to print the test page, and you can hear the sweet sound of your printer.<br />
<br />
==Compatibility with Brother HL-2035==<br />
Brother does not (yet) provide specific drivers for the HL-2035, but the HL-2030 drivers seem to work fine for this model as well. Use at your own risk, though.<br />
<br />
==Common Issues==<br />
If you have done all the steps above, and the printer will either not appear in your [http://localhost:631/ cups interface] or if you want to print sth. the printer will just warm up and then not print anything, the following is reported to have helped:<br />
# install the hal cups utils: <code>pacman -S hal-cups-utils</code><br />
# visit your [http://localhost:631/ cups interface], and under "administration" hit "find new printer". Surprisingly, it should be found. In the next step, choose the ppd file (found in /usr/share/cups/model/HL2030.ppd) and everything should work just fine ...</div>Madchine