https://wiki.archlinux.org/api.php?action=feedcontributions&user=Ivangorrion&feedformat=atomArchWiki - User contributions [en]2024-03-29T06:52:31ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=CUPS&diff=189510CUPS2012-03-14T16:16:36Z<p>Ivangorrion: </p>
<hr />
<div>[[Category:Printers (English)]]<br />
{{i18n|CUPS}}<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Installing and configuring CUPS}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|CUPS printer sharing}}<br />
{{Article summary wiki|CUPS printer-specific problems}}<br />
{{Article summary wiki|Samba}}<br />
{{Article summary end}}<br />
<br />
From [http://www.cups.org/index.php CUPS' site]:<br />
:"''[[Wikipedia:CUPS|CUPS]] is the standards-based, open source printing system developed by Apple Inc. for Mac OS® X and other UNIX®-like operating systems''".<br />
<br />
Although there are other printing packages such as LPRNG, the Common Unix Printing System is the most popular choice because of its relative ease of use.<br />
<br />
==Installing==<br />
The packages {{Pkg|cups}}, {{Pkg|ghostscript}}, and {{Pkg|gsfonts}} are needed. [[pacman|Install]] them from the [[Official repositories]].<br />
<br />
* '''cups''' - The actual CUPS software<br />
* '''ghostscript''' - Interpreter for the Postscript language<br />
* '''gsfonts''' - GhostScript standard Type1 fonts<br />
* '''hpoj''' - If you are using an HP Officejet, you should also install this package and follow the instructions to avoid problems. Read this [http://answers.launchpad.net/hplip/+question/133425 thread at launchpad/hplip] for more information.<br />
<br />
If the system is connected to a networked printer using the [[Samba]] protocol or if the system is to be a print server for Windows clients, also install {{Pkg|samba}}.<br />
<br />
===Printer driver===<br />
Here are some of the driver packages. Choosing the right driver depends on the printer:<br />
<br />
* '''{{Pkg|gutenprint}}''' - A collection of high quality drivers for Canon, Epson, Lexmark, Sony, Olympus, and PCL printers for use with GhostSscript, CUPS, Foomatic, and the [[GIMP]]<br />
* '''{{Pkg|foomatic-db}}, {{Pkg|foomatic-db-engine}}, {{Pkg|foomatic-db-nonfree}}, and {{Pkg|foomatic-filters}}''' - Foomatic is a database-driven system for integrating free software printer drivers with common spoolers under Unix. Installing foomatic-filters should solve problems if the cups error_log is reporting "stopped with status 22!".<br />
* '''{{AUR|foo2zjs}}''' - Drivers for ZjStream protocol printers such as the HP Laserjet 1018. More info [http://foo2zjs.rkkda.com here], Foo2zsj is available in the {{AUR|foo2zjs}}.<br />
* '''{{Pkg|hplip}}''' - HP GNU/Linux driver. Provides support for DeskJet, OfficeJet, Photosmart, Business Inkjet and some LaserJet printer models, as well as a number of Brother printers.<br />
* '''{{Pkg|splix}}''' - Samsung drivers for SPL (Samsung Printer Language) printers<br />
* '''{{AUR|ufr2}}''' - Canon UFR2 driver with support for LBP, iR and MF series printers. Package is available in the [[AUR]].<br />
* '''{{Pkg|cups-pdf}}''' - A package that allows one to setup a virtual PDF Printer that generates a PDF out of jobs sent to it<br />
<br />
If unsure of what driver package to install or if the current driver is not working, it may be easiest to just install all of drivers, since some of the packages are misleading because printers of other makes may rely on them. For instance, the Brother HL-2140 needs the hplip driver installed.<br />
<br />
====Download printer PPD====<br />
Depending on the printer, this step is optional and may not be needed, as the standard CUPS installation already comes with quite a few PPD (Postscript Printer Description) files. Moreover, the ''foomatic-filters'', ''gimp-print'' and ''hplip'' packages already include quite a few PPD files which will automatically be detected by CUPS.<br />
<br />
Here is an explanation of what a PPD file is from the Linux Printing website:<br />
:"''For every PostScript printer the manufacturers provide a PPD file which contains all printer-specific information about the particular printer model: Basic printer capabilities as whether the printer is a color printer, fonts, PostScript level, etc., and especially the user-adjustable options, as paper size, resolution, etc.''"<br />
<br />
If the PPD for the printer is ''not'' already in CUPS, then:<br />
*check [[AUR]] to see if there are packages for the printer/manufacturer<br />
*visit the [http://www.openprinting.org/printers OpenPrinting database] and select the manufacturer and model of the printer<br />
*visit the manufacturer's site and search for GNU/Linux drivers<br />
<br />
{{Note|PPD files go in {{ic|/usr/share/cups/model/}}}}<br />
<br />
==Configuring==<br />
Now that CUPS is installed, there are a variety of options on how to setup printing solutions. As always, the tried and true command line method is at your disposal. Likewise, various desktop environments such as GNOME and KDE have useful programs that can help manage printers. However, in order to make this process easy for the largest amount of users, this article will focus on the web interface provided by CUPS.<br />
<br />
If you are planning on connecting to a network printer, rather than one that is directly connected to the computer, you might want to read the [[CUPS printer sharing]] page first. Printer sharing between GNU/Linux systems is quite easy and involves very little configuration, whereas sharing between a Windows and GNU/Linux host requires a little bit more effort.<br />
<br />
USB printers can get accessed with two methods: The usblp kernel module and libusb. The former is the classic way. It is simple: Data is sent to the printer by writing it to a device file as a simple serial data stream. Reading the same device file allows bi-di access, at least for things like reading out ink levels, status, or printer capability information (PJL). It works very well for simple printers, but for multi-function devices (printer/scanner) it is not suitable and manufacturers like HP supply their own backends. (source: [http://lists.linuxfoundation.org/pipermail/printing-architecture/2012/002412.html here])<br />
<br />
===Kernel modules===<br />
Before using the CUPS web interface, the appropriate kernel modules need to be installed. The following steps are from the Gentoo Printing Guide.<br />
<br />
This section may not be necessary, however, depending on which kernel is being used. The kernel module may load automatically after plugging in the printer. Use the {{ic|tail}} command (described below) to see if the printer has already been detected. The {{ic|lsmod}} utility can also be used to see what modules have been loaded.<br />
<br />
====USB printers====<br />
USB printer users may need to blacklist the {{ic|usblp}} module. Keep in mind that there seems to be a lot of [http://bbs.archlinux.org/viewtopic.php?pid=660601 uncertainty] regarding blacklisting {{ic|usblp}}, as some USB printers, including some Canon and Epson printer series, are not recognized without it.<br />
<br />
To blacklist the module:<br />
<br />
{{hc|/etc/modprobe.d/blacklist.conf|blacklist usblp}}<br />
<br />
Custom kernel users may need to manually load the {{ic|usbcore}} module before proceeding:<br />
# modprobe usbcore<br />
<br />
Once the modules are installed, plug in the printer and check if the kernel detected it by running the following:<br />
# tail /var/log/messages.log<br />
or<br />
# dmesg<br />
<br />
If you're using {{ic|usblp}}, the output should indicate that the printer has been detected like so:<br />
Feb 19 20:17:11 kernel: printer.c: usblp0: USB Bidirectional<br />
printer dev 2 if 0 alt 0 proto 2 vid 0x04E8 pid 0x300E<br />
Feb 19 20:17:11 kernel: usb.c: usblp driver claimed interface cfef3920<br />
Feb 19 20:17:11 kernel: printer.c: v0.13: USB Printer Device Class driver<br />
<br />
If you blacklisted {{ic|usblp}}, you will see something like:<br />
usb 3-2: new full speed USB device using uhci_hcd and address 3<br />
usb 3-2: configuration #1 chosen from 1 choice<br />
<br />
====Parallel port printers====<br />
To use a parallel port printer the configuration is pretty much the same, except for the modules:<br />
# modprobe lp<br />
# modprobe parport<br />
# modprobe parport_pc<br />
<br />
Once again, check the setup by running:<br />
# tail /var/log/messages.log<br />
It should display something like this:<br />
lp0: using parport0 (polling).<br />
<br />
If you are using a USB to parallel port adapter, CUPS will not be able to detect the printer. As a workaround, add the printer using a different connection type and then change DeviceID in /etc/cups/printers.conf:<br />
DeviceID = parallel:/dev/usb/lp0<br />
<br />
====Auto-loading====<br />
It is convenient to have the system automatically load the kernel module every time it starts up. To do so, use a text editor to open up {{ic|/etc/[[rc.conf]]}} and add the appropriate module to the {{ic|1=MODULES=()}} line. Here is an example:<br />
MODULES=(!usbserial scsi_mod sd_mod snd-ymfpci snd-pcm-oss '''lp parport parport_pc''' ide-scsi)<br />
<br />
===CUPS daemon===<br />
With the kernel modules installed, you can now [[Daemon#Performing daemon actions manually|start the cupsd daemon]]. Add cupsd to your [[daemons#Starting on Boot|DAEMONS array]] so it starts automatically on boot.<br />
<br />
=== Web interface and tool-kit ===<br />
<br />
Once the daemon is running, open a browser and go to: http://localhost:631 (''The '''localhost''' string may need to be replaced with the hostname found in'' {{ic|/etc/hosts}}).<br />
<br />
From here, follow the various wizards to add the printer. A usual procedure is to start by clicking on ''Adding Printers and Classes'' and then ''Add Printer''. When prompted for a username and password, log in as root. The name assigned to the printer does not matter, the same applies for 'location' and 'description'. Next, a list of devices to select from will be presented. The actual name of the printer shows up next to the label ( e.g., next to ''USB Printer #1'' for USB printers). Finally, choose the appropriate drivers and the configuration is complete.<br />
<br />
Now test the configuration by pressing the ''Maintenance'' drop-down menu then ''Print Test Page''. If it does not print and there is certainty regarding the correctness of applied settings, then the problem is most likely due to missing a proper printer driver.<br />
<br />
{{Tip|See: [[#Alternative CUPS interfaces]] for other other frontends.}}<br />
{{Note|When setting up a USB printer, you should see your printer listed on ''Add Printer'' page. If you can only see a "SCSI printer" option, it probably means that CUPS has failed to recognize your printer.}}<br />
<br />
==== CUPS administration ====<br />
<br />
A username and password will be required when administering the printer in the web interface, such as: adding or removing printers, stopping print tasks, etc. The default username is the one assigned in the ''sys'' group, or root (change this by editing {{ic|/etc/cups/cupsd.conf}} in the line of ''SystemGroup''). <br />
<br />
If the root account has been locked (i.e. when using sudo), it is not possible to log in the CUPS administration interface with the default username and password. In this case, follow [http://www.cups.org/articles.php?L237+T+Qprintadmin these instructions] on the CUPS FAQ. You might also want to read [http://bbs.archlinux.org/viewtopic.php?id=35567 this post].<br />
<br />
====Remote access to web interface====<br />
By default, the CUPS web interface can only be accessed by the ''localhost''; i.e. the computer that it is installed on. To remotely access the interface, make the following changes to the {{ic|/etc/cups/cupsd.conf}} file. Replace the line:<br />
Listen localhost:631<br />
with<br />
port 631<br />
so that CUPS listens to incoming requests.<br />
<br />
Three levels of access can be granted:<br />
<Location /> #access to the server<br />
<Location /admin> #access to the admin pages<br />
<Location /admin/conf> #access to configuration files<br />
<br />
To give remote hosts access to one of these levels, add an {{ic|Allow}} statement to that level's section. An {{ic|Allow}} statement can take one or more of the forms listed below:<br />
Allow all<br />
Allow host.domain.com<br />
Allow *.domain.com<br />
Allow ip-address<br />
Allow ip-address/netmask<br />
<br />
Deny statements can also be used. For example, if wanting to give all hosts on the 192.168.1.0/255.255.255.0 subnet full access, file {{ic|/etc/cups/cupsd.conf}} would include this:<br />
# Restrict access to the server...<br />
# By default only localhost connections are possible<br />
<Location /><br />
Order allow,deny<br />
Allow From localhost<br />
'''Allow From 192.168.1.0/255.255.255.0'''<br />
</Location><br />
<br />
# Restrict access to the admin pages...<br />
<Location /admin><br />
# Encryption disabled by default<br />
#Encryption Required<br />
Order allow,deny<br />
Allow From localhost<br />
'''Allow From 192.168.1.0/255.255.255.0'''<br />
</Location><br />
<br />
# Restrict access to configuration files...<br />
<Location /admin/conf><br />
AuthType Basic<br />
Require user @SYSTEM<br />
Order allow,deny<br />
Allow From localhost<br />
'''Allow From 192.168.1.0/255.255.255.0'''<br />
</Location><br />
<br />
You might also need to add:<br />
<br />
DefaultEncryption Never<br />
<br />
This should avoid the error: 426 - Upgrade Required when using the CUPS web interface from a remote machine.<br />
<br />
==Troubleshooting==<br />
The best way to get printing working is to set 'LogLevel' in {{ic|/etc/cups/cupsd.conf}} to:<br />
LogLevel debug<br />
<br />
And then viewing the output from {{ic|/var/log/cups/error_log}} like this:<br />
# tail -n 100 -f /var/log/cups/error_log<br />
<br />
The characters at the left of the output stand for:<br />
*D=Debug<br />
*E=Error<br />
*I=Information<br />
*And so on<br />
<br />
These files may also prove useful:<br />
*{{ic|/var/log/cups/page_log}} - Echoes a new entry each time a print is successful<br />
*{{ic|/var/log/cups/access_log}} - Lists all cupsd http1.1 server activity<br />
<br />
Of course, it is important to know how CUPS works if wanting to solve related issues:<br />
# An application sends a .ps file (PostScript, a script language that details how the page will look) to CUPS when 'print' has been selected (this is the case with most programs).<br />
# CUPS then looks at the printer's PPD file (printer description file) and figures out what filters it needs to use to convert the .ps file to a language that the printer understands (like PJL, PCL), usually GhostScript.<br />
# GhostScript takes the input and figures out which filters it should use, then applies them and converts the .ps file to a format understood by the printer.<br />
# Then it is sent to the back-end. For example, if the printer is connected to a USB port, it uses the USB back-end.<br />
<br />
Print a document and watch {{ic|error_log}} to get a more detailed and correct image of the printing process.<br />
<br />
===Problems resulting from upgrades===<br />
''Issues that appeared after CUPS and related program packages underwent a version increment''<br />
<br />
====CUPS stops working====<br />
The chances are that a new configuration file is needed for the new version to work properly. Messages such as "404 - page not found" my result from trying to manage CUPS via localhost:631, for example.<br />
<br />
To use the new configuration, copy /etc/cups/cupsd.conf.default to /etc/cups/cupsd.conf (backup the old configuration if needed):<br />
# cp /etc/cups/cupsd.conf.default /etc/cups/cupsd.conf<br />
and restart CUPS to employ the new settings.<br />
<br />
====Error with gnutls====<br />
If receiving errors such as:<br />
/usr/sbin/cupsd: error while loading shared libraries: libgnutls.so.13: cannot open shared object file: No such file or directory<br />
gnutls may be in need of updating:<br />
# pacman -S gnutls<br />
<br />
After updating, there may be a file named {{ic|cupsd.conf.pacnew}} in {{ic|/etc/cups}}. This is the unmodified original configuration file that has been placed as part of the update. Compare it with the currently installed version and adjust to preference.<br />
<br />
====All jobs are "stopped"====<br />
If all jobs sent to the printer become "stopped", delete the printer and add it again.<br />
Using the [http://localhost:631 CUPS web interface], go to Printers > Delete Printer.<br />
<br />
To check the printer's settings go to ''Printers'', then ''Modify Printer''. Copy down the information displayed, click 'Modify Printer' to proceed to the next page(s), and so on.<br />
<br />
====All jobs are "The printer is not responding"====<br />
On networked printers, you should check that the name that CUPS uses as its connection URI resolves to the printer's IP via DNS, e.g.<br />
If your printer's connection looks like this:<br />
lpd://BRN_020554/BINARY_P1<br />
<br />
then the hostname 'BRN_020554' needs to resolve to the printer's IP from the server running CUPS<br />
<br />
====The PPD version is not compatible with gutenprint====<br />
Run:<br />
# /usr/sbin/cups-genppdupdate<br />
<br />
And restart CUPS (as pointed out in gutenprint's post-install message)<br />
<br />
===USB printers under CUPS 1.4.x===<br />
New CUPS 1.4.x introduces many changes:<br />
<br />
====Configuration file====<br />
The syntax of the configuration file cupsd.conf changed. Start with a new cupsd.conf file based on /etc/cups/cupsd.conf.default.<br />
<br />
====Blacklisting usblp====<br />
CUPS now uses libusb and printer USB devices (under /dev/bus/usb/) instead of the usblp generated /dev/usb/lpX ones. In order to get USB printers working, the usblp module needs disabling. Some users have also reported that they needed to reinstall their printer.<br />
<br />
{{hc|/etc/modprobe.d/modprobe.conf|blacklist usblp}}<br />
<br />
====Device node permissions====<br />
In addition to usblp not being loaded, CUPS also needs the ownership of the USB device file of the printer to be root:lp, and permissions to be 660, e.g.<br />
$ ls -l /dev/bus/usb/003/002<br />
crw-rw---- 1 root lp 189, 257 20. Okt 10:32 /dev/bus/usb/003/002<br />
<br />
This is supposed to be achieved by two udev rules in /lib/udev/rules.d/50-udev-default.rules:<br />
# hplip and cups 1.4+ use raw USB devices, so permissions should be similar to<br />
# the ones from the old usblp kernel module<br />
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="", IMPORT{program}="usb_id --export %p"<br />
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}==":0701*:", GROUP="lp", MODE="660"<br />
<br />
However, for some devices, in particular combined printer/scanner devices, these rules either do not trigger, or are overwritten by rules of the 'sane' package. In these cases a custom udev rule needs to be added. See below.<br />
<br />
=====Device node permission troubleshooting=====<br />
Get the printer's device file and its permissions with: <br />
$ lsusb<br />
...<br />
Bus 003 Device 002: ID 04b8:0841 Seiko Epson Corp.<br />
$ ls -l /dev/bus/usb/003/002<br />
crw-rw---- 1 root lp 189, 257 20. Okt 10:32 /dev/bus/usb/003/002<br />
<br />
If the permissions are not already root:lp 660, enforce it by creating a custom udev rule, e.g.<br />
cat /etc/udev/rules.d/10-usbprinter.rules<br />
ATTR{idVendor}=="04b8", ATTR{idProduct}=="0841", MODE:="0660", GROUP:="lp"<br />
<br />
If you have a multifunction device (printer+scanner) you need to make the device detectable to sane too<br />
cat /etc/udev/rules.d/10-usbprinter.rules<br />
ATTR{idVendor}=="04b8", ATTR{idProduct}=="0841", MODE:="0660", GROUP:="lp", ENV{libsane_matched}:="yes"<br />
<br />
Note that idVendor and idProduct are from the lsusb listing above.<br><br />
Note - some printers will need permissions to be 666<br />
<br />
=====Loading firmware=====<br />
<br />
Some printers and drivers need to load firmware to the printer (such as HP LaserJet 10xx printers using foo2zjs) and do this by writing directly to the lp device, a functionality provided by usblp. A work around until this issue is resolved is to install the usblp module until the firmware is loaded, then remove the module to allow CUPS to work. This can be accomplished by manually running "$ modprobe usblp", waiting for the firmware to load, then "$ rmmod usblp". You can also not blacklist usblp, then put "rmmod usblp" to /etc/rc.local, allowing the firmware to be loaded on boot before rc.local is run, then removing usblp.<br />
<br />
In case the printer is plugged in or powered on while system is already running, /etc/rc.local does not get executed and usblp module stays loaded. A workaround is to modify the /etc/udev/rules.d/11-hpj10xx.rules provided by foo2zjs so that after the add event we wait, e.g. 15 seconds for the firmware to load and then automatically remove usblp. The following example is for HP LaserJet 1018. For other models the value of ATTRS{idProduct} should be changed to match the printer model.<br />
<br />
Locate the line matching your printer in /etc/udev/rules.d/11-hpj10xx.rules:<br />
ACTION=="add", KERNEL=="lp*", SUBSYSTEM=="usb", ATTRS{idVendor}=="03f0", \<br />
ATTRS{idProduct}=="4117", RUN+="/sbin/foo2zjs-loadfw 1018 $tempnode"<br />
Add the following lines below it, make sure match the product and vendor IDs:<br />
ACTION=="add", KERNEL=="lp*", SUBSYSTEM=="usb", ATTRS{idVendor}=="03f0", \<br />
ATTRS{idProduct}=="4117", RUN+="/usr/bin/sleep 15"<br />
ACTION=="add", KERNEL=="lp*", SUBSYSTEM=="usb", ATTRS{idVendor}=="03f0", \<br />
ATTRS{idProduct}=="4117", RUN+="/sbin/rmmod usblp"<br />
<br />
===Other===<br />
<br />
=====CUPS permission errors=====<br />
*Some users fixed 'NT_STATUS_ACCESS_DENIED' (Windows clients) errors by using a slightly different syntax:<br />
smb://workgroup/username:password@hostname/printer_name<br />
<br />
*Sometimes, the block device has wrong permissions:<br />
# ls /dev/usb/<br />
lp0<br />
# chgrp lp /dev/usb/lp0<br />
<br />
====HPLIP printer sends "/usr/lib/cups/backend/hp failed" error====<br />
Make sure dbus is installed and running, e.g. check DAEMONS in {{ic|/etc/rc.conf}} or run {{ic|ls /var/run/daemons}}.<br />
<br />
The avahi-daemon might be required if this error persists and the dbus is already running.<br />
<br />
====hp-toolbox sends an error, "Unable to communicate with device"====<br />
If running hp-toolbox as a regular user results in:<br />
# hp-toolbox<br />
# error: Unable to communicate with device (code=12): hp:/usb/<printer id><br />
or, "{{ic|Unable to communicate with device"}}", then it may be needed to add the user to the lp group by running the following command:<br />
# gpasswd -a <username> lp<br />
<br />
This can also be caused by printers such as the P1102 that provide a virtual cd-rom drive for MS-Windows drivers. The lp dev appears and then disappears. In that case try the '''usb-modeswitch''' and '''usb-modeswitch-data''' packages, that lets one switch off the "Smart Drive" (udev rules included in said packages).<br />
<br />
====CUPS returns '"foomatic-rip" not available/stopped with status 3' with a HP printer====<br />
If receiving any of the following error messages in {{ic|/var/log/cups/error_log}} while using a HP printer, with jobs appearing to be processed while they all end up not being completed with their status set to 'stopped':<br />
Filter "foomatic-rip" for printer "<printer_name>" not available: No such file or director<br />
or:<br />
PID 5771 (/usr/lib/cups/filter/foomatic-rip) stopped with status 3!<br />
make sure '''hplip''' has been installed, in addition to [[#Packages|the packages mentioned above]], '''net-snmp''' is also needed. See [http://bbs.archlinux.org/viewtopic.php?id=65615 this forum post].<br />
# pacman -S hplip<br />
<br />
====Printing fails with unauthorised error====<br />
If the user has been added to the lp group, and allowed to print (set in {{ic|cupsd.conf}}), then the problem lies in {{ic|/etc/cups/printers.conf}}. This line could be the culprit:<br />
AuthInfoRequired negotiate<br />
<br />
Comment it out and restart CUPS.<br />
<br />
====Print button greyed-out in GNOME print dialogs====<br />
:''<small>Source: [http://bbs.archlinux.org/viewtopic.php?id=70418 I can't print from gnome applications. - Arch Forums]</small>''<br />
<br />
Be sure the package: '''libgnomeprint''' is installed<br />
<br />
Edit {{ic|/etc/cups/cupsd.conf}} and add<br />
# HostNameLookups Double<br />
<br />
Restart CUPS:<br />
# /etc/rc.d/cupsd restart<br />
<br />
====Unknown supported format: application/postscript====<br />
Comment the lines:<br />
application/octet-stream application/vnd.cups-raw 0 -<br />
from {{ic|/etc/cups/mime.convs}}, and:<br />
application/octet-stream<br />
in {{ic|/etc/cups/mime.types}}.<br />
<br />
====Finding URIs for Windows Print Servers====<br />
<br />
Sometimes Windows is a little less than forthcoming about exact device URIs (device locations). If having trouble specifying the correct device location in CUPS, run the following command to list all shares available to a certain windows username:<br />
$ smbtree -U ''windowsusername''<br />
This will list every share available to a certain Windows username on the local area network subnet, as long as Samba is set up and running properly. It should return something like this:<br />
{{bc| WORKGROUP<br />
\\REGULATOR-PC <br />
\\REGULATOR-PC\Z <br />
\\REGULATOR-PC\Public <br />
\\REGULATOR-PC\print$ Printer Drivers<br />
\\REGULATOR-PC\G <br />
\\REGULATOR-PC\EPSON Stylus CX8400 Series EPSON Stylus CX8400 Series}}<br />
What is needed here is first part of the last line, the resource matching the printer description. So to print to the EPSON Stylus printer, one would enter:<br />
smb://username.password@REGULATOR-PC/EPSON Stylus CX8400 Series<br />
as the URI into CUPS. Notice that whitespaces are allowed in URIs, whereas backslashes get replaced with forward slashes.<br />
<br />
====Print-Job client-error-document-format-not-supported====<br />
Try installing the foomatic packages and use a foomatic driver.<br />
<br />
====/usr/lib/cups/backend/hp failed====<br />
Change<br />
SystemGroup sys root<br />
to<br />
SystemGroup lp root<br />
in /etc/cups/cupsd.conf<br />
<br />
<br />
Following steps 1-3 in the Alternative CUPS interfaces below may be a better solution, since newer versions of cups will not allow the same group for both normal and admin operation.<br />
<br />
===="Unable to get list of printer drivers"====<br />
Try to remove Foomatic drivers.<br />
<br />
==Appendix==<br />
<br />
===Alternative CUPS interfaces===<br />
If using [[GNOME]], a possibility is to manage and configure the printer by using system-config-printer-gnome. This package is available through pacman: <br />
# pacman -S system-config-printer-gnome<br />
<br />
For system-config-printer to work as it should, running as root may be required, or alternatively set up a "normal" user to administer CUPS (if so '''follow steps 1-3''')<br />
<br />
* 1. Create group, and add a user to it<br />
# groupadd lpadmin<br />
# usermod -aG lpadmin <username><br />
<br />
* 2. Add "lpadmin" (without the quotes) to this line in {{ic|/etc/cups/cupsd.conf}}<br />
SystemGroup sys root <insert here><br />
<br />
* 3. Restart cups, log out and in again (or restart computer)<br />
{{bc|# rc.d restart cupsd}}<br />
<br />
[[KDE]] users can modify their printers from the Control Center. Both should refer to those desktop environments' documentation for more information on how to use the interfaces.<br />
<br />
There is also [https://aur.archlinux.org/packages.php?ID=43505 gtklp] in the [[AUR]]<br />
<br />
===PDF virtual printer===<br />
CUPS-PDF is a nice package that allows one to setup a virtual printer that will generate a PDF from anything sent to it. Obviously this package is not necessary, but it can be quite useful.<br />
<br />
Find generated PDF documents in a sub-directory located at {{ic|/var/spool/cups-pdf}}. Normally, the subdirectory is named after the user who performed the job. A little tweak helps you to find your printed PDF documents more easily. Edit /etc/cups/cups-pdf.conf by changing the line<br />
#Out /var/spool/cups-pdf/${USER}<br />
<br />
to<br />
<br />
Out /home/${USER}<br />
<br />
This package can be installed by the following command:<br />
# pacman -S cups-pdf<br />
<br />
After installing the package, set it up as if it were for any other printer by using the web interface. For the Device, select '''CUPS-PDF (Virtual PDF Printer)'''; Make/Manufacturer, choose '''Generic'''; Model/Driver, select '''Generic postscript color printer''' or '''Generic Cups-PDF Printer'''. Alternatively, provide the PPD file from [http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/cups-pdf-CURRENT/extra/CUPS-PDF.ppd this link].<br />
<br />
==== Print to postscript: CUPS-PDF virtual printer trick ====<br />
<br />
Printing to PDF in most applications like OpenOffice is no problem; just hit the button. Yet when printing out to postscript, matters take a little more work. For applications like OpenOffice where printing to kprinter is nebulous at best, there has to be another way -- and there is. The CUPS-PDF (Virtual PDF Printer) actually creates a postscript file and then creates the PDF using the ps2pdf utility. To print to postscript, what needs to be done is capturing the intermediate postscript file created by CUPS-PDF. This is easily accomplished with by selecting the "print to file" option in the print dialog. (choose either .ps or .eps as the extension) After selecting the "print to file" checkbox simply enter the filename and click "print".<br />
<br />
=====Configuring CUPS-PDF virtual printer=====<br />
#Set up the cups daemon using the instructions on this page.<br />
#Install {{Pkg|cups-pdf}} from [extra].<br />
#Access the cups print manager: http://localhost:631 and select:<br />
Administration -> Add Printer<br />
Select CUPS-PDF (Virtual PDF), choose for the make and driver:<br />
Make: Generic<br />
Driver: Generic CUPS-PDF Printer<br />
<br />
Now to print to postscript, just print as usual, in the print dialog choose "CUPS-PDF" as the printer, then select the checkbox for "print to file", hit print, enter the filename.ps and click save. This is handy for faxes, etc...<br />
<br />
===Another source for printer drivers===<br />
[http://www.turboprint.de/english.html Turboprint] is a proprietary driver for many printers not yet supported by GNU/Linux (Canon i*, for example). Unlike CUPS, however, high quality prints are either marked with a watermark or are a pay-only service.<br />
<br />
==Resources==<br />
* [http://localhost:631/documentation.html Official CUPS documentation], ''locally installed''<br />
* [http://www.cups.org/ Official CUPS Website]<br />
* [http://www.linuxprinting.org/ Linux Printing], ''[http://www.linuxfoundation.org The Linux Foundation]''<br />
* [http://www.gentoo.org/doc/en/printing-howto.xml Gentoo's Printing Guide], ''[http://www.gentoo.org/doc/en Gentoo Documentation Resources]''<br />
* [http://bbs.archlinux.org/ Arch Linux User Forums]</div>Ivangorrionhttps://wiki.archlinux.org/index.php?title=Cgroups&diff=182021Cgroups2012-02-04T15:32:15Z<p>Ivangorrion: </p>
<hr />
<div>[[Category:Kernel (English)]]<br />
[[Category:Virtualization]]<br />
'''cgroups''' (aka '''control groups''') is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the 'nice' command or {{ic|/etc/security/limits.conf}}, cgroups are infinitely more flexible.<br />
<br />
Control groups can be used in multiple ways:<br />
* create and manage them on the fly using tools like '''cgcreate''', '''cgexec''', '''cgclassify''' etc<br />
* the "rules engine daemon", to automatically move certain users/groups/commands to groups ('''/etc/cgrules.conf''' and '''/etc/rc.d/cgred''')<br />
* through other software such as [[Linux Containers]] (LXC) virtualization<br />
<br />
Unfortunately this feature is often underappreciated due to lack of easy "how-to" style documentation. This is an attempt of fixing the problem. :)<br />
<br />
Note: I'm only learning to use cgroups as I type this, so do not take everything I say here as pure gold.<br />
<br />
== Installing ==<br />
First, install the utilities for managing cgroups; you need the [http://aur.archlinux.org/packages.php?ID=36703 libcgroup package] from AUR. makepkg and install it as usual.<br />
<br />
Next, you need to define where to mount the cgroup controller virtual file systems. Let's start with the 'cpu' and 'memory' controllers:<br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
mount {<br />
cpu = /mnt/cgroups/cpu;<br />
memory = /mnt/cgroups/memory;<br />
}<br />
}}<br />
Then run the following to create these directories and mount the controller file systems:<br />
<br />
/etc/rc.d/'''cgconfig''' start<br />
<br />
Now when you list the controller directory, you should see some files (cgroup tunables) in it:<br />
<br />
ls -l /mnt/cgroups/'''memory'''<br />
<br />
You might also want to run this at boot:<br />
<br />
{{hc|/etc/rc.conf |2=<br />
DAEMONS=( ... '''cgconfig''' ...)<br />
}}<br />
<br />
== Simple usage ==<br />
=== Ad-hoc groups ===<br />
One of the powers of cgroups is that you can create "ad-hoc" groups on the fly. In fact, you can even grant the privileges to create custom groups to regular users. Run this as root (replace $USER with your user name):<br />
<br />
sudo '''cgcreate''' -a '''$USER''' -g memory,cpu:'''me'''<br />
<br />
That's it! Now all the tunables in the group "me" are writable by your user:<br />
<br />
$ ls -l /mnt/cgroups/memory/<b>me</b><br />
total 0<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.event_control<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.procs<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_period_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_runtime_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.shares<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 notify_on_release<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 tasks<br />
<br />
Cgroups are hierarchical, so you can create as many subgroups as you like. Let's say that, as a normal user, you want to run a '''bash''' shell under a new subgroup called 'foo':<br />
<br />
cgcreate -g memory,cpu:'''me/foo'''<br />
'''cgexec''' -g memory,cpu:me/foo '''bash'''<br />
<br />
There we go! Just to make sure:<br />
<br />
$ cat /proc/self/cgroup<br />
11:memory:/me/foo<br />
6:cpu:/me/foo<br />
<br />
A new subdirectory was created for this group. To limit the memory usage of all processes in this group to '''10 MB''', run the following:<br />
<br />
$ echo <b>10000000</b> > /mnt/cgroups/memory/me/foo/<b>memory.limit_in_bytes</b><br />
<br />
Note that the memory limit applies to RAM use only -- once tasks hit this limit, they will begin to swap. But it won't affect the performance of other processes significantly.<br />
<br />
Similarly you can change the CPU priority ("shares") of this group. By default all groups have '''1024''' shares. A group with '''100''' shares will get a ~10% portion of the CPU time:<br />
<br />
$ echo <b>100</b> > /mnt/cgroups/cpu/me/foo/<b>cpu.shares</b><br />
<br />
You can find more tunables or statistics by listing the cgroup directory.<br />
<br />
You can also change the cgroup of already running processes. To move all 'bash' commands to this group:<br />
<br />
$ pidof bash<br />
13244 13266<br />
$ '''cgclassify''' -g memory,cpu:me/foo `pidof bash`<br />
$ cat /proc/13244/cgroup<br />
11:memory:/me/foo<br />
6:cpu:/me/foo<br />
<br />
=== Persistent group configuration ===<br />
<br />
If you want your cgroups to be created at boot, you can define them in '''/etc/cgconfig.conf''' instead. For example, the "me" and "me/foo" group definitions would look like this:<br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
group '''me''' {<br />
perm {<br />
# who can manage limits<br />
admin {<br />
uid = '''$USER''';<br />
}<br />
# who can add tasks to this group<br />
task {<br />
uid = '''$USER''';<br />
}<br />
}<br />
# create this group in cpu and memory controllers<br />
cpu { }<br />
memory { }<br />
}<br />
<br />
group '''me/foo''' {<br />
cpu {<br />
'''cpu.shares''' = 100;<br />
}<br />
memory {<br />
'''memory.limit_in_bytes''' = 10000000;<br />
}<br />
}<br />
}}<br />
<br />
== Documentation ==<br />
For information on controllers and what certain switches and tunables mean, refer to [http://www.mjmwired.net/kernel/Documentation/cgroups/ kernel's Documentation/cgroup] (or install linux-docs and see {{ic|/usr/src/linux/Documentation/cgroup}}<br />
<br />
For commands and configuration files, see relevant man pages, e.g. {{ic|man cgcreate}} or {{ic|man cgrules.conf}}</div>Ivangorrionhttps://wiki.archlinux.org/index.php?title=System_time&diff=181970System time2012-02-04T10:21:25Z<p>Ivangorrion: </p>
<hr />
<div>[[Category:Mainboards and BIOS (English)]] <!-- with regard to the hardware clock --><br />
[[Category:Daemons and system services (English)]] <!-- as the basis/rationale for NTP --><br />
{{i18n|Time}}<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an introduction to the concept of keeping time on computers in general, and describes how clocks are configured and managed in Arch Linux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Network Time Protocol}}<br />
{{Article summary wiki|rc.conf}}<br />
{{Article summary end}}<br />
<br />
In an operating system, clock is determined by four parts: Time value, Time standard, Time Zone, and '''D'''aylight '''S'''aving '''T'''ime ('''DST''') if applicable. This article explains what they are and how to read and set them. For ''maintaining'' accurate system time see [[Network Time Protocol]].<br />
<br />
== Hardware clock and system clock ==<br />
<br />
There are two clocks to keep track of: "hardware clock" and "System clock". <br />
<br />
'''Hardware clock''' (a.k.a. the Real Time Clock (RTC) or CMOS clock) stores the values of: Year, Month, Day, Hour, Minute, and the Seconds. It does not have the ability to store the time standard (localtime or UTC), nor whether DST is used. <br />
<br />
'''System clock''' (a.k.a. the software clock) keeps track of: Time, Time Zone, and DST if applicable. It is calculated by the Linux kernel as the number of seconds since midnight January 1st 1970 UTC. The initial value of the system clock is calculated from the hardware clock, dependent on the value of the HARDWARECLOCK defined in {{ic|/etc/rc.conf}}. Once power up has completed the system clock runs independently of the hardware clock. The Linux kernel keeps track of the system clock by counting timer interrupts.<br />
<br />
32-bit Linux systems will stop working in 2038. Since system time is recorded as a 32-bit integer (the number of seconds since 1970-01-01) it's limitation will extend only this long.<br />
<br />
=== Read clock === <br />
To check the current hardware clock time and system clock time respectively (the hardware clock time is presented in localtime even if the hardware clock set to UTC):<br />
<br />
# hwclock --show<br />
$ date<br />
<br />
=== Set clock ===<br />
To set the system clock directly:<br />
<br />
# date MMDDhhmmYYYY<br />
<br />
To set the hardware clock directly (the argument must be in local time, even if you keep your hardware clock in UTC.):<br />
# hwclock --set --date="YYYY-MM-DD hh:mm:ss"<br />
<br />
The hardware clock can be set from the system clock and vice versa:<br />
<br />
# hwclock --systohc<br />
# hwclock --hctosys<br />
<br />
=== hwclock daemon ===<br />
{{accuracy}}<br />
Standard behavior of most operating systems is:<br />
* Set the system clock from the hardware clock on boot<br />
* Keep accurate time of the system clock with an [[Network Time Protocol daemon|NTP]] daemon<br />
* Set the hardware clock from the system clock on shutdown. <br />
<br />
In Arch Linux, the {{ic|/etc/rc.d/hwclock}} daemon uses {{ic|hwclock}} to set the system and hardware clocks on boot and shutdown if {{ic|hwclock}} is in the {{ic|DAEMONS}} list in {{ic|/etc/rc.conf}}). Running the {{ic|hwclock}} daemon is not recommended if running the [[ntpd|NTP daemon]] as the NTP daemon also adjusts the hardware clock.<br />
<br />
== Time standard ==<br />
There are two time standards: '''localtime''' and '''C'''oordinated '''U'''niversal '''T'''ime ('''UTC'''). The localtime standard is dependent on the current ''time zone'', while UTC is the ''global'' time standard and is independent of time zone values. Though conceptually different, UTC is also known as GMT.<br />
<br />
The standard used by hardware clock is defined by operating system. By default, Windows uses localtime, Mac OS uses UTC, and UNIX-like operating systems vary. <br />
<br />
When using Linux it is beneficial to have the hardware clock set to the UTC standard and made known to all operating systems. Defining the hardware clock in Linux as UTC means that Daylight Savings Time will automatically be accounted for. If using the localtime standard the system clock will not be changed for DST occurrences assuming that another operating system will take care of the DST switch (and provided no NTP agent is operating).<br />
<br />
You can set the hardware clock time standard through the command line. You can check what you have set your Arch Linux install to use by:<br />
<br />
$ grep ^HARDWARECLOCK /etc/rc.conf<br />
<br />
The hardware clock can be queried and set with the {{ic|hwclock}} command. To immediately change the hardware clock time standard to localtime use:<br />
<br />
# hwclock --localtime<br />
<br />
And to set it to UTC use:<br />
<br />
# hwclock --utc<br />
<br />
The time standard that the hardware clock uses will also need to be entered in your Arch Linux system configuration ([[rc.conf]]) so that the system clock will be correctly set on boot:<br />
<br />
HARDWARECLOCK="localtime"<br />
<br />
or<br />
<br />
HARDWARECLOCK="UTC"<br />
<br />
During kernel startup, at the point when the rtc driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of {{ic|/proc/sys/class/rtcN/hctosys}} (N=0,1,2,..) will be set to 1. Later during execution of {{ic|/etc/rc.sysinit}}, the system clock is set again from the hardware clock dependent on the value of HARDWARECLOCK. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards which is always a bad idea.<br />
<br />
=== UTC in Windows ===<br />
<br />
Add the DWORD value:<br />
<br />
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal<br />
<br />
with hexadecimal value 1 to the registry (through regedit). Windows XP and Windows Vista SP1 have support for setting the time standard as {{ic|UTC}} and can be activated in the same way however there is a bug after resuming from the suspend/hibernation state that resets the clock to {{ic|localtime}}. For these operating systems it is recommended to use {{ic|localtime}}.<br />
<br />
The hardware clock and system clock time may need to be [[#Set clock|updated]] after setting this value.<br />
<br />
== Time Zone ==<br />
<br />
Be sure that your time zone is set correctly in {{ic|/etc/rc.conf}}. This is necessary not only for the localtime to be set correctly but also for other programs you may use. You can do this by:<br />
<br />
$ grep ^TIMEZONE /etc/rc.conf<br />
<br />
You can find the time zones listed in {{ic|/usr/share/zoneinfo/}} and then you will need to find a major city that exists to your time zone. If you live in a specialized time zone area these will be listed in sub-directories. An example configuration:<br />
<br />
TIMEZONE="America/Chicago"<br />
<br />
The new time zone will be taken into effect when you reboot. To change the timezone immediately you will need to link or copy it to {{ic|/etc/localtime}}:<br />
<br />
# cp /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
When you [[#Time Set|set the hardware clock]] the new time zone will be take used.<br />
<br />
== Time Skew ==<br />
<br />
Every clock has a value that differs from ''real time'' (the best representation of which being [[Wikipedia:International Atomic Time|International Atomic Time]]), no clock is perfect. A quartz based electronic clock keeps imperfect time, but maintains a consistent inaccuracy. This base 'inaccuracy' is known as 'time skew' or 'time drift'. <br />
<br />
When the hardware clock is set with {{ic|hwclock}}, a new drift value is calculated in seconds per day. The drift value is calculated by using the difference between the new value set and the hardware clock value just before the set, taking into account the value of the previous drift value and the last time the hardware clock was set. The new drift value and the time when the clock was set is written to the file {{ic|/var/lib/hwclock/adjtime}} overwriting the previous values. The hardware clock can be adjusted for drift when the command {{ic|hwclock --adjust}} is run; this occurs by default on shutdown if the {{ic|hwclock}} daemon is enabled. <br />
<br />
{{Note|If the hwclock has been set again less than 24 hours after a previous set, the drift is not recalculated as {{ic|hwclock}} considers the elapsed time period too short to accurately calculate the drift. It may be worth occasionally to stay in Linux so it gets calculated}}<br />
<br />
If the hardware clock keeps losing or gaining time in large increments, it is possible that an invalid drift has been recorded. This can happen if you have set the hardware clock time incorrectly or your [[#Time Standard|time standard]] is not synchronized with a Windows or Mac OS install. The drift value can be removed by removing the file {{ic|/var/lib/hwclock/adjtime}}, then set the correct hardware clock and system clock time, and check if your [[#Time Standard|time standard]] is correct.<br />
<br />
The software clock is very accurate but like most clocks is not perfectly accurate and will drift as well. Though rarely, the system clock can lose accuracy if the kernel skips interrupts. There are some tools to improve software clock accuracy:<br />
* [[NTP]] can synchronize the software clock of a GNU/Linux system with internet time servers using the Network Time Protocol. NTP can also adjust the interrupt frequency and the number of ticks per second to decrease system clock drift.<br />
* {{AUR|adjtimex}} in [[Arch User Repository|AUR]] can adjust kernel time variables like interrupt frequency to help improve the system clock time drift.<br />
<br />
== It's About 'Time' == <br />
<!-- This was the introduction to the original 'Time' article by [[User:Android]]; kept for nostalgia's sake. --><br />
<br />
Our concept of time speaks much more to our limited perception than it does to the nature of what we observe. Time is clearly the most fertile ground for a fundamental shift in the human conception of the objective natural universe.<br />
<br />
Time has been measured since the beginning of time, at least as a human concept. The most obvious natural marker of the passage of time is the progression of day and night. The "day" was the first known measure of time and still forms a fundamental part of timekeeping. Other cyclic natural phenomena are also historically associated with time; the word "tide" comes from a common etymological root. Even with computer timekeeping, the day is a fundamental concept.<br />
<br />
As the measurement of time has improved, standard measures of time have had to be revised. The "leapyear" accounts for the fact that the Earth's orbit around the sun is not exactly 365 days. With the advent of atomic clocks in the 1960s, it became clear that the Earth's daily rotation was gradually slowing down (primarily due to tidal friction). The definition of the second in terms of cesium atom oscillations is the basis of the time standard known as [[Wikipedia:International Atomic Time|'''I'''nternational '''A'''tomic '''T'''ime]], or '''TAI'''.<br />
<br />
The slow and irregular increase in the amount of time comprising a day occasionally causes problems with the POSIX definition of a day as 86400 seconds. This led to the introduction of the "leapsecond" in 1972. Occasionally a second must be inserted into the normally defined UTC sequence in order to keep it synchronized with TAI. <br />
<br />
== Resources ==<br />
<br />
* [http://www.linuxsa.org.au/tips/time.html Linux Tips - Linux, Clocks, and Time]<br />
* [http://www.twinsun.com/tz/tz-link.htm Sources for Time Zone and Daylight Saving Time Data] for {{Pkg|tzdata}}<br />
* [http://www.ucolick.org/~sla/leapsecs/timescales.html Time Scales]<br />
* [[Wikipedia:Time]]</div>Ivangorrionhttps://wiki.archlinux.org/index.php?title=Network_configuration&diff=180884Network configuration2012-01-28T14:11:44Z<p>Ivangorrion: </p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Getting and installing Arch (English)]]<br />
{{i18n|Configuring Network}}<br />
{{Article summary start}}<br />
{{Article summary text|A simple guide for setting up and troubleshooting network.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Networking overview}}}}<br />
{{Article summary end}}<br />
<br />
==Check first==<br />
Many times, the basic installation procedure has created a working network configuration. To check if this is so, use the following command:<br />
{{hc|$ ping -c 3 www.google.com|<nowiki><br />
PING www.l.google.com (74.125.224.146) 56(84) bytes of data.<br />
64 bytes from 74.125.224.146: icmp_req=1 ttl=50 time=437 ms<br />
64 bytes from 74.125.224.146: icmp_req=2 ttl=50 time=385 ms<br />
64 bytes from 74.125.224.146: icmp_req=3 ttl=50 time=298 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 1999ms<br />
rtt min/avg/max/mdev = 298.107/373.642/437.202/57.415 ms<br />
</nowiki>}}<br />
{{Tip| The {{ic|-c 3}} options instruct {{ic|ping}} to do so three times. See {{ic|man ping}} for more information.}}<br />
<br />
If it works, then you may only wish to personalize your settings from the options below.<br />
<br />
==Set the host name==<br />
A host name is a unique name created to identify a machine on a network. With Arch Linux, a machine's host name is set in {{ic|/etc/[[rc.conf]]}} or until a restart using the {{ic|hostname}} command.<br />
Host names are restricted to alphanumeric characters. The dash ({{ic|-}}) can be used, but a host name cannot start or end with it. Length is restricted to 63 characters.<br />
<br />
Edit {{ic|/etc/rc.conf}} and set the {{ic|HOSTNAME}} variable ({{ic|archlinux}} in this example):<br />
HOSTNAME="archlinux"<br />
<br />
After setting a host name, it is also important to include the same host name in {{ic|/etc/hosts}}. This will help processes that refer to the computer by its host name to find its IP address, as well as programs that rely on the {{ic|gethostname()}} system call to determine the system's host name.<br />
<br />
Edit {{ic|/etc/hosts}} and add the same HOSTNAME you entered in {{ic|/etc/rc.conf}}:<br />
127.0.0.1 archlinux.domain.org localhost.localdomain localhost archlinux<br />
<br />
{{Note|The fully qualified domain name (FQDN) should be '''the first item following the IP address'''. All of the names on the right side are just aliases for the left-most host/domain name. You can check if this has been properly configured by running {{ic|hostname --fqdn}}.}}<br />
<br />
To set the host name temporarily (until the next reboot) use the {{ic|hostname}} command as root:<br />
{{bc|# hostname archlinux}}<br />
{{note|The {{ic|hostname}} utility moved from {{Pkg|net-tools}} to {{Pkg|inetutils}}. [https://www.archlinux.org/news/hostname-utility-moved-from-net-tools-to-inetutils/]}}<br />
<br />
==Load the device module==<br />
Udev should detect your network interface card (NIC) module and load it automatically at startup. If it does, skip this section. Otherwise, you will need to know which module is needed for your particular model:<br />
# hwdetect --show-net<br />
Since hwdetect isn't installed by default and most NICs work out of the box on linux, you're better of using lspci<br />
# lspci | grep -i Ethernet <br />
Then google for the right module/driver for the chip<br />
<br />
<br />
Once you know which module to use, you can load it with:<br />
# modprobe ''<modulename>''<br />
<br />
If [[udev]] is not detecting and loading the proper module automatically during bootup, you can add it into the {{ic|MODULES}} array in {{ic|/etc/rc.conf}}, so you do not need to {{ic|modprobe}} it everytime you boot. For example, if {{ic|tg3}} is the network module:<br />
MODULES=(... tg3 snd-cmipci ...)<br />
<br />
Other common modules are 8139too for cards with the Realtek chipset or {{ic|sis900}} for SiS cards.<br />
<br />
==Configure IP==<br />
It is important to realize that you may have a dynamically assigned address using DHCP or an unchanging "static" address. (see [[Wikipedia:Dynamic Host Configuration Protocol|Wikipedia:DHCP]] for more information)<br />
{{Note|For motherboards that have integrated NICs, it is important to know which one is considered the primary NIC (e.g. ''eth0'') and which is considered the secondary NIC (e.g. eth1). Many configuration issues are caused by users incorrectly configuring ''eth0'' in their {{ic|/etc/rc.conf}}, when in fact, they have their Ethernet cable plugged into ''eth1''.}}<br />
<br />
===For DHCP IP===<br />
For this option, you need the {{Pkg|dhcpcd}} package (already available on most installations). To make use of it, edit {{ic|/etc/rc.conf}} like this:<br />
interface="eth0"<br />
address=<br />
netmask=<br />
gateway=<br />
<br />
Only the interface has to be defined, as leaving the other options blank will set network to DHCP.<br />
<br />
If you use DHCP and you do '''not''' want your DNS servers automatically assigned every time you start your network, be sure to add the following to the last section of {{ic|/etc/dhcpcd.conf}}:<br />
nohook resolv.conf<br />
<br />
Then add your own DNS nameserver to {{ic|/etc/resolv.conf}}.<br />
<br />
Make sure to test your new settings by stopping and starting the {{ic|/etc/rc.d/network}} daemon, as opposed to bringing down your interface and starting DHCP manually. To restart the network daemon:<br />
# /etc/rc.d/network restart<br />
<br />
You may use the {{Pkg|openresolv}} package if several different processes want to control {{ic|/etc/resolv.conf}} (i.e. {{Pkg|dhcpcd}} and a VPN client). No additional configuration for {{Pkg|dhcpcd}} is needed to use {{Pkg|openresolv}}.<br />
<br />
{{Note|1=It is possible to have a static IP using {{Pkg|dhcpcd}}. Simply edit your {{ic|/etc/conf.d/dhcpcd}} file to look something like this (where x.x.x.x is your desired IP address):<br />
DHCPCD_ARGS="-q -s x.x.x.x"}}<br />
<br />
===For Static IP Addresses===<br />
There are various reasons why you may wish to assign static IP addresses on your network. For instance, one may gain a certain degree of predictability. Also, if you share your Internet connection from a Windows box without a router, be sure to use static IP addresses on both computers. Otherwise you will have LAN issues.<br />
<br />
You need:<br />
* Your static IP address,<br />
* The subnet mask,<br />
* The broadcast address,<br />
* Your gateway's IP address,<br />
* Your name servers' IP addresses,<br />
* Your domain name (unless a local LAN, in which case you can make it up).<br />
<br />
If you are running a private network, it is safe to use IP addresses in 192.168.*.* for your IP addresses, with a netmask of 255.255.255.0 and a broadcast address of 192.168.*.255. Unless your network has a router, the gateway IP address does not matter. Edit {{ic|/etc/rc.conf}} like this, substituting your own values for the IP address, netmask, broadcast, and gateway:<br />
interface=eth0<br />
address=192.168.0.2<br />
netmask=255.255.255.0<br />
gateway=192.168.22.1<br />
<br />
Edit your {{ic|/etc/resolv.conf}} like this, substituting your name servers' IP addresses and your local domain name:<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 3 {{ic|nameserver}} lines.}}<br />
<br />
====Manual assignment====<br />
You can assign a static IP in console:<br />
# ip addr add <ip address>/<netmask> dev <interface><br />
For example:<br />
# ip addr add 192.168.1.2/24 dev eth0<br />
<br />
For more options, see: {{ic|man ip}}<br />
<br />
Add your gateway like so:<br />
# ip route add default via <ip address><br />
(Substitute your own gateway's IP address)<br />
<br />
For example:<br />
# ip route add default via 192.168.1.1<br />
<br />
==Load configuration==<br />
To test your settings either reboot the computer, or as root:<br />
{{bc|# /etc/rc.d/network restart}}<br />
<br />
Try pinging your gateway, DNS server, ISP provider and other Internet sites, in that order, to detect any connection problems along the way, as in this example:<br />
{{bc|$ ping -c 3 www.google.com}}<br />
<br />
==Additional settings==<br />
<br />
===Enable/disable interface===<br />
You can activate or deactivate net interface:<br />
# ip link set <interface> up/down<br />
<br />
===Firewall===<br />
You can install and configure a [[Firewalls|firewall]] to feel more secure.<br />
<br />
===Wireless Setup===<br />
See the [[Wireless Setup]] article for more information.<br />
<br />
===Laptops, 'ifplugd'===<br />
You can install a daemon which will automatically configure your Ethernet device when a cable is plugged in and automatically unconfigure it if the cable is pulled. This is useful on laptops with onboard network adapters, since it will only configure the interface when a cable is really connected. Another use is when you just need to restart the network but do not want to restart the computer or do it from the shell.<br />
<br />
Installation is very simple since {{Pkg|ifplugd}} is in the [[Official Repositories]]:<br />
<br />
By default it is configured to work for the {{ic|eth0}} device. This and other settings like delays can be configured in {{ic|/etc/ifplugd/ifplugd.conf}}.<br />
<br />
[[Daemon#Performing daemon actions manually|Start the ifplugd daemon]] and add {{ic|ifplugd}} to your [[Daemons#Starting on Boot|DAEMONS array]] so it starts automatically on boot.<br />
<br />
===Jumbo Frames===<br />
See the [[Jumbo Frames]] article for more information.<br />
<br />
===Bonding or LAG===<br />
You will need {{Pkg|netcfg}} from the [[Official Repositories]], as well as the {{AUR|netcfg-bonding}} package from the [[AUR]].<br />
<br />
<br />
Edit/create the following files:<br />
<br />
<br />
Create {{ic|/etc/network.d/bonded}}:<br />
{{hc<br />
|/etc/network.d/bonded<br />
|<nowiki><br />
CONNECTION="bonding"<br />
INTERFACE="bond0"<br />
SLAVES="eth0 eth1"<br />
IP="dhcp"<br />
DHCP_TIMEOUT=10<br />
</nowiki>}}<br />
<br />
<br />
Edit your {{ic|/etc/rc.conf}}:<br />
{{hc<br />
|/etc/rc.conf<br />
|<nowiki><br />
<br />
MODULES=(... bonding ...)<br />
<br />
...<br />
<br />
interface=bond0 #comment other lines (address,netmask,gateway,...)<br />
<br />
...<br />
<br />
NETWORKS=(... bonded ...)<br />
<br />
...<br />
<br />
DAEMONS=(... net-profiles ...) #replace network <br />
<br />
</nowiki>}}<br />
<br />
<br />
To activate the new bonded ports modprobe {{ic|bonding}}, stop {{ic|network}} and start the {{ic|net-profiles}} service:<br />
<br />
# modprobe bonding<br />
<br />
# rc.d stop network<br />
<br />
# rc.d start net-profiles<br />
<br />
===IP aliasing===<br />
{{Expansion}}<br />
If you want to use multiple IP addresses on an interface, you will have to use [[netcfg]] and its {{ic|POST_UP}} and {{ic|PRE_DOWN}} commands in your network profile to set up the additional IP addresses manually. See [https://bbs.archlinux.org/viewtopic.php?pid=1036395#p1036395 here] for details.<br />
<br />
====Example====<br />
You will need {{Pkg|netcfg}} from the [[Official Repositories]].<br />
<br />
Prepare configuration<br />
<br />
{{hc<br />
|/etc/network.d/mynetwork<br />
|<nowiki><br />
<br />
CONNECTION='ethernet'<br />
DESCRIPTION='Five different addresses on the same NIC.'<br />
INTERFACE='eth0'<br />
IP='static'<br />
ADDR='192.168.1.10'<br />
GATEWAY='192.168.1.1'<br />
DNS=('192.168.1.1')<br />
DOMAIN=''<br />
POST_UP='x=0; for i in 11 12 13 14; do ip addr add 192.168.1.$i/24 brd 192.168.1.255 dev eth0 label eth0:$((x++)); done'<br />
PRE_DOWN='for i in 11 12 13 14; do ip addr del 192.168.1.$i/24 dev eth0; done'<br />
<br />
</nowiki>}}<br />
<br />
{{hc<br />
|/etc/rc.conf<br />
|<nowiki><br />
NETWORKS=(mynetwork)<br />
<br />
...<br />
<br />
DAEMONS=(... net-profiles ...)<br />
</nowiki>}}<br />
<br />
===Change MAC/hardware address===<br />
Changing your MAC address is not possible anymore via {{ic|/etc/rc.conf}}. See [[MAC Address Spoofing]] for details.<br />
<br />
==Troubleshooting==<br />
<br />
=== DHCP fails at boot ===<br />
First, check all the steps that the computer normally executes at boot in order to find out which one failed. <br />
These steps are:<br />
# Detect the network device and load its driver. <br />
# Bring up the interface. <br />
# Call {{ic|dhcp}}<br />
<br />
====Step 1====<br />
Check the "Ethernet controller" entry in the output of {{ic|lspci -v}}.<br />
It should tell you which kernel module contains the driver of your network device. For example:<br />
{{hc|$ lspci -v|<nowiki><br />
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0)<br />
...<br />
Kernel driver in use: atl1<br />
Kernel modules: atl1<br />
</nowiki>}}<br />
Next, check that the driver was loaded via ''dmesg | grep <module name>''. For example:<br />
$ dmesg |grep atl1<br />
...<br />
atl1 0000:02:00.0: eth0 link is up 100 Mbps full duplex<br />
<br />
====Step 2====<br />
Check the output of {{ic|dmesg}} for the interface associated with your network device and bring it up via (as root) <br />
{{bc|# ip link set <interface> up}}<br />
<br />
Check the result with {{ic|ip addr show dev eth0}}. For example:<br />
{{hc|$ ip addr show dev eth0|<nowiki><br />
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc vboxnetflt state UP qlen 1000<br />
[...]<br />
</nowiki>}}<br />
<br />
====Step 3====<br />
To be on the safe side, start by releasing the lease of your interface with {{ic|dhcpcd --release}}, then try to get a lease with {{ic|dhcpcd}}. Refer to {{ic| man dhcpcd}} for more information.<br />
<br />
If all goes well, it will look like this:<br />
{{hc|# dhcpcd --release eth0|<nowiki><br />
dhcpcd: dhcpcd not running</nowiki>}}<br />
{{hc|# dhcpcd eth0|<nowiki><br />
dhcpcd: version 5.1.1 starting<br />
dhcpcd: eth0: broadcasting for a lease<br />
...<br />
dhcpcd: eth0: leased 192.168.1.70 for 86400 seconds<br />
</nowiki>}}<br />
<br />
And now {{ic|ip addr show dev <interface>}} should show your inet address.<br />
<br />
Probably things will not work as described somewhere along these steps, or else the network would have started automatically at boot.<br />
<br />
If {{ic|dhcp}} works using the steps above but not at boot, add the following to {{ic|/etc/rc.local}}:<br />
dhcpcd -k eth0 <br />
dhcpcd -nd eth0<br />
<br />
See http://bbs.archlinux.org/viewtopic.php?id=63940 for more information.<br />
<br />
For some people, the {{ic|dhclient}} package (available in [extra]) works where {{ic|dhcpcd}} fails.<br />
<br />
===Swapping computers on the cable modem===<br />
Most domestic cable ISPs (videotron for example) have the cable modem configured to recognise only one client PC, by the MAC address of its network interface. Once the cable modem has learnt the MAC address of the first PC or equipment that talks to it, it will not respond to another MAC address in any way. Thus if you swap one PC for another (or for a router), the new PC (or router) will not work with the cable modem, because the new PC (or router) has a different MAC address to the old one. To reset the cable modem so that it will recognise the new PC, you must power the cable modem off and on again. Once the cable modem has rebooted and gone fully online again (indicator lights settled down), reboot the newly connected PC so that it makes a DHCP request, or manually make it request a new DHCP lease.<br />
<br />
If this method does not work, you will need to clone the MAC address of the original machine. See also [[Configuring Network#Change MAC/hardware address|Change MAC/hardware address]].<br />
<br />
===The TCP window scaling issue===<br />
TCP packets contain a "window" value in their headers indicating how much data the other host may send in return. This value is represented with only 16 bits, hence the window size is at most 64Kb. TCP packets are cached for a while (they have to be reordered), and as memory is (or used to be) limited, one host could easily run out of it.<br />
<br />
Back in 1992, as more and more memory became available, [http://www.faqs.org/rfcs/rfc1323.html RFC 1323] was written to improve the situation: Window Scaling. The "window" value, provided in all packets, will be modified by a Scale Factor defined once, at the very beginning of the connection.<br />
<br />
That 8-bit Scale Factor allows the Window to be up to 32 times higher than the initial 64Kb.<br />
<br />
It appears that some broken routers and firewalls on the Internet are rewriting the Scale Factor to 0 which causes misunderstandings between hosts.<br />
<br />
The Linux kernel 2.6.17 introduced a new calculation scheme generating higher Scale Factors, virtually making the aftermaths of the broken routers and firewalls more visible. <br />
<br />
The resulting connection is at best very slow or broken.<br />
<br />
====How to diagnose the problem====<br />
First of all, lets make it clear: this problem is odd. In some cases, you will not be able to use TCP connections (HTTP, FTP, ...) at all and in others, you will be able to communicate with some hosts (very few).<br />
<br />
When you have this problem, the {{ic|dmesg}}'s output is OK, logs are clean and {{ic|ip addr}} will report normal status &mdash; and actually everything appears normal.<br />
<br />
If you cannot browse any website, but you can ping some random hosts, chances are great that you're experiencing this issue: ping uses ICMP and is not affected by TCP issues.<br />
<br />
You can try to use Wireshark. You might see successful UDP and ICMP communications but unsuccessful TCP communications (only to foreign hosts).<br />
<br />
====How to fix it (The bad way)====<br />
To fix it the bad way, you can change the tcp_rmem value, on which Scale Factor calculation is based. Although it should work for most hosts, it is not guaranteed, especially for very distant ones.<br />
<br />
echo "4096 87380 174760" > /proc/sys/net/ipv4/tcp_rmem<br />
<br />
====How to fix it (The good way)====<br />
Simply disable Window Scaling. Since Window Scaling is a nice TCP feature, it may be uncomfortable to disable it, especially if you cannot fix the broken router. There are several ways to disable Window Scaling, and it seems that the most bulletproof way (which will work with most kernels) is to add the following line to {{ic|/etc/sysctl.conf}} (see also [[sysctl]])<br />
<br />
net.ipv4.tcp_window_scaling = 0<br />
<br />
====How to fix it (The best way)====<br />
This issue is caused by broken routers/firewalls, so lets change them. Some users have reported that the broken router was their very own DSL router.<br />
<br />
====More about it====<br />
This section is based on the LWN article [http://lwn.net/Articles/92727/ TCP window scaling and broken routers] and a Kernel Trap article: [http://kerneltrap.org/node/6723 Window Scaling on the Internet].<br />
<br />
There are also several relevant threads on the LKML.<br />
<br />
=== Interface names varying ===<br />
<br />
Your network cards are sometimes named differently between two reboots. Configuring your network connection is hard if you do not know if your card will be called {{ic|eth0}} or {{ic|eth1}}.<br />
You can fix this using {{ic|ifrename}}, see [[Rename network interfaces]]<br />
<br />
It is also possible to manually create udev rules that assign interface names based on the interface's MAC address.<br />
<br />
{{hc|/etc/udev/rules.d/10-network.rules|<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 />
{{Note|Make sure to use the lower-case hex values in your udev rules. It doesn't like uppercase.}}<br />
<br />
For more information or the original udev guide on the last two methods, see the [[Udev]] wiki entry on this issue.<br />
<br />
[[Udev#Mixed Up Devices, Sound/Network Cards Changing Order Each Boot]]<br />
<br />
===Realtek no link / WOL issue===<br />
Users with Realtek 8168 8169 8101 8111(C) based NICs (cards / and on-board) may notice an issue where the NIC seems to be disabled on boot and has no Link light. This can usually be found on a dual boot system where Windows is also installed. It seems that using the offical Realtek drivers (dated anything after May 2007) under Windows is the cause. These newer drivers disable the Wake-On-LAN feature by disabling the NIC at Windows shutdown time, where it will remain disabled until the next time Windows boots. You will be able to notice if this issue is affecting you if the Link light remains off until Windows boots up; during Windows shutdown the Link light will switch off. Normal operation should be that the link light is always on as long as the system is on, even during POST. This issue will also affect other operative systems without newer drivers (eg. Live CDs). Here are a few fixes for this issue:<br />
<br />
====Method 1 - Rollback/change Windows driver====<br />
You can roll back your Windows NIC driver to the Microsoft provided one (if available), or roll back/install an official Realtek driver pre-dating May 2007 (may be on the CD that came with your hardware).<br />
<br />
====Method 2 - Enable WOL in Windows driver====<br />
Probably the best and the fastest fix is to change this setting in the Windows driver. This way it should be fixed system-wide and not only under Arch (eg. live CDs, other operative systems). In Windows, under Device Manager, find your Realtek network adapter and double-click it. Under the Advanced tab, change "Wake-on-LAN after shutdown" to Enable.<br />
In Windows XP (example)<br />
Right click my computer<br />
--> Hardware tab<br />
--> Device Manager<br />
--> Network Adapters<br />
--> "double click" Realtek ...<br />
--> Advanced tab<br />
--> Wake-On-Lan After Shutdown<br />
--> Enable<br />
<br />
{{Note|Newer Realtek Windows drivers (tested with ''Realtek 8111/8169 LAN Driver v5.708.1030.2008'', dated 2009/01/22, available from GIGABYTE) may refer to this option slightly differently, like ''Shutdown Wake-On-LAN --> Enable''. It seems that switching it to {{ic|Disable}} has no effect (you will notice the Link light still turns off upon Windows shutdown). One rather dirty workaround is to boot to Windows and just reset the system (perform an ungraceful restart/shutdown) thus not giving the Windows driver a chance to disable LAN. The Link light will remain on and the LAN adapter will remain accessible after POST - that is until you boot back to Windows and shut it down properly again.}}<br />
<br />
====Method 3 - Newer Realtek Linux driver====<br />
Any newer driver for these Realtek cards can be found for Linux on the realtek site. (untested but believed to also solve the problem).<br />
<br />
====Method 4 - Enable ''LAN Boot ROM'' in BIOS/CMOS====<br />
It appears that setting ''Integrated Peripherals --> Onboard LAN Boot ROM --> Enabled'' in BIOS/CMOS reactivates the Realtek LAN chip on system boot-up, despite the Windows driver disabling it on OS shutdown.<br />
<br><small>This was tested successfully multiple times with GIGABYTE system board GA-G31M-ES2L with BIOS version F8 released on 2009/02/05. YMMV.</small><br />
<br />
===DLink G604T/DLink G502T DNS issue===<br />
Users with a DLink G604T/DLink G502T router, using DHCP and have firmware v2.00+ (typically users with AUS firmware) may have issues with certain programs not resolving the DNS. One of these programs are unfortunatley pacman. The problem is basically the router in certain situations is not sending the DNS properly to DHCP, which causes programs to try and connect to servers with an IP of 1.0.0.0 and fail with a connection timed out error<br />
<br />
====How to diagnose the problem====<br />
The best way to diagnose the problem is to use Firefox/Konqueror/links/seamonkey and to enable wget for pacman. If this is a fresh install of Arch Linux, then you may want to consider installing {{ic|links}} through the live CD.<br />
<br />
Firstly, enable wget for pacman (since it gives us info about pacman when it is downloading packages)<br />
Open {{ic|/etc/pacman.conf}} with your favourite editor and uncomment the following line (remove the # if it is there)<br />
<br />
XferCommand=/usr/bin/wget --passive-ftp -c -O %o %u<br />
<br />
While you are editing {{ic|/etc/pacman.conf}}, check the default mirror that pacman uses to download packages.<br />
<br />
Now open up the default mirror in an Internet browser to see if the mirror actually works. If it does work, then do {{ic|pacman -Syy}} (otherwise pick another working mirror and set it to the pacman default). If you get something similar to the following (notice the 1.0.0.0),<br />
<nowiki>ftp://mirror.pacific.net.au/linux/archlinux/extra/os/i686/extra.db.tar.gz</nowiki> <br />
<nowiki>=> `/var/lib/pacman/community.db.tar.gz.part'</nowiki><br />
Resolving mirror.pacific.net.au... 1.0.0.0<br />
then you most likely have this problem. The 1.0.0.0 means it is unable to resolve DNS, so we must add it to {{ic|/etc/resolv.conf}}.<br />
<br />
====How to fix it====<br />
Basically what we need to do is to manually add the DNS servers to our {{ic|/etc/resolv.conf}} file. The problem is that DHCP automatically deletes and replaces this file on boot, so we need to edit {{ic|/etc/conf.d/dhcpcd}} and change the flags to stop DHCP from doing this.<br />
<br />
When you open {{ic|/etc/conf.d/dhcpcd}}, you should see something close to the following:<br />
DHCPCD_ARGS="-t 30 -h $HOSTNAME"<br />
Add the -R flag to the arguments, e.g.<br />
DHCPCD_ARGS="-R -t 30 -h $HOSTNAME"<br />
<br />
{{Note|1=If you are using {{Pkg|dhcpcd}} >= 4.0.2, the {{ic|-R}} flag has been deprecated. Please see the [[#For DHCP IP]] section for information on how to use a custom {{ic|/etc/resolv.conf}} file.}}<br />
<br />
Save and close the file; now open {{ic|/etc/resolv.conf}}. You should see a single nameserver (most likely 10.1.1.1). This is the gateway to your router, which we need to connect to in order to get the DNS servers of your ISP. Paste the IP address into your browser and log in to your router. Go to the DNS section, and you should see an IP address in the Primary DNS Server field; copy it and paste it as a nameserver ABOVE the current gateway one.<br />
<br />
E.g. a {{ic|/etc/resolv.conf}} should look something along the lines of<br />
nameserver 10.1.1.1<br />
<br />
If my primary DNS server is 211.29.132.12, then change {{ic|/etc/resolv.conf}} to<br />
nameserver 211.29.132.12<br />
nameserver 10.1.1.1<br />
<br />
Now restart the network daemon by doing {{ic|/etc/rc.d/network restart}} and do {{ic|pacman -Syy}}. If it syncs correctly with the server, then the problem is solved.<br />
<br />
====More about it====<br />
This is the whirlpool forum (Australian ISP community) which talks about and gives the same solution to the problem<br />
http://forums.whirlpool.net.au/forum-replies-archive.cfm/461625.html<br />
<br />
===Get an IP from the wrong DHCP in linked (by VPN) router cases===<br />
In my case, I have a network where two routers are tied together through VPN. I have one router at my home, and one at a completely different place in the world. In some rare cases, it appears that the router that is connected to me by VPN is assigning me an IP address. I do not know a way to prevent that process, but I do know a way to fix it. On a console, as root, try this:<br />
dhcpcd -k<br />
dhcpcd<br />
The first line releases your IP and the next line requests a new one. I had to run those two commands three times till my issue was fixed, so do not expect it to work after just one try. If that also fails, you might need to disconnect the VPN connection and try it again with the commands above.<br />
<br />
This even works when NetworkManager is installed.<br />
<br />
===Realtek 8111E loses lots of packets/dmesg is flooded with link messages===<br />
This issue currently plagues rev6 of the 8111. To check if you have this chip, check the output of the following:<br />
lspci | grep 8111<br />
<br />
If you see a line like the following:<br />
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)<br />
and dmesg has a bunch of this:<br />
r8169 0000:03:00.0: eth0: link up<br />
you are using a bad r8169 driver. To fix this, install the {{AUR|r8168}} package from the [[AUR]], [[Kernel_modules#Blacklisting|blacklist]] the r8169 kernel module, and reboot in order to fix the issue.<br />
<br />
Supposedly there is a fix for this in Linux 3.0.<br />
<br />
Source: http://forums.gentoo.org/viewtopic-t-881217-start-0.html<br />
<br />
==Related==<br />
[[Samba]]</div>Ivangorrionhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Package_Signing_Proposal_for_Pacman&diff=180344DeveloperWiki:Package Signing Proposal for Pacman2012-01-26T12:28:00Z<p>Ivangorrion: </p>
<hr />
<div>[[Category:Package development (English)]]<br />
[[Category:Pacman development (English)]]<br />
This is a proposal for the package signing feature for Pacman. Here we'll gather ideas and commitments, so the implementation will be guided by this document.<br />
<br />
See also: [[Pacman package signing]]<br />
<br />
== Introduction ==<br />
<br />
Package signing is a long asked feature for Pacman. The goal of this implementation is to guarantee that a package was created by the person that claims to have made it.<br />
<br />
For that to work, we'll use GnuPG as the tool to sign, verify and manage the group of keys that are trusted.<br />
<br />
== Web of Trust - Simple introduction ==<br />
<br />
A web of trust is the concept used by OpenPGP (and GnuPG) for the management of trust policies in its public key system. As there's no concept of a central authoritative entity, there is the need of some kind of verification of the public keys that we accept in our keyring. Keys can be signed by other users, indicating that they trust in the veracity of the key. But the verification can become cumbersome, as the number of keys exchanged increases. To solve this, the concept of Web of Trust was introduced. If I trust enough in a friend, I can sign his key in my keyring and tell to gpg that I also trust in the keys that he signs. So, if I verify a file that was signed by a person that my friend trusts, gpg will accept the signature as valid. When I import the third person's public key, gpg will mark it as a valid key.<br />
<br />
In GnuPG, there are four levels of trust in a public key:<br />
<br />
; unknown: I did not say anything about this key yet<br />
; none: I do not trust this public key to sign other keys (this just affects the signature keys, not the signatures of files)<br />
; marginal: I have a little trust in this public key to sign other keys<br />
; fully: I trust completely in this public key, as if it was my own<br />
; ultimately: the same level of trust as your own key<br />
<br />
So, GnuPG can be configured to accept a key as valid if it has 3 marginally trusted key signatures or 1 fully trusted key signature (this is the default). Or it can be any other combination, if properly configured.<br />
<br />
The following is a suggestion for the use of GnuPG to sign and manage the pacman's keyring, together with the creation of a web of trust for the Arch Developers. It is very similar to what Debian and Fedora do, although there are some differences, because of our way of doing things.<br />
<br />
== Pacman's keyring ==<br />
<br />
Pacman will have a separated keyring, so the root's keyring will not be affected by keys that are intended for use with package signing. This is already implemented in Allan's pacman git branch for gpg support. The directory will be /etc/pacman.d/gnupg/. There will be the public key database, the trust database and a fake private key database, because GnuPG doesn't work very well without one (according to Debian's apt-key script).<br />
<br />
The keyring will be populated based on the keys from the pacman-keyring package. In this package, there will be a file for the valid keys and one for the removed keys, so that the post-install script can revoke keys that may not be trusted anymore (be it for security reasons or because some developer has left the project). There'll be signature files for the two sets of keys, so the updatedb script can check to see if they are valid before updating.<br />
<br />
== Arch Key Signing keys ==<br />
<br />
There will be 3 keys for the sole purpose of signing other developers' keys (hereafter named KSK, Key Signing Keys). They will be created by 3 developers (hereafter named Key Signers) that will be responsible for the role of signing the other developers' keys (and their own too). This procedure is very important and must be done with the certainty that the keys being signed are from the person they plead to be. The confirmation of the fingerprints must be done via a secure channel (skype, phone call, secure email or personally). For example, Debian only trust in keys confirmed personally. We can be a little lenient because the group of developers is reduced.<br />
<br />
The Key Signers must keep his KSK secured and must choose a strong passphrase, so that even in the event of the secret keys being stolen, the risk of a real misuse will be little. In such case, there will be some time for the generation of a new set of KSK and the re-signing of the others developers' keys. The Key Signers must also generate a revocation key for each of the KSK and must keep the revocation keys secured (preferably only in printed form or in a thumbdrive stored in some kind of safe box). This is needed because anyone that owns the revocation key can revoke the corresponding key.<br />
<br />
To sign the developer's keys, the Key Signers must receive a copy of the public key (through email or from a public key server). After importing the key into his own keyring, the Key Signer must sign the public key with the KSK. After that, he needs to export the signed public key and update the pacman-keyring package (there'll be a script for that task). Only one Key Signer should update the pacman-keyring package at a time to avoid having some key being lost because of overwriting files. There must be some form of coordination between the Key Signers on who will do the task.<br />
<br />
With the KSK and the signed developers' keys, the pacman-keyring package will be created and signed with one of the KSK.<br />
<br />
=== Use case: Arch Key Signing Keys creation ===<br />
<br />
# 3 developers will be selected to be the Key Signers<br />
# Each Key Signer creates a public/private key pair in his local keyring with gpg --gen-key<br />
## We need to decide if there'll be an expiration date<br />
#Each Key Signer creates a revocation key, which will be used for revocation of the KSK, in case of compromising of the private key. gpg --gen-revoke <key id><br />
## GnuPG can generate a revocation key for other person to trigger there the revocation. So, for each KSK, there should be designated revocation keys for the other two Key Signers. They could revoke their KSK and the others too, in case of inavailability of the owner of a KSK.<br />
## The revocation key MUST be kept secure, even more than the private key. This is because any person can revoke a key. The advise from GnuPG is that the revocation key be kept in a thumb drive in a safe or printed, so that there would be no way to access the digital file of the rev. key.<br />
# Each Key Signer sends his public KSK to a predefined key server. gpg --send-keys <key id> --keyserver <url for key server><br />
# Each Key Signer fetches the other KSKs from the key server and signs them with his own KSK (not his personal key)<br />
# Each Key Signer sends the other KSKs to the server again, to update the signatures.<br />
# Each fetches again the KSKs from the key server, so they get the KSKs with all signatures from the others signers.<br />
<br />
=== Use case: Signing of developer's keys ===<br />
<br />
# If a developer doesn't have a key yet, he generates one with: gpg --gen-key<br />
# If he generated the key in the previous step, he needs to generate a revocation key too. gpg --gen-revoke <key id><br />
## The same remarks for the revocation key above apply here.<br />
# The developer exports his public key to a file or sends it to a public key server. gpg --export <key id> > key.gpg or gpg --send-key <key id> --keyserver <url for key server><br />
# The developer contacts one of the Key Signers and sends him his public key file or instructs him to fetch it from the key server. Is important to negotiate a secure channel for the exchange of fingerprint. It should not be through email. Maybe IM, Skype or through ssh session with some Arch server as temporary storage.<br />
# The Key Signer signs the developer's public key with his owned KSK.<br />
# There'll be a script to help the management of the files used to populate pacman's key ring, so the new key will be added to the set of valid keys.<br />
# The pacman-keyring package will be rebuilt and signed with a KSK (not with a common developer's key). The procedure is described in the use case for package signing.<br />
<br />
== Package signing by developers ==<br />
<br />
When a developer builds a new package, makepkg will have the options to sign the package too, with the developer's own key (not the KSK, if the developer owns one). The signature will be detached, so we can keep this process optional for people that do not care for it.<br />
<br />
=== Use case ===<br />
<br />
# A package is rebuilt and signed with makepkg --signwithkey <key id> [other options]<br />
# Developer uses tool to upload the package and signature to his staging area<br />
# Developer repeats this until there are no more packages to build<br />
# Developer uses tool to copy his packages from staging area to the final repository and sign the repo.db. The script will do the following:<br />
## check if the repo.db is locked. Just proceed if unlocked.<br />
## lock the repo.db<br />
## call repo-add to add all the new packages<br />
## copy the repo.db to the local machine of the developer<br />
## sign the local repo.db with the developer's personal key. The signature will be detached<br />
## scp the signature back (and the repo.db?) to the server<br />
## unlock the repo.db<br />
<br />
== Installation of KSK by the users ==<br />
<br />
This is a very sensitive part and must be done with caution, at the risk of driving all the work moot. The KSK should be manually verified by the user before pacman can accept the pacman-keyring package. I believe that the following would be the workflow:<br />
<br />
* the KSK and the corresponding fingerprints would be available in several channels of Arch: Home page, git repository, forums, public key servers, etc.<br />
<br />
* the user downloads the KSK and import them (with a new tool, called pacman-key, named after apt-key)<br />
<br />
* pacman-key shows the fingerprint of each KSK and asks for the approval of the user<br />
<br />
* if the user confirms, pacman imports the keys to its keyring, setting them as fully trusted<br />
<br />
After this, the pacman-keyring can be installed and the public keys of the developers can be added by the post-install script. The trustdb will be updated automatically.<br />
<br />
=== Use case ===<br />
<br />
# The user must download the pacman-key tool (or it could be provided in a version of pacman without signing capabilities).<br />
# User fetches the KSKs from a key server. The id's can be discovered on a new item or forum or mail list post. pacman-key receive <keyserver> <KSK1 id> <KSK2 id> <KSK3 id><br />
# If the user downloaded the KSKs, they must be imported to pacman's keyring. Otherwise, they are already there. pacman-key add <file with KSKs><br />
# User must trust explicitly each KSK with pacman-key trust <KSK id><br />
## The KSK fingerprint will be shown to the user. He must guarantee that he consults more than one secure source for comparison, such as Arch news item, Forum post, Mail list archive post, maybe we should have a file in git too.<br />
## The user must type 'trust' in the prompt. GnuPG will ask the level of trust that the user assigns to the key. He should answer 5 (ultimately) for the KSKs. Any value other than 5 will not make the KSK effective to assign trust to other keys signed by it. This must be further investigated. "Ultimately" should be used only for personal keys and "Fully" or "Marginal" should be effective. Maybe it is a configuration problem.<br />
## The user types 'save' to end the edit session of GnuPG<br />
# When a version of pacman able to verify signatures is available, pacman will update itself and install pacman-keyring first, as a dependency. The pacman-key tool will be used by --post-install script from pacman-keyring and will update the real pacman keyring with the keys in this package. The web of trust will be updated accordingly.<br />
<br />
== Package verification ==<br />
<br />
When pacman downloads a package, the signature will be downloaded with it, if applicable. Pacman will inform the user if the package's signature is not valid and stop. There will be no possibility to install a signed package with an invalid signature.<br />
<br />
=== Use case ===<br />
<br />
# Pacman downloads the repo.db and its corresponding signature. The following should happen:<br />
## pacman verifies if the signature date is older than n days (we must decide this). If older, stop the procedure and ask the user to change mirrors or report the bug (the lack of new versions of the repo.db will be a bug)<br />
## pacman verifies the signature to see if it is valid.<br />
# pacman downloads the packages (the signatures are already downloaded in the repository database)<br />
# Before the installation (or update), each package is verified to see if the signature is correct and is signed by a trusted key. If the package has a signature and it is not valid, it should not be installed.<br />
<br />
== Affected tools ==<br />
<br />
=== Makepkg ===<br />
<br />
There should be options to choose the key to sign a package. The key will always be from the keyring of the user building the package.<br />
<br />
=== devtools ===<br />
<br />
This is a subject that is being discussed and this text will be updated soon.<br />
<br />
=== pacman ===<br />
<br />
Allan's branch is already verifying signatures, but there are some easy changes needed to point to the right keyring.<br />
<br />
=== pacman-key ===<br />
<br />
Pacman-key is a new tool, responsible for the management of Pacman's keyring. It is a shell script and is needed because gpgme is not able to handle some operations on keyrings, so we can not change pacman to handle them too. The operations available will be, amongst others:<br />
<br />
* approval of KSK<br />
* importing/exporting of keys<br />
* fetching keys from a key server<br />
* changing level of trust for keys<br />
* removal of keys<br />
* update of trustdb<br />
<br />
== Final comments ==<br />
<br />
We believe that these suggestions are feasible and will bring a new level of quality to Arch Linux. Allan's gpg branch of pacman git repository is in a good position in relation of what I suggested above. <br />
<br />
The discussions will take place on pacman-dev mailing list and this document will be updated as the decisions are made.</div>Ivangorrionhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Package_Signing_Proposal_for_Pacman&diff=180339DeveloperWiki:Package Signing Proposal for Pacman2012-01-26T11:55:46Z<p>Ivangorrion: /* Web of Trust - Simple introduction */</p>
<hr />
<div>[[Category:Package development (English)]]<br />
[[Category:Pacman development (English)]]<br />
This is a proposal for the package signing feature for Pacman. Here we'll gather ideas and commitments, so the implementation will be guided by this document.<br />
<br />
See also: [[Pacman package signing]]<br />
<br />
== Introduction ==<br />
<br />
Package signing is a long asked feature for Pacman. The goal of this implementation is to guarantee that a package was created by the person that claims to have made it.<br />
<br />
For that to work, we'll use GnuPG as the tool to sign, verify and manage the group of keys that are trusted.<br />
<br />
== Web of Trust - Simple introduction ==<br />
<br />
A web of trust is the concept used by OpenPGP (and GnuPG) for the management of trust policies in its public key system. As there's no concept of a central authoritative entity, there is the need of some kind of verification of the public keys that we accept in our keyring. Keys can be signed by other users, indicating that they trust in the veracity of the key. But the verification can become cumbersome, as the number of keys exchanged increases. To solve this, the concept of Web of Trust was introduced. If I trust enough in a friend, I can sign his key in my keyring and tell to gpg that I also trust in the keys that he signs. So, if I verify a file that was signed by a person that my friend trusts, gpg will accept the signature as valid. When I import the third person's public key, gpg will mark it as a valid key.<br />
<br />
In GnuPG, there are four levels of trust in a public key:<br />
<br />
; unknown: I did not say anything about this key yet<br />
; none: I do not trust this public key to sign other keys (this just affects the signature keys, not the signatures of files)<br />
; marginal: I have a little trust in this public key to sign other keys<br />
; fully: I trust completely in this public key, as if it was my own<br />
; ultimately: the same level of trust as your own key<br />
<br />
So, GnuPG can be configured to accept a key as valid if it has 3 marginally trusted key signatures or 1 fully trusted key signature (this is the default). Or it can be any other combination, if properly configured.<br />
<br />
The following is a suggestion for the use of GnuPG to sign and manage the pacman's keyring, together with the creation of a web of trust for the Arch Developers. It is very similar to what Debian and Fedora do, although there are some differences, because of our way of doing things.<br />
<br />
== Pacman's keyring ==<br />
<br />
Pacman will have a separated keyring, so the root's keyring will not be affected by keys that are intended for use with package signing. This is already implemented in Allan's pacman git branch for gpg support. The directory will be /etc/pacman.d/gnupg/. There will be the public key database, the trust database and a fake private key database, because GnuPG doesn't work very well without one (according to Debian's apt-key script).<br />
<br />
The keyring will be populated based on the keys from the pacman-keyring package. In this package, there will be a file for the valid keys and one for the removed keys, so that the post-install script can revoke keys that may not be trusted anymore (be it for security reasons or because some developer has left the project). There'll be signature files for the two sets of keys, so the updatedb script can check to see if they are valid before updating.<br />
<br />
== Arch Key Signing keys ==<br />
<br />
There will be 3 keys for the sole purpose of signing other developers' keys (hereafter named KSK, Key Signing Keys). They will be created by 3 developers (hereafter named Key Signers) that will be responsible for the role of signing the other developer's keys (and theirs own too). This procedure is very important and must be done with the certainty that the keys being signed are from the person they plead to be. The confirmation of the fingerprints must be done via a secure channel (skype, phone call, secure email or personally). For example, Debian only trust in keys confirmed personally. We can be a little lenient because the group of developers is reduced.<br />
<br />
The Key Signers must keep his KSK secured and must choose a strong passphrase, so that even in the event of the secret keys being stolen, the risk of a real misuse will be little. In such case, there will be some time for the generation of a new set of KSK and the re-signing of the others developers' keys. The Key Signers must also generate a revocation key for each of the KSK and must keep the revocation keys secured (preferably only in printed form or in a thumbdrive stored in some kind of safe box). This is needed because anyone that owns the revocation key can revoke the corresponding key.<br />
<br />
To sign the developer's keys, the Key Signers must receive a copy of the public key (through email or from a public key server). After importing the key into his own keyring, the Key Signer must sign the public key with the KSK. After that, he needs to export the signed public key and update the pacman-keyring package (there'll be a script for that task). Only one Key Signer should update the pacman-keyring package at a time to avoid having some key being lost because of overwriting files. There must be some form of coordination between the Key Signers on who will do the task.<br />
<br />
With the KSK and the signed developers' keys, the pacman-keyring package will be created and signed with one of the KSK.<br />
<br />
=== Use case: Arch Key Signing Keys creation ===<br />
<br />
# 3 developers will be selected to be the Key Signers<br />
# Each Key Signer creates a public/private key pair in his local keyring with gpg --gen-key<br />
## We need to decide if there'll be an expiration date<br />
#Each Key Signer creates a revocation key, which will be used for revocation of the KSK, in case of compromising of the private key. gpg --gen-revoke <key id><br />
## GnuPG can generate a revocation key for other person to trigger there the revocation. So, for each KSK, there should be designated revocation keys for the other two Key Signers. They could revoke their KSK and the others too, in case of inavailability of the owner of a KSK.<br />
## The revocation key MUST be kept secure, even more than the private key. This is because any person can revoke a key. The advise from GnuPG is that the revocation key be kept in a thumb drive in a safe or printed, so that there would be no way to access the digital file of the rev. key.<br />
# Each Key Signer sends his public KSK to a predefined key server. gpg --send-keys <key id> --keyserver <url for key server><br />
# Each Key Signer fetches the other KSKs from the key server and signs them with his own KSK (not his personal key)<br />
# Each Key Signer sends the other KSKs to the server again, to update the signatures.<br />
# Each fetches again the KSKs from the key server, so they get the KSKs with all signatures from the others signers.<br />
<br />
=== Use case: Signing of developer's keys ===<br />
<br />
# If a developer doesn't have a key yet, he generates one with: gpg --gen-key<br />
# If he generated the key in the previous step, he needs to generate a revocation key too. gpg --gen-revoke <key id><br />
## The same remarks for the revocation key above apply here.<br />
# The developer exports his public key to a file or sends it to a public key server. gpg --export <key id> > key.gpg or gpg --send-key <key id> --keyserver <url for key server><br />
# The developer contacts one of the Key Signers and sends him his public key file or instructs him to fetch it from the key server. Is important to negotiate a secure channel for the exchange of fingerprint. It should not be through email. Maybe IM, Skype or through ssh session with some Arch server as temporary storage.<br />
# The Key Signer signs the developer's public key with his owned KSK.<br />
# There'll be a script to help the management of the files used to populate pacman's key ring, so the new key will be added to the set of valid keys.<br />
# The pacman-keyring package will be rebuilt and signed with a KSK (not with a common developer's key). The procedure is described in the use case for package signing.<br />
<br />
== Package signing by developers ==<br />
<br />
When a developer builds a new package, makepkg will have the options to sign the package too, with the developer's own key (not the KSK, if the developer owns one). The signature will be detached, so we can keep this process optional for people that do not care for it.<br />
<br />
=== Use case ===<br />
<br />
# A package is rebuilt and signed with makepkg --signwithkey <key id> [other options]<br />
# Developer uses tool to upload the package and signature to his staging area<br />
# Developer repeats this until there are no more packages to build<br />
# Developer uses tool to copy his packages from staging area to the final repository and sign the repo.db. The script will do the following:<br />
## check if the repo.db is locked. Just proceed if unlocked.<br />
## lock the repo.db<br />
## call repo-add to add all the new packages<br />
## copy the repo.db to the local machine of the developer<br />
## sign the local repo.db with the developer's personal key. The signature will be detached<br />
## scp the signature back (and the repo.db?) to the server<br />
## unlock the repo.db<br />
<br />
== Installation of KSK by the users ==<br />
<br />
This is a very sensitive part and must be done with caution, at the risk of driving all the work moot. The KSK should be manually verified by the user before pacman can accept the pacman-keyring package. I believe that the following would be the workflow:<br />
<br />
* the KSK and the corresponding fingerprints would be available in several channels of Arch: Home page, git repository, forums, public key servers, etc.<br />
<br />
* the user downloads the KSK and import them (with a new tool, called pacman-key, named after apt-key)<br />
<br />
* pacman-key shows the fingerprint of each KSK and asks for the approval of the user<br />
<br />
* if the user confirms, pacman imports the keys to its keyring, setting them as fully trusted<br />
<br />
After this, the pacman-keyring can be installed and the public keys of the developers can be added by the post-install script. The trustdb will be updated automatically.<br />
<br />
=== Use case ===<br />
<br />
# The user must download the pacman-key tool (or it could be provided in a version of pacman without signing capabilities).<br />
# User fetches the KSKs from a key server. The id's can be discovered on a new item or forum or mail list post. pacman-key receive <keyserver> <KSK1 id> <KSK2 id> <KSK3 id><br />
# If the user downloaded the KSKs, they must be imported to pacman's keyring. Otherwise, they are already there. pacman-key add <file with KSKs><br />
# User must trust explicitly each KSK with pacman-key trust <KSK id><br />
## The KSK fingerprint will be shwon to the user. He must guarantee that he consults more than one secure source for comparison, such as Arch news item, Forum post, Mail list archive post, maybe we should have a file in git too.<br />
## The user must type 'trust' in the prompt. GnuPG will as the level of trust that the user assigns tho the key. He should answer 5 (ultimately) for the KSKs. Any value other than 5 will not make the KSK effective to assign trust to other keys signed by it. This must be further investigated. "Ultimately" should be used only for personal keys and "Fully" or "Marginal" should be effective. Maybe it is a configuration problem.<br />
## The user types 'save' to end the edit session of GnuPG<br />
# When a version of pacman able to verify signatures is available, pacman will update itself and install pacman-keyring first, as a dependency. The pacman-key tool will be used by --post-install script from pacman-keyring and will update the real pacman keyring with the keys in this package. The web of trust will be updated accordingly.<br />
<br />
== Package verification ==<br />
<br />
When pacman downloads a package, the signature will be downloaded together, if applicable. Pacman will inform the user if the package's signature is not valid and stop. There'll no possibility to install a signed package with an invalid signature.<br />
<br />
=== Use case ===<br />
<br />
# Pacman downloads the repo.db and its corresponding signature. The following should happen:<br />
## pacman verifies if the signature date is older than n days (we must decide this). If older, stop the procedure and ask the user to change mirrors or report the bug (the lack of new versions of the repo.db will be a bug)<br />
## pacman verifies the signature to see if it is valid.<br />
# pacman downloads the packages (the signatures are already downloaded in the repository database)<br />
# Before the installation (or update), each package is verified to see if the signature is correct and is signed by a trusted key. If the package has a signature and it is not valid, it should not be installed.<br />
<br />
== Affected tools ==<br />
<br />
=== Makepkg ===<br />
<br />
There should be options to choose the key to sign a package. The key will be always from the keyring of the user building the package.<br />
<br />
=== devtools ===<br />
<br />
This is a subject that is being discussed and this text will be updated soon.<br />
<br />
=== pacman ===<br />
<br />
Allan's branch is already verifying signatures, but there'are some easy changes needed to point to the right keyring.<br />
<br />
=== pacman-key ===<br />
<br />
Pacman-key is a new tool, responsible for the management of Pacman's keyring. It is a shell script and is needed because gpgme is not able to handle some operations on keyrings, so we can't change pacman to handle them too. The operations available will be, amongst others:<br />
<br />
* approval of KSK<br />
* importing/exporting of keys<br />
* fetching keys from a key server<br />
* changing level of trust for keys<br />
* removal of keys<br />
* update of trustdb<br />
<br />
== Final comments ==<br />
<br />
We believe that this suggestions are feasible and will bring a new level of quality to Arch Linux. The gpg branch of pacman git repository of Allan is in a good position in relation of what I suggested above. <br />
<br />
The discussions will take place on pacman-dev mailing list and this document will be updated as the decisions are made.</div>Ivangorrionhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Package_Signing_Proposal_for_Pacman&diff=180338DeveloperWiki:Package Signing Proposal for Pacman2012-01-26T11:54:51Z<p>Ivangorrion: /* Web of Trust - Simple introduction */</p>
<hr />
<div>[[Category:Package development (English)]]<br />
[[Category:Pacman development (English)]]<br />
This is a proposal for the package signing feature for Pacman. Here we'll gather ideas and commitments, so the implementation will be guided by this document.<br />
<br />
See also: [[Pacman package signing]]<br />
<br />
== Introduction ==<br />
<br />
Package signing is a long asked feature for Pacman. The goal of this implementation is to guarantee that a package was created by the person that claims to have made it.<br />
<br />
For that to work, we'll use GnuPG as the tool to sign, verify and manage the group of keys that are trusted.<br />
<br />
== Web of Trust - Simple introduction ==<br />
<br />
A web of trust is the concept used by OpenPGP (and GnuPG) for the management of trust policies in its public key system. As there's no concept of a central authoritative entity, there is the need of some kind of verification of the public keys that we accept in our keyring. Keys can be signed by other users, indicating that they trust in the veracity of the key. But the verification can become cumbersome, as the number of keys exchanged increases. To solve this, the concept of Web of Trust was introduced. If I trust enough in a friend, I can sign his key in my keyring and tell to gpg that I also trust in the keys that he signs. So, if I verify a file that was signed by a person that my friend trusts, gpg will accept the signature as valid. When I import the third person's public key, gpg will mark it as a valid key.<br />
<br />
In GnuPG, there are four levels of trust in a public key:<br />
<br />
; unknown: I didn't say anything about this key yet<br />
; none: I do not trust this public key to sign other keys (this just affects the signature keys, not the signatures of files)<br />
; marginal: I have a little trust in this public key to sign other keys<br />
; fully: I trust completely in this public key, as if it was my own<br />
; ultimately: the same level of trust as your own key<br />
<br />
So, GnuPG can be configured to accept a key as valid if it has 3 marginally trusted key signatures or 1 fully trusted key signature (this is the default). Or it can be any other combination, if properly configured.<br />
<br />
The following is a suggestion for the use of GnuPG to sign and manage the pacman's keyring, together with the creation of a web of trust for the Arch Developers. It is very similar to what Debian and Fedora do, although there are some differences, because of our way of doing things.<br />
<br />
== Pacman's keyring ==<br />
<br />
Pacman will have a separated keyring, so the root's keyring will not be affected by keys that are intended for use with package signing. This is already implemented in Allan's pacman git branch for gpg support. The directory will be /etc/pacman.d/gnupg/. There will be the public key database, the trust database and a fake private key database, because GnuPG doesn't work very well without one (according to Debian's apt-key script).<br />
<br />
The keyring will be populated based on the keys from the pacman-keyring package. In this package, there will be a file for the valid keys and one for the removed keys, so that the post-install script can revoke keys that may not be trusted anymore (be it for security reasons or because some developer has left the project). There'll be signature files for the two sets of keys, so the updatedb script can check to see if they are valid before updating.<br />
<br />
== Arch Key Signing keys ==<br />
<br />
There will be 3 keys for the sole purpose of signing other developers' keys (hereafter named KSK, Key Signing Keys). They will be created by 3 developers (hereafter named Key Signers) that will be responsible for the role of signing the other developer's keys (and theirs own too). This procedure is very important and must be done with the certainty that the keys being signed are from the person they plead to be. The confirmation of the fingerprints must be done via a secure channel (skype, phone call, secure email or personally). For example, Debian only trust in keys confirmed personally. We can be a little lenient because the group of developers is reduced.<br />
<br />
The Key Signers must keep his KSK secured and must choose a strong passphrase, so that even in the event of the secret keys being stolen, the risk of a real misuse will be little. In such case, there will be some time for the generation of a new set of KSK and the re-signing of the others developers' keys. The Key Signers must also generate a revocation key for each of the KSK and must keep the revocation keys secured (preferably only in printed form or in a thumbdrive stored in some kind of safe box). This is needed because anyone that owns the revocation key can revoke the corresponding key.<br />
<br />
To sign the developer's keys, the Key Signers must receive a copy of the public key (through email or from a public key server). After importing the key into his own keyring, the Key Signer must sign the public key with the KSK. After that, he needs to export the signed public key and update the pacman-keyring package (there'll be a script for that task). Only one Key Signer should update the pacman-keyring package at a time to avoid having some key being lost because of overwriting files. There must be some form of coordination between the Key Signers on who will do the task.<br />
<br />
With the KSK and the signed developers' keys, the pacman-keyring package will be created and signed with one of the KSK.<br />
<br />
=== Use case: Arch Key Signing Keys creation ===<br />
<br />
# 3 developers will be selected to be the Key Signers<br />
# Each Key Signer creates a public/private key pair in his local keyring with gpg --gen-key<br />
## We need to decide if there'll be an expiration date<br />
#Each Key Signer creates a revocation key, which will be used for revocation of the KSK, in case of compromising of the private key. gpg --gen-revoke <key id><br />
## GnuPG can generate a revocation key for other person to trigger there the revocation. So, for each KSK, there should be designated revocation keys for the other two Key Signers. They could revoke their KSK and the others too, in case of inavailability of the owner of a KSK.<br />
## The revocation key MUST be kept secure, even more than the private key. This is because any person can revoke a key. The advise from GnuPG is that the revocation key be kept in a thumb drive in a safe or printed, so that there would be no way to access the digital file of the rev. key.<br />
# Each Key Signer sends his public KSK to a predefined key server. gpg --send-keys <key id> --keyserver <url for key server><br />
# Each Key Signer fetches the other KSKs from the key server and signs them with his own KSK (not his personal key)<br />
# Each Key Signer sends the other KSKs to the server again, to update the signatures.<br />
# Each fetches again the KSKs from the key server, so they get the KSKs with all signatures from the others signers.<br />
<br />
=== Use case: Signing of developer's keys ===<br />
<br />
# If a developer doesn't have a key yet, he generates one with: gpg --gen-key<br />
# If he generated the key in the previous step, he needs to generate a revocation key too. gpg --gen-revoke <key id><br />
## The same remarks for the revocation key above apply here.<br />
# The developer exports his public key to a file or sends it to a public key server. gpg --export <key id> > key.gpg or gpg --send-key <key id> --keyserver <url for key server><br />
# The developer contacts one of the Key Signers and sends him his public key file or instructs him to fetch it from the key server. Is important to negotiate a secure channel for the exchange of fingerprint. It should not be through email. Maybe IM, Skype or through ssh session with some Arch server as temporary storage.<br />
# The Key Signer signs the developer's public key with his owned KSK.<br />
# There'll be a script to help the management of the files used to populate pacman's key ring, so the new key will be added to the set of valid keys.<br />
# The pacman-keyring package will be rebuilt and signed with a KSK (not with a common developer's key). The procedure is described in the use case for package signing.<br />
<br />
== Package signing by developers ==<br />
<br />
When a developer builds a new package, makepkg will have the options to sign the package too, with the developer's own key (not the KSK, if the developer owns one). The signature will be detached, so we can keep this process optional for people that do not care for it.<br />
<br />
=== Use case ===<br />
<br />
# A package is rebuilt and signed with makepkg --signwithkey <key id> [other options]<br />
# Developer uses tool to upload the package and signature to his staging area<br />
# Developer repeats this until there are no more packages to build<br />
# Developer uses tool to copy his packages from staging area to the final repository and sign the repo.db. The script will do the following:<br />
## check if the repo.db is locked. Just proceed if unlocked.<br />
## lock the repo.db<br />
## call repo-add to add all the new packages<br />
## copy the repo.db to the local machine of the developer<br />
## sign the local repo.db with the developer's personal key. The signature will be detached<br />
## scp the signature back (and the repo.db?) to the server<br />
## unlock the repo.db<br />
<br />
== Installation of KSK by the users ==<br />
<br />
This is a very sensitive part and must be done with caution, at the risk of driving all the work moot. The KSK should be manually verified by the user before pacman can accept the pacman-keyring package. I believe that the following would be the workflow:<br />
<br />
* the KSK and the corresponding fingerprints would be available in several channels of Arch: Home page, git repository, forums, public key servers, etc.<br />
<br />
* the user downloads the KSK and import them (with a new tool, called pacman-key, named after apt-key)<br />
<br />
* pacman-key shows the fingerprint of each KSK and asks for the approval of the user<br />
<br />
* if the user confirms, pacman imports the keys to its keyring, setting them as fully trusted<br />
<br />
After this, the pacman-keyring can be installed and the public keys of the developers can be added by the post-install script. The trustdb will be updated automatically.<br />
<br />
=== Use case ===<br />
<br />
# The user must download the pacman-key tool (or it could be provided in a version of pacman without signing capabilities).<br />
# User fetches the KSKs from a key server. The id's can be discovered on a new item or forum or mail list post. pacman-key receive <keyserver> <KSK1 id> <KSK2 id> <KSK3 id><br />
# If the user downloaded the KSKs, they must be imported to pacman's keyring. Otherwise, they are already there. pacman-key add <file with KSKs><br />
# User must trust explicitly each KSK with pacman-key trust <KSK id><br />
## The KSK fingerprint will be shwon to the user. He must guarantee that he consults more than one secure source for comparison, such as Arch news item, Forum post, Mail list archive post, maybe we should have a file in git too.<br />
## The user must type 'trust' in the prompt. GnuPG will as the level of trust that the user assigns tho the key. He should answer 5 (ultimately) for the KSKs. Any value other than 5 will not make the KSK effective to assign trust to other keys signed by it. This must be further investigated. "Ultimately" should be used only for personal keys and "Fully" or "Marginal" should be effective. Maybe it is a configuration problem.<br />
## The user types 'save' to end the edit session of GnuPG<br />
# When a version of pacman able to verify signatures is available, pacman will update itself and install pacman-keyring first, as a dependency. The pacman-key tool will be used by --post-install script from pacman-keyring and will update the real pacman keyring with the keys in this package. The web of trust will be updated accordingly.<br />
<br />
== Package verification ==<br />
<br />
When pacman downloads a package, the signature will be downloaded together, if applicable. Pacman will inform the user if the package's signature is not valid and stop. There'll no possibility to install a signed package with an invalid signature.<br />
<br />
=== Use case ===<br />
<br />
# Pacman downloads the repo.db and its corresponding signature. The following should happen:<br />
## pacman verifies if the signature date is older than n days (we must decide this). If older, stop the procedure and ask the user to change mirrors or report the bug (the lack of new versions of the repo.db will be a bug)<br />
## pacman verifies the signature to see if it is valid.<br />
# pacman downloads the packages (the signatures are already downloaded in the repository database)<br />
# Before the installation (or update), each package is verified to see if the signature is correct and is signed by a trusted key. If the package has a signature and it is not valid, it should not be installed.<br />
<br />
== Affected tools ==<br />
<br />
=== Makepkg ===<br />
<br />
There should be options to choose the key to sign a package. The key will be always from the keyring of the user building the package.<br />
<br />
=== devtools ===<br />
<br />
This is a subject that is being discussed and this text will be updated soon.<br />
<br />
=== pacman ===<br />
<br />
Allan's branch is already verifying signatures, but there'are some easy changes needed to point to the right keyring.<br />
<br />
=== pacman-key ===<br />
<br />
Pacman-key is a new tool, responsible for the management of Pacman's keyring. It is a shell script and is needed because gpgme is not able to handle some operations on keyrings, so we can't change pacman to handle them too. The operations available will be, amongst others:<br />
<br />
* approval of KSK<br />
* importing/exporting of keys<br />
* fetching keys from a key server<br />
* changing level of trust for keys<br />
* removal of keys<br />
* update of trustdb<br />
<br />
== Final comments ==<br />
<br />
We believe that this suggestions are feasible and will bring a new level of quality to Arch Linux. The gpg branch of pacman git repository of Allan is in a good position in relation of what I suggested above. <br />
<br />
The discussions will take place on pacman-dev mailing list and this document will be updated as the decisions are made.</div>Ivangorrionhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Package_Signing_Proposal_for_Pacman&diff=180335DeveloperWiki:Package Signing Proposal for Pacman2012-01-26T11:52:16Z<p>Ivangorrion: /* Web of Trust - Simple introduction */</p>
<hr />
<div>[[Category:Package development (English)]]<br />
[[Category:Pacman development (English)]]<br />
This is a proposal for the package signing feature for Pacman. Here we'll gather ideas and commitments, so the implementation will be guided by this document.<br />
<br />
See also: [[Pacman package signing]]<br />
<br />
== Introduction ==<br />
<br />
Package signing is a long asked feature for Pacman. The goal of this implementation is to guarantee that a package was created by the person that claims to have made it.<br />
<br />
For that to work, we'll use GnuPG as the tool to sign, verify and manage the group of keys that are trusted.<br />
<br />
== Web of Trust - Simple introduction ==<br />
<br />
A web of trust is the concept used by OpenPGP (and GnuPG) for the management of trust policies in its public key system. As there's no concept of a central authoritative entity, there is the need of some kind of verification of the public keys that we accept in our keyring. Keys can be signed by other users, indicating that they trust in the veracity of the key. But the verification can become cumbersome, as the number of keys exchanged increases. To solve this, the concept of Web of Trust was introduced. If I trust enough in a friend, I can sign his key in my keyring and tell to gpg that I also trust in the keys that he signs. So, if I verify a file that was signed by a person that my friend trusts, gpg will accept the signature as valid. When I import the third person's public key, gpg will mark it as a valid key.<br />
<br />
In GnuPG, there are four levels of trust in a public key:<br />
<br />
; unknown: I didn't said anything about this key yet<br />
; none: I do not trust this public key to sign other keys (this just affects the signature keys, not the signatures of files)<br />
; marginal: I have a little trust in this public key to sign other keys<br />
; fully: I trust completely in this public key, as if it was my own<br />
; ultimately: the same level of trust as your own key<br />
<br />
So, GnuPG can be configured to accept a key as valid if it has 3 marginally trusted key signatures or 1 fully trusted key signature (this is the default). Or it can be any other combination, if properly configured.<br />
<br />
The following is a suggestion for the use of GnuPG to sign and manage the pacman's keyring, together with the creation of a web of trust for the Arch Developers. It is very similar to what Debian and Fedora do, although there are some differences, because of our way of doing things.<br />
<br />
== Pacman's keyring ==<br />
<br />
Pacman will have a separated keyring, so the root's keyring will not be affected by keys that are intended for use with package signing. This is already implemented in Allan's pacman git branch for gpg support. The directory will be /etc/pacman.d/gnupg/. There will be the public key database, the trust database and a fake private key database, because GnuPG doesn't work very well without one (according to Debian's apt-key script).<br />
<br />
The keyring will be populated based on the keys from the pacman-keyring package. In this package, there will be a file for the valid keys and one for the removed keys, so that the post-install script can revoke keys that may not be trusted anymore (be it for security reasons or because some developer has left the project). There'll be signature files for the two sets of keys, so the updatedb script can check to see if they are valid before updating.<br />
<br />
== Arch Key Signing keys ==<br />
<br />
There will be 3 keys for the sole purpose of signing other developers' keys (hereafter named KSK, Key Signing Keys). They will be created by 3 developers (hereafter named Key Signers) that will be responsible for the role of signing the other developer's keys (and theirs own too). This procedure is very important and must be done with the certainty that the keys being signed are from the person they plead to be. The confirmation of the fingerprints must be done via a secure channel (skype, phone call, secure email or personally). For example, Debian only trust in keys confirmed personally. We can be a little lenient because the group of developers is reduced.<br />
<br />
The Key Signers must keep his KSK secured and must choose a strong passphrase, so that even in the event of the secret keys being stolen, the risk of a real misuse will be little. In such case, there will be some time for the generation of a new set of KSK and the re-signing of the others developers' keys. The Key Signers must also generate a revocation key for each of the KSK and must keep the revocation keys secured (preferably only in printed form or in a thumbdrive stored in some kind of safe box). This is needed because anyone that owns the revocation key can revoke the corresponding key.<br />
<br />
To sign the developer's keys, the Key Signers must receive a copy of the public key (through email or from a public key server). After importing the key into his own keyring, the Key Signer must sign the public key with the KSK. After that, he needs to export the signed public key and update the pacman-keyring package (there'll be a script for that task). Only one Key Signer should update the pacman-keyring package at a time to avoid having some key being lost because of overwriting files. There must be some form of coordination between the Key Signers on who will do the task.<br />
<br />
With the KSK and the signed developers' keys, the pacman-keyring package will be created and signed with one of the KSK.<br />
<br />
=== Use case: Arch Key Signing Keys creation ===<br />
<br />
# 3 developers will be selected to be the Key Signers<br />
# Each Key Signer creates a public/private key pair in his local keyring with gpg --gen-key<br />
## We need to decide if there'll be an expiration date<br />
#Each Key Signer creates a revocation key, which will be used for revocation of the KSK, in case of compromising of the private key. gpg --gen-revoke <key id><br />
## GnuPG can generate a revocation key for other person to trigger there the revocation. So, for each KSK, there should be designated revocation keys for the other two Key Signers. They could revoke their KSK and the others too, in case of inavailability of the owner of a KSK.<br />
## The revocation key MUST be kept secure, even more than the private key. This is because any person can revoke a key. The advise from GnuPG is that the revocation key be kept in a thumb drive in a safe or printed, so that there would be no way to access the digital file of the rev. key.<br />
# Each Key Signer sends his public KSK to a predefined key server. gpg --send-keys <key id> --keyserver <url for key server><br />
# Each Key Signer fetches the other KSKs from the key server and signs them with his own KSK (not his personal key)<br />
# Each Key Signer sends the other KSKs to the server again, to update the signatures.<br />
# Each fetches again the KSKs from the key server, so they get the KSKs with all signatures from the others signers.<br />
<br />
=== Use case: Signing of developer's keys ===<br />
<br />
# If a developer doesn't have a key yet, he generates one with: gpg --gen-key<br />
# If he generated the key in the previous step, he needs to generate a revocation key too. gpg --gen-revoke <key id><br />
## The same remarks for the revocation key above apply here.<br />
# The developer exports his public key to a file or sends it to a public key server. gpg --export <key id> > key.gpg or gpg --send-key <key id> --keyserver <url for key server><br />
# The developer contacts one of the Key Signers and sends him his public key file or instructs him to fetch it from the key server. Is important to negotiate a secure channel for the exchange of fingerprint. It should not be through email. Maybe IM, Skype or through ssh session with some Arch server as temporary storage.<br />
# The Key Signer signs the developer's public key with his owned KSK.<br />
# There'll be a script to help the management of the files used to populate pacman's key ring, so the new key will be added to the set of valid keys.<br />
# The pacman-keyring package will be rebuilt and signed with a KSK (not with a common developer's key). The procedure is described in the use case for package signing.<br />
<br />
== Package signing by developers ==<br />
<br />
When a developer builds a new package, makepkg will have the options to sign the package too, with the developer's own key (not the KSK, if the developer owns one). The signature will be detached, so we can keep this process optional for people that do not care for it.<br />
<br />
=== Use case ===<br />
<br />
# A package is rebuilt and signed with makepkg --signwithkey <key id> [other options]<br />
# Developer uses tool to upload the package and signature to his staging area<br />
# Developer repeats this until there are no more packages to build<br />
# Developer uses tool to copy his packages from staging area to the final repository and sign the repo.db. The script will do the following:<br />
## check if the repo.db is locked. Just proceed if unlocked.<br />
## lock the repo.db<br />
## call repo-add to add all the new packages<br />
## copy the repo.db to the local machine of the developer<br />
## sign the local repo.db with the developer's personal key. The signature will be detached<br />
## scp the signature back (and the repo.db?) to the server<br />
## unlock the repo.db<br />
<br />
== Installation of KSK by the users ==<br />
<br />
This is a very sensitive part and must be done with caution, at the risk of driving all the work moot. The KSK should be manually verified by the user before pacman can accept the pacman-keyring package. I believe that the following would be the workflow:<br />
<br />
* the KSK and the corresponding fingerprints would be available in several channels of Arch: Home page, git repository, forums, public key servers, etc.<br />
<br />
* the user downloads the KSK and import them (with a new tool, called pacman-key, named after apt-key)<br />
<br />
* pacman-key shows the fingerprint of each KSK and asks for the approval of the user<br />
<br />
* if the user confirms, pacman imports the keys to its keyring, setting them as fully trusted<br />
<br />
After this, the pacman-keyring can be installed and the public keys of the developers can be added by the post-install script. The trustdb will be updated automatically.<br />
<br />
=== Use case ===<br />
<br />
# The user must download the pacman-key tool (or it could be provided in a version of pacman without signing capabilities).<br />
# User fetches the KSKs from a key server. The id's can be discovered on a new item or forum or mail list post. pacman-key receive <keyserver> <KSK1 id> <KSK2 id> <KSK3 id><br />
# If the user downloaded the KSKs, they must be imported to pacman's keyring. Otherwise, they are already there. pacman-key add <file with KSKs><br />
# User must trust explicitly each KSK with pacman-key trust <KSK id><br />
## The KSK fingerprint will be shwon to the user. He must guarantee that he consults more than one secure source for comparison, such as Arch news item, Forum post, Mail list archive post, maybe we should have a file in git too.<br />
## The user must type 'trust' in the prompt. GnuPG will as the level of trust that the user assigns tho the key. He should answer 5 (ultimately) for the KSKs. Any value other than 5 will not make the KSK effective to assign trust to other keys signed by it. This must be further investigated. "Ultimately" should be used only for personal keys and "Fully" or "Marginal" should be effective. Maybe it is a configuration problem.<br />
## The user types 'save' to end the edit session of GnuPG<br />
# When a version of pacman able to verify signatures is available, pacman will update itself and install pacman-keyring first, as a dependency. The pacman-key tool will be used by --post-install script from pacman-keyring and will update the real pacman keyring with the keys in this package. The web of trust will be updated accordingly.<br />
<br />
== Package verification ==<br />
<br />
When pacman downloads a package, the signature will be downloaded together, if applicable. Pacman will inform the user if the package's signature is not valid and stop. There'll no possibility to install a signed package with an invalid signature.<br />
<br />
=== Use case ===<br />
<br />
# Pacman downloads the repo.db and its corresponding signature. The following should happen:<br />
## pacman verifies if the signature date is older than n days (we must decide this). If older, stop the procedure and ask the user to change mirrors or report the bug (the lack of new versions of the repo.db will be a bug)<br />
## pacman verifies the signature to see if it is valid.<br />
# pacman downloads the packages (the signatures are already downloaded in the repository database)<br />
# Before the installation (or update), each package is verified to see if the signature is correct and is signed by a trusted key. If the package has a signature and it is not valid, it should not be installed.<br />
<br />
== Affected tools ==<br />
<br />
=== Makepkg ===<br />
<br />
There should be options to choose the key to sign a package. The key will be always from the keyring of the user building the package.<br />
<br />
=== devtools ===<br />
<br />
This is a subject that is being discussed and this text will be updated soon.<br />
<br />
=== pacman ===<br />
<br />
Allan's branch is already verifying signatures, but there'are some easy changes needed to point to the right keyring.<br />
<br />
=== pacman-key ===<br />
<br />
Pacman-key is a new tool, responsible for the management of Pacman's keyring. It is a shell script and is needed because gpgme is not able to handle some operations on keyrings, so we can't change pacman to handle them too. The operations available will be, amongst others:<br />
<br />
* approval of KSK<br />
* importing/exporting of keys<br />
* fetching keys from a key server<br />
* changing level of trust for keys<br />
* removal of keys<br />
* update of trustdb<br />
<br />
== Final comments ==<br />
<br />
We believe that this suggestions are feasible and will bring a new level of quality to Arch Linux. The gpg branch of pacman git repository of Allan is in a good position in relation of what I suggested above. <br />
<br />
The discussions will take place on pacman-dev mailing list and this document will be updated as the decisions are made.</div>Ivangorrion