https://wiki.archlinux.org/api.php?action=feedcontributions&user=Txus.palacios&feedformat=atomArchWiki - User contributions [en]2024-03-29T10:59:26ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=QEMU&diff=274910QEMU2013-09-10T10:36:47Z<p>Txus.palacios: /* What is VDE? */ -- fixed typo (Your -> You)</p>
<hr />
<div>[[Category:Emulators]]<br />
[[Category:Virtualization]]<br />
[[de:Qemu]]<br />
[[es:Qemu]]<br />
[[fr:Qemu]]<br />
[[zh-CN:QEMU]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers running QEMU virtual machines (VMs), creating new VMs, sharing data between host and guest, networking and some other advanced features.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|KVM}}<br />
{{Article summary wiki|Libvirt}}<br />
{{Article summary wiki|VirtualBox}}<br />
{{Article summary wiki|Xen}}<br />
{{Article summary wiki|VMware}}<br />
{{Article summary end}}<br />
From the [http://wiki.qemu.org/Main_Page QEMU about page]:<br />
:''QEMU is a generic and open source machine emulator and virtualizer.''<br />
<br />
When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your x86 PC). By using dynamic translation, it achieves very good performance.<br />
<br />
QEMU can use other hypervisors like [[Xen]] or [[KVM]] to use CPU extensions ([[Wikipedia:Hardware-assisted virtualization|HVM]]) for virtualization. When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU.<br />
<br />
== Installing QEMU ==<br />
<br />
Install {{Pkg|qemu}} from the [[Official Repositories|official repositories]].<br />
<br />
== Graphical front-ends for QEMU ==<br />
<br />
Unlike other virtualization programs such as [[VirtualBox]] and [[VMware]], QEMU does not provide a GUI to manage virtual machines (other than the window that appears when running a virtual machine), nor does it provide a way to create persistent virtual machines with saved settings. All parameters to run a virtual machine must be specified on the command line at every launch, unless you have created a custom script to start your virtual machine(s). However, there are several GUI front-ends for QEMU:<br />
<br />
* {{Pkg|virt-manager}} (part of [[libvirt]])<br />
* {{Pkg|qemu-launcher}}<br />
* {{Pkg|qtemu}}<br />
From AUR:<br />
* {{AUR|aqemu-git}}<br />
* {{AUR|qemulator}}<br />
<br />
== Running virtualized system ==<br />
<br />
{{ic|qemu-system-*}} binaries (for example {{ic|qemu-system-i386}} or {{ic|qemu-system-x86_64}}, depending on emulated architecture) are used to run the virtualized system. The usage is:<br />
<br />
$ qemu-system-i386 [options] [disk_image]<br />
<br />
Options are the same for all {{ic|qemu-system-*}} binaries, see {{ic|qemu(1)}} for documentation of all options.<br />
<br />
By default, QEMU will show the virtual machine's video output in a window. One thing to keep in mind: when you click inside the QEMU window, the mouse pointer is grabbed. To release it, press {{ic|Ctrl+Alt}}.<br />
<br />
{{Warning|QEMU should never be run as root. If you must launch it in a script as root, you should use the {{ic|-runas}} option to make QEMU drop root privileges.}}<br />
<br />
=== Enabling KVM ===<br />
<br />
KVM must be supported by your processor and kernel, and necessary [[kernel modules]] must be loaded. See [[KVM]] for more information.<br />
<br />
To start QEMU in KVM mode, append {{ic|-enable-kvm}} to the additional start options.<br />
<br />
{{Note|If you start your VM with a GUI tool and experience very bad performance, you should check for proper KVM support, as QEMU may be falling back to software emulation.}}<br />
<br />
== Creating new virtualized system ==<br />
<br />
=== Creating a hard disk image ===<br />
<br />
{{Tip|See [http://en.wikibooks.org/wiki/QEMU/Images Wikibooks] for more information on QEMU images.}}<br />
<br />
To run QEMU you will need a hard disk image, unless you are booting a live system from CD-ROM or the network (and not doing so to install an operating system to a hard disk image). A hard disk image is a file which stores the contents of the emulated hard disk. <br />
<br />
A hard disk image may simply contain the literal contents, byte for byte, of the hard disk. This is usually called ''raw'' format, and it provides the least I/O overhead, although the images may take up a large amount of space.<br />
<br />
Alternatively, the hard disk image can be in a format such as ''qcow2'' that can save enormous amounts of space by only allocating space to the image file when the guest operating system actually writes to those sectors on its virtual hard disk. The image appears as the full size to the guest operating system, even though it may take up only a very small amount of space on the host system.<br />
<br />
QEMU provides the {{ic|qemu-img}} command to create hard disk images. For example to create 4GB image in the qcow2 format:<br />
$ qemu-img create -f qcow2 <qcow2_disk_image> 4G<br />
<br />
You may use {{ic|-f raw}} to create a raw disk instead, although you can also do so simply by creating a file of the needed size using {{ic|dd}} or {{ic|fallocate}}.<br />
<br />
{{Tip|''raw'' disk usually provides much better performance than ''qcow2''.}}<br />
<br />
==== Overlay images ====<br />
<br />
A good idea is to use overlay images. This way you can a create hard disk image once and tell QEMU to store changes in an external file. This makes it easy to revert the virtual machine's disk to a previous state.<br />
<br />
To create an overlay image, type:<br />
$ qemu-img create -b <base_image> -f qcow2 <overlay_image><br />
<br />
After that you can run QEMU as usual (see [[#Running virtualized system]]):<br />
$ qemu-system-i386 <overlay_image><br />
<br />
and the original image will be left untouched. One hitch, the base image cannot be renamed or moved, the overlay remembers the base's full path.<br />
<br />
==== Resizing the image ====<br />
<br />
{{Warning|Resizing an image containing an NTFS boot filesystem could make the VM installed on it unbootable. One solution, which is really tricky and for expert users only, is shown [http://tjworld.net/wiki/Howto/ResizeQemuDiskImages here] along with a deep explanation of the problem.}}<br />
<br />
===== Up-to-date way =====<br />
<br />
The {{ic|qemu-img}} executable has {{ic|resize}} option, which allows resizing a qcow2 image directly, with no need to pass through raw conversion. For example to increase image space by 10GB:<br />
$ qemu-img resize <qcow2_disk_image> +10G<br />
<br />
===== Old way =====<br />
<br />
It is possible to increase the size of a qcow2 image later, at least with ext3. Convert it to a raw image, expand its size with {{ic|dd}}, convert it back to qcow2, replace the partition with a larger one, do a {{ic|fsck}} and resize the filesystem.<br />
<br />
{{bc|<nowiki><br />
$ qemu-img convert -O raw image.qcow2 image.img<br />
$ dd if=/dev/zero of=image.img bs=1G count=0 seek=[NUMBER_OF_GB]<br />
$ qemu-img convert -O qcow2 -o cluster_size=64K image.img imageplus.qcow2<br />
$ qemu-kvm -hda imageplus.qcow2 -m 512 -cdrom </Path/to/the/ISO/Image> -boot d -vga std<br />
# fdisk /dev/sda [delete the partition, create new one occupying whole disk]<br />
# e2fsck -f /dev/sda1<br />
# resize2fs /dev/sda1<br />
</nowiki>}}<br />
<br />
=== Preparing the installation media ===<br />
<br />
To install an operating system into your disk image, you need the installation media (e.g. CD-ROM, floppy, or ISO image) for the operating system.<br />
<br />
{{Tip|If you would like to run an Arch Linux virtual machine, you can install it using the [https://www.archlinux.org/download/ official installation media for Arch Linux]. It is also possible to set up an Arch Linux virtual machine without the installation media, provided that your host machine is running Arch Linux, although this is more difficult; it is detailed [[Creating Arch Linux disk image#Install Arch Linux in a disk image without the installation media|here]].}}<br />
<br />
The installation media should not be mounted because QEMU accesses the media directly. Also, if using physical media (e.g. CD-ROM or floppy), it is a good idea to first dump the media to a file because this both improves performance and does not require you to have direct access to the devices (that is, you can run QEMU as a regular user without having to change access permissions on the media's device file). For example, if the CD-ROM device node is named {{ic|/dev/cdrom}}, you can dump it to a file with the command:<br />
$ dd if=/dev/cdrom of=<cd_image.iso><br />
<br />
=== Installing the operating system===<br />
<br />
This is the first time you will need to start the emulator. To install the operating system on the disk image, you must attach both the disk image and the installation media to the virtual machine, and have it boot from the installation media.<br />
<br />
For example on i386 systems, to install from a bootable ISO file as CD-ROM:<br />
$ qemu-system-i386 -cdrom <iso_image> -boot order=d <qemu_image><br />
<br />
See {{ic|qemu(1)}} for information about loading other media types, such as floppy or disk images, or physical drives.<br />
<br />
After the operating system has finished installing, the QEMU image can be booted directly (see [[#Running virtualized system]]).<br />
<br />
{{Tip|<br />
* By default only 128MB of memory is assigned to the machine, the amount of memory can be adjusted with the -m switch, for example {{ic|-m 512}}.<br />
* Instead of specifying {{ic|1=-boot order=x}}, some users may feel more comfortable using a boot menu: {{ic|1=-boot menu=on}}, at least during configuration and experimentation.<br />
}}<br />
<br />
{{Note|If you need to replace floppies or CDs as part of the installation process, you can use the QEMU machine monitor (press {{ic|Ctrl-Alt-2}} in the virtual machine's window) to remove and attach storage devices to a virtual machine. Type {{ic|info block}} to see the block devices, and use the {{ic|change}} command to swap out a device. Press {{ic|Ctrl-Alt-1}} to go back to the virtual machine.}}<br />
<br />
== Moving data between host and guest OS ==<br />
<br />
=== Network ===<br />
<br />
Data can be shared between the host and guest OS using any network protocol that can transfer files, such as [[NFS]], [[Samba|SMB]], [[Wikipedia:Network Block Device|NBD]], HTTP, [[Very Secure FTP Daemon|FTP]], or [[Secure Shell|SSH]], provided that you have set up the network appropriately and enabled the appropriate services.<br />
<br />
The default user-mode networking allows the guest to access the host OS at the IP address 10.0.2.2. Any servers that you are running on your host OS, such as a SSH server or SMB server, will be accessible at this IP address. So on the guests, you can mount directories exported on the host via [[Samba|SMB]] or [[NFS]], or you can access the host's HTTP server, etc. <br />
It will not be possible for the host OS to access servers running on the guest OS, but this can be done with other network configurations (see [[#Tap networking with QEMU]]).<br />
<br />
=== QEMU's built-in SMB server ===<br />
<br />
QEMU's documentation says it has a "built-in" SMB server, but actually it just starts up [[Samba]] with an automatically generated configuration file and makes it accessible to the guest at a different IP address (10.0.2.4 by default). This only works for user networking, and this isn't necessarily very useful since the guest can also access the normal [[Samba]] service on the host if you have set up shares on it.<br />
<br />
To enable this feature, start QEMU with a command like:<br />
$ qemu-system-i386 <disk_image> -net nic -net user,smb=<shared_dir_path><br />
<br />
where {{ic|<shared_dir_path>}} is a directory that you want to share between the guest and host.<br />
<br />
Then, in the guest, you will be able to access the shared directory on the host 10.0.2.4 with the share name "qemu". For example, in Windows Explorer you would go to {{ic|\\10.0.2.4\qemu}}.<br />
<br />
=== Mounting a partition inside a raw disk image ===<br />
<br />
When the virtual machine is not running, it is possible to mount partitions that are inside a raw disk image file by setting them up as loopback devices. This does not work with disk images in special formats, such as qcow2, although those can be mounted using {{ic|qemu-nbd}}.<br />
<br />
{{Warning|You must make sure to unmount the partitions before running the virtual machine again. Otherwise data corruption could occur, unless you had mounted the partitions read-only.}}<br />
<br />
==== With manually specifying byte offset ====<br />
<br />
One way to mount a disk image partition is to mount the disk image at a certain offset using a command like the following:<br />
# mount -o loop,offset=32256 <disk_image> <mountpoint><br />
<br />
The {{ic|<nowiki>offset=32256</nowiki>}} option is actually passed to the {{ic|losetup}} program to set up a loopback device that starts at byte offset 32256 of the file and continues to the end. This loopback device is then mounted. You may also use the {{ic|sizelimit}} option to specify the exact size of the partition, but this is usually unnecessary.<br />
<br />
Depending on your disk image, the needed partition may not start at offset 32256. Run {{ic|fdisk -l <disk_image>}} to see the partitions in the image. fdisk gives the start and end offsets in 512-byte sectors, so multiply by 512 to get the correct offset to pass to {{ic|mount}}.<br />
<br />
==== With loop module autodetecting partitions ====<br />
<br />
The Linux loop driver actually supports partitions in loopback devices, but it is disabled by default. To enable it, do the following:<br />
<br />
* Get rid of all your loopback devices (unmount all mounted images, etc.).<br />
* Unload the loop [[Kernel modules|module]].<br />
# modprobe -r loop<br />
* Load the loop [[Kernel modules|module]] with the {{ic|max_part}} parameter set.<br />
# modprobe loop max_part=15<br />
<br />
{{Tip|You can put an entry in {{ic|/etc/modprobe.d}} to load the loop module with {{ic|<nowiki>max_part=15</nowiki>}} every time, or you can put {{ic|<nowiki>loop.max_part=15</nowiki>}} on the kernel command line, depending on whether you have the {{ic|loop.ko}} module built into your kernel or not.}}<br />
<br />
Set up your image as a loopback device:<br />
# losetup -f <disk_image><br />
<br />
Then, if the device created was {{ic|/dev/loop0}}, additional devices {{ic|/dev/loop0pX}} will have been automatically created, where X is the number of the partition. These partition loopback devices can be mounted directly. For example:<br />
# mount /dev/loop0p1 <mountpoint><br />
<br />
==== With kpartx ====<br />
<br />
'''kpartx''' from the {{AUR|multipath-tools-git}} package from the [[Arch User Repository|AUR]] can read a partition table on a device and create a new device for each partition. For example:<br />
# kpartx -a /dev/loop0<br />
<br />
=== Mounting a partition inside a qcow2 image ===<br />
<br />
You may mount a partition inside a qcow2 image using {{ic|qemu-nbd}}. See [http://en.wikibooks.org/wiki/QEMU/Images#Mounting_an_image_on_the_host Wikibooks].<br />
<br />
=== Using any real partition as the single primary partition of a hard disk image ===<br />
<br />
Sometimes, you may wish to use one of your system partitions from within QEMU. Using a raw partition for a virtual machine will improve performance, as the read and write operations do not go through the filesystem layer on the physical host. Such a partition also provides a way to share data between the host and guest.<br />
<br />
In Arch Linux, device files for raw partitions are, by default, owned by ''root'' and the ''disk'' group. If you would like to have a non-root user be able to read and write to a raw partition, you need to change the owner of the partition's device file to that user.<br />
<br />
{{Warning|<br />
* Although it is possible, it is not recommended to allow virtual machines to alter critical data on the host system, such as the root partition.<br />
* You must not mount a filesystem on a partition read-write on both the host and the guest at the same time. Otherwise, data corruption will result.<br />
}}<br />
<br />
After doing so, you can attach the partition to a QEMU virtual machine as a virtual disk.<br />
<br />
However, things are a little more complicated if you want to have the ''entire'' virtual machine contained in a partition. In that case, there would be no disk image file to actually boot the virtual machine since you cannot install a bootloader to a partition that is itself formatted as a filesystem and not as a partitioned device with a MBR. Such a virtual machine can be booted either by specifying the [[Kernels|kernel]] and [[initramfs|initrd]] manually, or by simulating a disk with a MBR by using linear [[RAID]].<br />
<br />
==== By specifying kernel and initrd manually ====<br />
<br />
QEMU supports loading [[Kernels|Linux kernels]] and [[initramfs|init ramdisks]] directly, thereby circumventing bootloaders such as [[GRUB]]. It then can be launched with the physical partition containing the root filesystem as the virtual disk, which will not appear to be partitioned. This is done by issuing a command similar to the following:<br />
$ qemu-system-i386 -kernel /boot/vmlinuz-linux -initrd /boot/initramfs-linux.img -append root=/dev/sda /dev/sda3<br />
<br />
In the above example, the physical partition being used for the guest's root filesystem is {{ic|/dev/sda3}} on the host, but it shows up as {{ic|/dev/sda}} on the guest.<br />
<br />
You may, of course, specify any kernel and initrd that you want, and not just the ones that come with Arch Linux.<br />
<br />
==== Simulate virtual disk with MBR using linear RAID ====<br />
<br />
A more complicated way to have a virtual machine use a physical partition, while keeping that partition formatted as a filesystem and not just having the guest partition the partition as if it were a disk, is to simulate a MBR for it so that it can boot using a bootloader such as GRUB.<br />
<br />
You can do this using software [[RAID]] in linear mode (you need the linear.ko kernel driver) and a loopback device: the trick is to dynamically prepend a master boot record (MBR) to the real partition you wish to embed in a QEMU raw disk image.<br />
<br />
Suppose you have a plain, unmounted {{ic|/dev/hdaN}} partition with some filesystem on it you wish to make part of a QEMU disk image. First, you create some small file to hold the MBR:<br />
$ dd if=/dev/zero of=/path/to/mbr count=32<br />
<br />
Here, a 16 KB (32 * 512 bytes) file is created. It is important not to make it too small (even if the MBR only needs a single 512 bytes block), since the smaller it will be, the smaller the chunk size of the software RAID device will have to be, which could have an impact on performance. Then, you setup a loopback device to the MBR file:<br />
# losetup -f /path/to/mbr<br />
<br />
Let's assume the resulting device is {{ic|/dev/loop0}}, because we would not already have been using other loopbacks. Next step is to create the "merged" MBR + {{ic|/dev/hdaN}} disk image using software RAID:<br />
# modprobe linear<br />
# mdadm --build --verbose /dev/md0 --chunk=16 --level=linear --raid-devices=2 /dev/loop0 /dev/hdaN<br />
<br />
The resulting {{ic|/dev/md0}} is what you will use as a QEMU raw disk image (do not forget to set the permissions so that the emulator can access it). The last (and somewhat tricky) step is to set the disk configuration (disk geometry and partitions table) so that the primary partition start point in the MBR matches the one of {{ic|/dev/hdaN}} inside {{ic|/dev/md0}} (an offset of exactly 16 * 512 = 16384 bytes in this example). Do this using {{ic|fdisk}} on the host machine, not in the emulator: the default raw disc detection routine from QEMU often results in non kilobyte-roundable offsets (such as 31.5 KB, as in the previous section) that cannot be managed by the software RAID code. Hence, from the the host:<br />
# fdisk /dev/md0<br />
<br />
Press {{ic|X}} to enter the expert menu. Set number of 's'ectors per track so that the size of one cylinder matches the size of your MBR file. For two heads and a sector size of 512, the number of sectors per track should be 16, so we get cylinders of size 2x16x512=16k.<br />
<br />
Now, press {{ic|R}} to return to the main menu. <br />
<br />
Press {{ic|P}} and check that the cylinder size is now 16k.<br />
<br />
Now, create a single primary partition corresponding to {{ic|/dev/hdaN}}. It should start at cylinder 2 and end at the end of the disk (note that the number of cylinders now differs from what it was when you entered fdisk.<br />
<br />
Finally, 'w'rite the result to the file: you are done. You now have a partition you can mount directly from your host, as well as part of a QEMU disk image: <br />
<br />
$ qemu-system-i386 -hdc /dev/md0 [...]<br />
<br />
You can of course safely set any bootloader on this disk image using QEMU, provided the original {{ic|/dev/hdaN}} partition contains the necessary tools.<br />
<br />
== Networking ==<br />
<br />
The performance of virtual networking should be better with tap devices and bridges than with user-mode networking or vde, since tap devices and bridges are implemented in-kernel.<br />
<br />
In addition, networking performance can be improved by assigning virtual machines a [http://wiki.libvirt.org/page/Virtio virtio] network device rather than the default emulation of an e1000 NIC. See [[#Installing virtio drivers]] for more information.<br />
<br />
=== Link-level address caveat ===<br />
<br />
By giving the {{ic|-net nic}} argument to QEMU, it will, by default, assign a virtual machine a network interface with the link-level address {{ic|52:54:00:12:34:56}}. However, when using bridged networking with multiple virtual machines, it is essential that each virtual machine has a unique link-level (MAC) address on the virtual machine side of the tap device. Otherwise, the bridge will not work correctly, because it will receive packets from multiple sources that have the same link-level address. This problem occurs even if the tap devices themselves have unique link-level addresses because the source link-level address is not rewritten as packets pass through the tap device.<br />
<br />
Make sure that each virtual machine has a unique link-level address, but it should always start with {{ic|52:54:}}. Use the following option, replace ''X'' with arbitrary hexadecimal digit:<br />
<br />
$ qemu-system-i386 -net nic,macaddr=52:54:XX:XX:XX:XX -net vde ''disk_image''<br />
<br />
Generating unique link-level addresses can be done in several ways:<br />
<br />
1. Manually specify unique link-level address for each NIC. The benefit is that the DHCP server will assign the same IP address each time the virtual machine is run, but it is unusable for large number of virtual machines.<br />
<br />
2. Generate random link-level address each time the virtual machine is run. Practically zero probability of collisions, but the downside is that the DHCP server will assign a different IP address each time. You can use the following command in a script to generate random link-level address in a {{ic|macaddr}} variable:<br />
<br />
printf -v macaddr "52:54:%02x:%02x:%02x:%02x" $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff )) $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff ))<br />
qemu-system-i386 -net nic,macaddr="$macaddr" -net vde ''disk_image''<br />
<br />
3. Use the following script {{ic|qemu-mac-hasher.py}} to generate the link-level address from the virtual machine name using a hashing function. Given that the names of virtual machines are unique, this method combines the benefits of the aforementioned methods: it generates the same link-level address each time the script is run, yet it preserves the practically zero probability of collisions.<br />
<br />
{{hc|qemu-mac-hasher.py|<nowiki><br />
#!/usr/bin/env python<br />
<br />
import sys<br />
import zlib<br />
<br />
if len(sys.argv) != 2:<br />
print("usage: %s <VM Name>" % sys.argv[0])<br />
sys.exit(1)<br />
<br />
crc = zlib.crc32(sys.argv[1].encode("utf-8")) & 0xffffffff<br />
crc = str(hex(crc))[2:]<br />
print("52:54:%s%s:%s%s:%s%s:%s%s" % tuple(crc))<br />
</nowiki>}}<br />
<br />
In a script, you can use for example:<br />
<br />
vm_name="''VM Name''"<br />
qemu-system-i386 -name "$vm_name" -net nic,macaddr=$(qemu-mac-hasher.py "$vm_name") -net vde ''disk_image''<br />
<br />
=== User-mode networking ===<br />
<br />
By default, without any {{ic|-netdev}} arguments, QEMU will use user-mode networking with a built-in DHCP server. Your virtual machines will be assigned an IP address when they run their DHCP client, and they will be able to access the physical host's network through IP masquerading done by QEMU. This only works with the TCP and UDP protocols, so ICMP, including {{ic|ping}}, will not work. <br />
<br />
This default configuration allows your virtual machines to easily access the Internet, provided that the host is connected to it, but the virtual machines will not be directly visible on the external network, nor will virtual machines be able to talk to each other if you start up more than one concurrently.<br />
<br />
QEMU's user-mode networking can offer more capabilities such as built-in TFTP or SMB servers, or attaching guests to virtual LANs so that they can talk to each other. See the QEMU documentation on the {{ic|-net user}} flag for more details.<br />
<br />
However, user-mode networking has limitations in both utility and performance. More advanced network configurations require the use of tap devices or other methods.<br />
<br />
=== Tap networking with QEMU ===<br />
<br />
[[wikipedia:TUN/TAP|Tap devices]] are a Linux kernel feature that allows you to create virtual network interfaces that appear as real network interfaces. Packets sent to a tap interface are delivered to a userspace program, such as QEMU, that has bound itself to the interface.<br />
<br />
QEMU can use tap networking for a virtual machine so that packets sent to the tap interface will be sent to the virtual machine and appear as coming from a network interface (usually an Ethernet interface) in the virtual machine. Conversely, everything that the virtual machine sends through its network interface will appear on the tap interface.<br />
<br />
Tap devices are supported by the Linux bridge drivers, so it is possible to bridge together tap devices with each other and possibly with other host interfaces such as {{ic|eth0}}. This is desirable if you want your virtual machines to be able to talk to each other, or if you want other machines on your LAN to be able to talk to the virtual machines.<br />
<br />
{{Warning|If you bridge together tap device and some host interface, such as {{ic|eth0}}, your virtual machines will appear directly on the external network, which will expose them to possible attack. Depending on what resources your virtual machines have access to, you may need to take all the precautions you normally would take in securing a computer to secure your virtual machines. If the risk is too great, virtual machines have little resources or you set up multiple virtual machines, better solution might be to use [[#Host-only networking|host-only networking]] and set up NAT. In this case you only need one firewall on the host instead of multiple firewalls for each guest.}}<br />
<br />
==== Host-only networking ====<br />
<br />
If the bridge is given an IP address and traffic destined for it is allowed, but no real interface (e.g. {{ic|eth0}}) is connected to the bridge, then the virtual machines will be able to talk to each other and the host system. However, they will not be able to talk to anything on the external network, provided that you do not set up IP masquerading on the physical host. This configuration is called ''host-only networking'' by other virtualization software such as [[VirtualBox]].<br />
<br />
{{Tip|<br />
* If you want to set up IP masquerading, e.g. NAT for virtual machines, see the [[Internet Share#Enable NAT]] page.<br />
* You may want to have a DHCP server running on the bridge interface to service the virtual network. For example, to use the {{ic|172.20.0.1/16}} subnet with [[dnsmasq]] as the DHCP server:<br />
# ip addr add 172.20.0.1/16 dev br0<br />
# ip link set br0 up<br />
# dnsmasq --interface&#61;br0 --bind-interfaces --dhcp-range&#61;172.20.0.2,172.20.255.254<br />
}}<br />
<br />
==== Internal networking ====<br />
<br />
If you do not give the bridge an IP address and add an [[iptables]] rule to drop all traffic to the bridge in the INPUT chain, then the virtual machines will be able to talk to each other, but not to the physical host or to the outside network. This configuration is called ''internal networking'' by other virtualization software such as [[VirtualBox]]. You will need to either assign static IP addresses to the virtual machines or run a DHCP server on one of them.<br />
<br />
==== Bridged networking using qemu-bridge-helper ====<br />
<br />
{{Note|This method is available since QEMU 1.1, see http://wiki.qemu.org/Features/HelperNetworking.}}<br />
<br />
This method does not require start-up script and readily accommodates multiple taps and multiple bridges. It uses {{ic|/usr/lib/qemu/qemu-bridge-helper}} binary, which allows creating tap devices on an existing bridge.<br />
<br />
{{Tip|See [[Bridge with netctl]] for information on creating bridge.}} <br />
<br />
First, copy {{ic|/etc/qemu/bridge.conf.sample}} to {{ic|/etc/qemu/bridge.conf}}. Now modify {{ic|/etc/qemu/bridge.conf}} to contain the names of all bridges to be used by QEMU: <br />
<br />
{{hc|/etc/qemu/bridge.conf|<nowiki><br />
allow <bridge0><br />
allow <bridge1><br />
...<br />
</nowiki>}}<br />
<br />
Now start the VM. The most basic usage would be:<br />
<br />
$ qemu-system-i386 -net nic -net bridge,br=<bridge0> [...]<br />
<br />
With multiple taps, the most basic usage requires specifying the vlan for all additional nics:<br />
<br />
$ qemu-system-i386 -net nic -net bridge,br=<bridge0> -net nic,vlan=1 -net bridge,vlan=1,br=<bridge1> [...]<br />
<br />
==== Creating bridge manually ====<br />
<br />
{{Poor writing|This section needs serious cleanup and may contain out-of-date information.}}<br />
<br />
{{Tip|Since QEMU 1.1, the [http://wiki.qemu.org/Features/HelperNetworking network bridge helper] can set tun/tap up for you without the need for additional scripting. See [[#Creating bridge using qemu-bridge-helper]].}}<br />
<br />
The following describes how to bridge a virtual machine to a host interface such as {{ic|eth0}}, which is probably the most common configuration. This configuration makes it appear that the virtual machine is located directly on the external network, on the same Ethernet segment as the physical host machine.<br />
<br />
We will replace the normal Ethernet adapter with a bridge adapter and bind the normal Ethernet adapter to it. See http://en.gentoo-wiki.com/wiki/KVM#Networking_2{{Linkrot|2013|07|23}}.<br />
<br />
* Install {{Pkg|bridge-utils}}, which provides {{ic|brctl}} to manipulate bridges.<br />
<br />
* Enable IPv4 forwarding:<br />
# sysctl net.ipv4.ip_forward=1<br />
<br />
To make the change permanent, change {{ic|1=net.ipv4.ip_forward = 0}} to {{ic|1=net.ipv4.ip_forward = 1}} in {{ic|/etc/sysctl.conf}}.<br />
<br />
* Load the {{ic|tun}} module and configure it to be loaded on boot. See [[Kernel modules]] for details.<br />
<br />
* Now create the bridge. See [[Bridge with netctl]] for details. Remember to name your bridge as {{ic|br0}}, or change the scripts below to your bridge's name.<br />
<br />
* Create the script that QEMU uses to bring up the tap adapter with root:kvm 750 permissions:<br />
{{hc|/etc/qemu-ifup|<nowiki><br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifup"<br />
echo "Bringing up $1 for bridged mode..."<br />
sudo /usr/bin/ip link set $1 up promisc on<br />
echo "Adding $1 to br0..."<br />
sudo /usr/bin/brctl addif br0 $1<br />
sleep 2<br />
</nowiki>}}<br />
<br />
* Create the script that QEMU uses to bring down the tap adapter in {{ic|/etc/qemu-ifdown}} with root:kvm 750 permissions:<br />
{{hc|/etc/qemu-ifdown|<nowiki><br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifdown"<br />
sudo /usr/bin/ip link set $1 down<br />
sudo /usr/bin/brctl delif br0 $1<br />
sudo /usr/bin/ip link delete dev $1<br />
</nowiki>}}<br />
<br />
* Use {{ic|visudo}} to add the following to your {{ic|sudoers}} file:<br />
{{bc|<nowiki><br />
Cmnd_Alias QEMU=/usr/bin/ip,/usr/bin/modprobe,/usr/bin/brctl<br />
%kvm ALL=NOPASSWD: QEMU<br />
</nowiki>}}<br />
<br />
* Make sure the user(s) wishing to use this new functionality are in the {{ic|kvm}} group. Exit and log in again if necessary.<br />
<br />
* You launch QEMU using the following {{ic|run-qemu}} script:<br />
{{hc|run-qemu|<nowiki><br />
#!/bin/bash<br />
USERID=$(whoami)<br />
<br />
# Get name of newly created TAP device; see https://bbs.archlinux.org/viewtopic.php?pid=1285079#p1285079<br />
precreationg=$(/usr/bin/ip tuntap list | /usr/bin/cut -d: -f1 | /usr/bin/sort)<br />
sudo /usr/bin/ip tuntap add user $USERID mode tap<br />
postcreation=$(/usr/bin/ip tuntap list | /usr/bin/cut -d: -f1 | /usr/bin/sort)<br />
IFACE=$(comm -13 <(echo "$precreationg") <(echo "$postcreation"))<br />
<br />
# This line creates a random mac address. The downside is the dhcp server will assign a different ip each time<br />
printf -v macaddr "52:54:%02x:%02x:%02x:%02x" $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff )) $(( $RANDOM & 0xff)) $(( $RANDOM & 0xff ))<br />
# Instead, uncomment and edit this line to set an static mac address. The benefit is that the dhcp server will assign the same ip.<br />
# macaddr='52:54:be:36:42:a9'<br />
<br />
qemu-system-i386 -net nic,macaddr=$macaddr -net tap,ifname="$IFACE" $*<br />
<br />
sudo ip link set dev $IFACE down &> /dev/null<br />
sudo ip tuntap del $IFACE mode tap &> /dev/null <br />
</nowiki>}}<br />
<br />
Then to launch a VM, do something like this<br />
$ run-qemu -hda myvm.img -m 512 -vga std<br />
<br />
{{Tip|If you cannot get a DHCP address in the host, it might be because [[iptables]] are up by default in the bridge.}}<br />
<br />
* It is recommended for performance and security reasons to disable the firewall on the bridge:<br />
{{hc|/etc/sysctl.conf|<nowiki><br />
net.bridge.bridge-nf-call-ip6tables = 0<br />
net.bridge.bridge-nf-call-iptables = 0<br />
net.bridge.bridge-nf-call-arptables = 0<br />
</nowiki>}}<br />
Run {{ic|sysctl -p /etc/sysctl.conf}} to apply changes to {{ic|/etc/sysctl.conf}}.<br />
<br />
See the [http://wiki.libvirt.org/page/Networking#Creating_network_initscripts libvirt wiki] and [https://bugzilla.redhat.com/show_bug.cgi?id=512206 Fedora bug 512206]. If you get errors by sysctl during boot about non-existing files, make the {{ic|bridge}} module load at boot. See [[Kernel modules#Loading]].<br />
<br />
Alternatively, you can configure [[iptables]] to allow all traffic to be forwarded across the bridge by adding a rule like this:<br />
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT<br />
<br />
=== Networking with VDE2 ===<br />
<br />
{{Poor writing|This section needs serious cleanup and may contain out-of-date information.}}<br />
<br />
==== What is VDE? ====<br />
<br />
VDE stands for Virtual Distributed Ethernet. It started as an enhancement of [[User-mode Linux|uml]]_switch. It is a toolbox to manage virtual networks.<br />
<br />
The idea is to create virtual switches, which are basically sockets, and to "plug" both physical and virtual machines in them. The configuration we show here is quite simple; However, VDE is much more powerful than this, it can plug virtual switches together, run them on different hosts and monitor the traffic in the switches. You are invited to read [http://wiki.virtualsquare.org/wiki/index.php/Main_Page the documentation of the project].<br />
<br />
The advantage of this method is you do not have to add sudo privileges to your users. Regular users should not be allowed to run modprobe.<br />
<br />
==== Basics ====<br />
<br />
VDE support can be [[pacman|installed]] via the {{Pkg|vde2}} package in the [[Official Repositories|official repositories]].<br />
<br />
In our config, we use tun/tap to create a virtual interface on my host. Load the {{ic|tun}} module (see [[Kernel modules]] for details):<br />
<br />
# modprobe tun<br />
<br />
Now create the virtual switch:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group kvm<br />
<br />
This line creates the switch, creates {{ic|tap0}}, "plugs" it, and allows the users of the group {{ic|kvm}} to use it.<br />
<br />
The interface is plugged in but not configured yet. To configure it, run this command:<br />
<br />
# ip addr add 192.168.100.254/24 dev tap0<br />
<br />
Now, you just have to run KVM with these {{ic|-net}} options as a normal user:<br />
<br />
$ qemu-system-i386 -net nic -net vde -hda [...]<br />
<br />
Configure networking for your guest as you would do in a physical network.<br />
<br />
{{Tip|You might want to set up NAT on tap device to access the internet from the virtual machine. See [[Internet Share#Enable NAT]] for more information.}}<br />
<br />
==== Startup scripts ====<br />
<br />
Example of main script starting VDE:<br />
<br />
{{hc|/etc/systemd/scripts/qemu-network-env|<nowiki><br />
#!/bin/sh<br />
# QEMU/VDE network environment preparation script<br />
<br />
# The IP configuration for the tap device that will be used for<br />
# the virtual machine network:<br />
<br />
TAP_DEV=tap0<br />
TAP_IP=192.168.100.254<br />
TAP_MASK=24<br />
TAP_NETWORK=192.168.100.0<br />
<br />
<br />
# Host interface<br />
NIC=eth0<br />
<br />
case "$1" in<br />
start)<br />
echo -n "Starting VDE network for QEMU: "<br />
<br />
# If you want tun kernel module to be loaded by script uncomment here <br />
#modprobe tun 2>/dev/null<br />
## Wait for the module to be loaded<br />
#while ! lsmod |grep -q "^tun"; do echo Waiting for tun device;sleep 1; done<br />
<br />
# Start tap switch<br />
vde_switch -tap "$TAP_DEV" -daemon -mod 660 -group kvm<br />
<br />
# Bring tap interface up<br />
ip address add "$TAP_IP"/"$TAP_MASK" dev "$TAP_DEV"<br />
ip link set "$TAP_DEV" up<br />
<br />
# Start IP Forwarding<br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
iptables -t nat -A POSTROUTING -s "$TAP_NETWORK"/"$TAP_MASK" -o "$NIC" -j MASQUERADE<br />
;;<br />
stop)<br />
echo -n "Stopping VDE network for QEMU: "<br />
# Delete the NAT rules<br />
iptables -t nat -D POSTROUTING "$TAP_NETWORK"/"$TAP_MASK" -o "$NIC" -j MASQUERADE<br />
<br />
# Bring tap interface down<br />
ip link set "$TAP_DEV" down<br />
<br />
# Kill VDE switch<br />
pgrep -f vde_switch | xargs kill -TERM <br />
;;<br />
restart|reload)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
*)<br />
echo "Usage: $0 {start|stop|restart|reload}"<br />
exit 1<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Example of systemd service using the above script:<br />
<br />
{{hc|/etc/systemd/system/qemu-network-env.service|<nowiki><br />
[Unit]<br />
Description=Manage VDE Switch<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/etc/systemd/scripts/qemu-network-env start<br />
ExecStop=/etc/systemd/scripts/qemu-network-env stop<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Change permissions for qemu-network-env to be executable<br />
<br />
# chmod u+x /etc/systemd/scripts/qemu-network-env<br />
<br />
You can start it as usual (see [[systemd#Using units]] for details):<br />
<br />
# systemctl start qemu-network-env<br />
<br />
====Alternative method====<br />
<br />
If the above method does not work or you do not want to mess with kernel configs, TUN, dnsmasq and iptables you can do the following for the same result.<br />
<br />
# vde_switch -daemon -mod 660 -group kvm<br />
# slirpvde --dhcp --daemon<br />
<br />
Then to start the vm with a connection to the network of the host:<br />
<br />
$ qemu-system-i386 -net nic,macaddr=52:54:00:00:EE:03 -net vde <disk_image><br />
<br />
=== VDE2 Bridge ===<br />
<br />
Based on [http://selamatpagicikgu.wordpress.com/2011/06/08/quickhowto-qemu-networking-using-vde-tuntap-and-bridge/ quickhowto: qemu networking using vde, tun/tap, and bridge] graphic. Any virtual machine connected to vde is externally exposed. For example, each virtual machine can receive dhcp configuration directly from you ADSL router.<br />
<br />
==== Basics ====<br />
<br />
Remember that you need {{ic|tun}} module and {{Pkg|bridge-utils}} package.<br />
<br />
Create the vde2/tap device:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group kvm<br />
# ip link set tap0 up<br />
<br />
Create bridge:<br />
<br />
# brctl addbr br0<br />
<br />
Add devices:<br />
<br />
# brctl addif br0 eth0<br />
# brctl addif br0 tap0<br />
<br />
And configure bridge interface:<br />
<br />
# dhcpcd br0<br />
<br />
==== Startup scripts ====<br />
<br />
All devices must be set up. And only the bridge needs ip address. For physical devices on the bridge (e.g. {{ic|eth0}}), this can be done with [[netctl]] using a custom ethernet profile with:<br />
<br />
{{hc|/etc/netctl/ethernet-noip|<nowiki><br />
Description='A more versatile static ethernet connection'<br />
Interface=eth0<br />
Connection=ethernet<br />
IP=no<br />
</nowiki>}}<br />
<br />
VDE2 tap interface can be activated with the [[systemd/Services#VDE2_interface|VDE2 interface custom systemd service]].<br />
<br />
And finally, you can create the [[Bridge with netctl |bridge interface with netctl]].<br />
<br />
== Graphics ==<br />
<br />
QEMU can use the following different graphic outputs: {{ic|std}}, {{ic|cirrus}}, {{ic|vmware}}, {{ic|qxl}}, {{ic|xenfb}} and {{ic|vnc}}. With the {{ic|vnc}} option you can run your guest standalone and connect to it via VNC.<br />
<br />
{{Expansion|Missing info on how to enable VNC. It's not {{ic|-vga vnc}}.}}<br />
<br />
=== std ===<br />
<br />
With {{ic|-vga std}} you can get a resolution of up to 2560 x 1600 pixels.<br />
<br />
=== vmware ===<br />
<br />
Although it is a bit buggy, it performs better than std and cirrus. On the guest, install the VMware drivers. For Arch Linux guests:<br />
<br />
# pacman -S xf86-video-vmware xf86-input-vmmouse<br />
<br />
=== qxl ===<br />
<br />
QXL is a paravirt graphics driver with 2D support. You can install it from AUR {{AUR|xf86-video-qxl}} in your guest VM. <br />
Then start your VM with {{ic|-vga qxl}}<br />
<br />
=== none ===<br />
<br />
If you do not want to see the graphical output from your virtual machine because you will be accessing it entirely through the network or serial port, you can run QEMU with the {{ic|-nographic}} option.<br />
<br />
== Installing virtio drivers ==<br />
<br />
QEMU offers guests the ability to use paravirtualized block and network devices using the [http://wiki.libvirt.org/page/Virtio virtio] drivers, which provide better performance and lower overhead.<br />
<br />
* A virtio block device requires the option {{Ic|-drive}} instead of the simple {{Ic|-hd*}} plus {{Ic|1=if=virtio}}:<br />
$ qemu-system-i386 -boot order=c -drive file=<disk_image>,if=virtio<br />
<br />
{{Note|{{Ic|1=-boot order=c}} is absolutely necessary when you want to boot from it. There is no auto-detection as with {{Ic|-hd*}}.}}<br />
<br />
* Almost the same goes for the network:<br />
$ qemu-system-i386 -net nic,model=virtio<br />
<br />
{{Note|This will only work if the guest machine has a drivers for virtio devices. Linux does, and the required drivers are included in Arch Linux, but there is no guarantee that virtio devices will work with other operating systems.}}<br />
<br />
=== Preparing an (Arch) Linux guest ===<br />
<br />
To use virtio devices after an Arch Linux guest has been installed, the following modules can be loaded in the guest: {{Ic|virtio}}, {{Ic|virtio_pci}}, {{Ic|virtio_blk}}, {{Ic|virtio_net}}, and {{Ic|virtio_ring}} (for 32-bit guests, the specific "virtio" module is not necessary).<br />
<br />
If you want to boot from a virtio disk, the initial ramdisk must be [[mkinitcpio|rebuilt]]. Add the appropriate modules in {{ic|/etc/mkinitcpio.conf}} like this:<br />
MODULES="virtio_blk virtio_pci virtio_net"<br />
and rebuild the initial ramdisk:<br />
# mkinitcpio -p linux<br />
<br />
Virtio disks are recognized with the prefix {{ic|'''v'''}} (e.g. {{ic|'''v'''da}}, {{ic|'''v'''db}}, etc.); therefore, changes must be made in at least {{ic|/etc/fstab}} and {{ic|/boot/grub/grub.cfg}} when booting from a virtio disk.<br />
<br />
{{Tip|When referencing to disks by [[Persistent_block_device_naming#By-uuid|UUID]] in both {{ic|/etc/fstab}} and bootloader, nothing has to be done.}}<br />
<br />
Further information on paravirtualization with KVM can be found [http://www.linux-kvm.org/page/Boot_from_virtio_block_device here].<br />
<br />
=== Preparing a Windows guest ===<br />
<br />
==== Block device drivers ====<br />
<br />
Preparing a Windows guest for booting from virtio disk is a bit tricky.<br />
<br />
You can download the virtio disk driver from the [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers Fedora repository].<br />
<br />
Now you need to create a new disk image, which fill force Windows to search for the driver. For example:<br />
$ qemu-img create -f qcow2 fake.qcow2 1G<br />
<br />
Run the original Windows guest (with the boot disk still in IDE mode) with the fake disk (in virtio mode) and a CD-ROM with the driver.<br />
$ qemu-system-i386 -m 512 -vga std -drive file=<windows_disk_image>,if=ide -drive file=fake.qcow2,if=virtio -cdrom virtio-win-0.1-59.iso<br />
<br />
Windows will detect the fake disk and try to find a driver for it. If it fails, go to the ''Device Manager'', locate the SCSI drive with an exclamation mark icon (should be open), click ''Update driver'' and select the virtual CD-ROM. Don't forget to mark the checkbox which says to search for directories recursively.<br />
<br />
When the installation is successful, you can turn off the virtual machine and launch it again, now with the boot disk attached in virtio mode:<br />
$ qemu-system-i386 -m 512 -vga std -drive file=<windows_disk_image>,if=virtio<br />
<br />
{{Note|If you encounter the Blue Screen of Death, make sure you did not forget the {{ic|-m}} parameter, and that you do not boot with virtio instead of ide for the system drive before drivers are installed.}}<br />
<br />
==== Network drivers ====<br />
<br />
Installing virtio network drivers is a bit easier, simply add the {{ic|-net}} argument as explained above.<br />
$ qemu-system-i386 -m 512 -vga std -drive file=<windows_disk_image>,if=virtio -net nic,model=virtio -cdrom virtio-win-0.1-30.iso<br />
<br />
Windows will detect the network adapter and try to find a driver for it. If it fails, go to the ''Device Manager'', locate the network adapter with an exclamation mark icon (should be open), click ''Update driver'' and select the virtual CD-ROM. Don't forget to mark the checkbox which says to search for directories recursively.<br />
<br />
=== Preparing a FreeBSD guest ===<br />
<br />
Install the {{ic|emulators/virtio-kmod}} port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your {{ic|/boot/loader.conf}} file:<br />
<br />
{{bc|<nowiki><br />
virtio_loader="YES"<br />
virtio_pci_load="YES"<br />
virtio_blk_load="YES"<br />
if_vtnet_load="YES"<br />
virtio_balloon_load="YES"<br />
</nowiki>}}<br />
<br />
Then modify your {{ic|/etc/fstab}} by doing the following:<br />
<br />
{{bc|<nowiki><br />
sed -i/etc/fstab.bak "s/ad/vtbd/g" /etc/fstab<br />
</nowiki>}}<br />
<br />
And verify that {{ic|/etc/fstab}} is consistent. If anything goes wrong, just boot into a rescue CD and copy {{ic|/etc/fstab.bak}} back to {{ic|/etc/fstab}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Starting QEMU virtual machines on boot ===<br />
<br />
==== With libvirt ====<br />
<br />
If a virtual machine is set up with [[libvirt]], it can be configured through the virt-manager GUI to start at host boot by going to the Boot Options for the virtual machine and selecting "Start virtual machine on host boot up".<br />
<br />
==== Custom script ====<br />
<br />
To run QEMU VMs on boot, you can use following systemd unit and config.<br />
<br />
{{hc|/etc/systemd/system/qemu@.service|<nowiki><br />
[Unit]<br />
Description=QEMU virtual machine<br />
<br />
[Service]<br />
Environment="type=system-x86_64" "haltcmd=kill -INT $MAINPID"<br />
EnvironmentFile=/etc/conf.d/qemu.d/%i<br />
ExecStart=/usr/bin/qemu-${type} -name %i -nographic ${args}<br />
ExecStop=/bin/sh -c ${haltcmd}<br />
TimeoutStopSec=30<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Then create per-VM configuration files, named {{ic|/etc/conf.d/qemu.d/''vm_name''}}, with the following variables set:<br />
<br />
; type<br />
: QEMU binary to call. If specified, will be prepended with {{ic|/usr/bin/qemu-}} and that binary will be used to start the VM. I.e. you can boot e.g. {{ic|qemu-system-arm}} images with {{ic|1=type="system-arm"}}.<br />
; args<br />
: QEMU command line to start with. Will always be prepended with {{ic|-name ${vm} -nographic}}.<br />
; haltcmd<br />
: Command to shutdown VM safely. I am using {{ic|-monitor telnet:..}} and power off my VMs via ACPI by sending {{ic|system_powerdown}} to monitor. You can use ssh or some other ways.<br />
<br />
Example configs:<br />
{{hc|/etc/conf.d/qemu.d/one|<nowiki><br />
type="system-x86_64"<br />
<br />
args="-enable-kvm -m 512 -hda /dev/mapper/vg0-vm1 -net nic,macaddr=DE:AD:BE:EF:E0:00 \<br />
-net tap,ifname=tap0 -serial telnet:localhost:7000,server,nowait,nodelay \<br />
-monitor telnet:localhost:7100,server,nowait,nodelay -vnc :0"<br />
<br />
haltcmd="echo 'system_powerdown' | nc localhost 7100" # or netcat/ncat<br />
<br />
# You can use other ways to shutdown your VM correctly<br />
#haltcmd="ssh powermanager@vm1 sudo poweroff"<br />
</nowiki>}}<br />
{{hc|/etc/conf.d/qemu.d/two|<nowiki><br />
args="-enable-kvm -m 512 -hda /srv/kvm/vm2.img -net nic,macaddr=DE:AD:BE:EF:E0:01 \<br />
-net tap,ifname=tap1 -serial telnet:localhost:7001,server,nowait,nodelay \<br />
-monitor telnet:localhost:7101,server,nowait,nodelay -vnc :1"<br />
<br />
haltcmd="echo 'system_powerdown' | nc localhost 7101"<br />
</nowiki>}}<br />
<br />
To set which virtual machines will start on bootup, use<br />
# systemctl enable qemu@<var>vm_name</var><br />
# systemctl disable qemu@<var>vm_name</var><br />
<br />
=== Mouse integration ===<br />
<br />
To prevent the mouse from being grabbed when clicking on the guest operating system's window, add the option {{ic|-usbdevice tablet}}. This means QEMU is able to report the mouse position without having to grab the mouse. This also overrides PS/2 mouse emulation when activated. For example:<br />
$ qemu-system-i386 -hda <disk_image> -m 512 -vga std -usbdevice tablet<br />
<br />
=== Pass-through host USB device ===<br />
<br />
To access physical USB device connected to host from VM, you can start QEMU with following option:<br />
<br />
$ qemu-system-i386 -usbdevice host:<vendor_id>:<product_id> <disk_image><br />
<br />
You can find {{ic|vendor_id}} and {{ic|product_id}} of your device with {{ic|lsusb}} command.<br />
<br />
{{Note|If you encounter permission errors when running QEMU, see [[Udev#Writing udev rules]] for information on how to set permissions of the device.}}<br />
<br />
=== Enabling KSM ===<br />
<br />
Kernel Samepage Merging (KSM) is a feature of the Linux kernel introduced in the 2.6.32 kernel. KSM allows for an application to register with the kernel to have its pages merged with other processes that also register to have their pages merged. The KSM mechanism allows for guest virtual machines to share pages with each other. In an environment where many of the guest operating systems are similar, this can result in significant memory savings.<br />
<br />
To enable KSM, simply run<br />
# echo 1 > /sys/kernel/mm/ksm/run<br />
<br />
To make it permanent, you can use [[systemd#Temporary files|systemd's temporary files]]:<br />
{{hc|/etc/tmpfiles.d/ksm.conf|<br />
w /sys/kernel/mm/ksm/run - - - - 1<br />
}}<br />
<br />
If KSM is running, and there are pages to be merged (i.e. at least two similar VMs are running), then {{ic|/sys/kernel/mm/ksm/pages_shared}} should be non-zero. See https://www.kernel.org/doc/Documentation/vm/ksm.txt for more information.<br />
<br />
{{Tip|An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory: {{bc|$ grep . /sys/kernel/mm/ksm/*}}}}<br />
<br />
=== Spice support ===<br />
<br />
The Spice project aims to provide a complete open source solution for interaction with virtualized desktop devices. Its main focus is to provide high-quality remote access to QEMU virtual machines. [http://spice-space.org/ Spice project homepage]<br />
<br />
The official {{Pkg|qemu}} package is built without Spice support; however, there's {{AUR|qemu-spice}} package in the [[Arch User Repository|AUR]]. Alternatively you can grab the official [[PKGBUILD]] from [[Arch Build System|ABS]] and compile with {{ic|--enable-spice}} flag.<br />
<br />
After installation of all the spice-enabled QEMU package, you can start your VM:<br />
<br />
$ qemu-system-i386 -vga qxl -spice port=5930,disable-ticketing<br />
<br />
Then connect with the the spice client<br />
<br />
$ spicec -h 127.0.0.1 -p 5930<br />
<br />
{{Tip|Spice guest drivers can be downloaded [http://www.spice-space.org/download.html here] in the ''"Guest"'' section.}}<br />
<br />
=== Windows-specific notes ===<br />
<br />
QEMU can run any version of Windows from Windows 95 through Windows 8.<br />
<br />
It is possible to run [[Windows PE]] in QEMU.<br />
<br />
==== Remote Desktop Protocol ====<br />
<br />
If you use a MS Windows guest, you might want to use RDP to connect to your guest VM. If you are using a VLAN or are not in the same network as the guest, use:<br />
$ qemu -nographic -net user,hostfwd=tcp::5555-:3389<br />
Then connect with either rdesktop or freerdp to the guest, for example:<br />
$ xfreerdp -g 2048x1152 localhost:5555 -z -x lan<br />
<br />
== Troubleshooting ==<br />
<br />
=== Mouse cursor is jittery or erratic ===<br />
<br />
If the cursor jumps around the screen uncontrollably, entering this on the terminal before starting qemu might help:<br />
$ export SDL_VIDEO_X11_DGAMOUSE=0<br />
<br />
If this helps, you can add this to your {{ic|bashrc}}.<br />
<br />
=== Keyboard seems broken or the arrow keys do not work ===<br />
<br />
Should you find that some of your keys do not work or "press" the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in {{ic|/usr/share/qemu/keymaps}}.<br />
$ qemu-system-i386 -k <keymap> <disk_image><br />
<br />
=== Virtual machine runs too slowly ===<br />
<br />
There are a number of techniques that you can use to improve the performance if your virtual machine. For example:<br />
<br />
* Use the {{ic|-cpu host}} option to make QEMU emulate the host's exact CPU. If you don't do this, it may be trying to emulate a more generic CPU.<br />
* If the host machine has multiple CPUs, assign the guest more CPUs using the {{ic|-smp}} option.<br />
* Make sure you have assigned the virtual machine enough memory. By default, QEMU only assigns 128MiB of memory to each virtual machine. Use the {{ic|-m}} option to assign more memory. For example, {{ic|-m 1024}} runs a virtual machine with 1024MiB of memory.<br />
* Use KVM if possible: add {{ic|1=-machine type=pc,accel=kvm}} to the qemu start command you use.<br />
* If supported by drivers in the guest operating system, use [http://wiki.libvirt.org/page/Virtio virtio] for network and/or block devices. For example:<br />
$ qemu-system-i386 -net nic,model=virtio -net tap,if=tap0,script=no -drive file=<disk_image>,media=disk,if=virtio<br />
* Use TAP devices instead of user-mode networking. See [[#Tap networking with QEMU]].<br />
* If the guest OS is doing heavy writing to its disk, you may benefit from certain mount options on the host's filesystem. For example, you can mount an [[Ext4|ext4 filesystem]] with the option {{ic|<nowiki>barrier=0</nowiki>}}. You should read the documentation for any options that you change, since sometimes performance-enhancing options for filesystems come at the cost of data integrity.<br />
* If you have a raw disk image, disable the cache:<br />
$ qemu-system-i386 -drive file=<disk_image>,if=virtio,cache=none<br />
* If you are running multiple virtual machines concurrently that all have the same operating system installed, you can save memory by enabling [[wikipedia:Kernel_SamePage_Merging_(KSM)|kernel same-page merging]]:<br />
# echo 1 > /sys/kernel/mm/ksm/run<br />
* In some cases, memory can be reclaimed from running virtual machines by running a memory ballooning driver in the guest operating system and launching QEMU with the {{ic|-balloon virtio}} option.<br />
<br />
See http://www.linux-kvm.org/page/Tuning_KVM for more information.<br />
<br />
== See also ==<br />
<br />
* [http://qemu.org Official QEMU website]<br />
* [http://www.linux-kvm.org Official KVM website]<br />
* [http://qemu.weilnetz.de/qemu-doc.html QEMU Emulator User Documentation]<br />
* [http://en.wikibooks.org/wiki/QEMU QEMU Wikibook]<br />
* ''[http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu Hardware virtualization with QEMU]'' by AlienBOB<br />
* ''[http://blog.falconindy.com/articles/build-a-virtual-army.html Building a Virtual Army]'' by Falconindy<br />
* ''[http://qemu-buch.de/de/index.php/QEMU-KVM-Book/_Content QEMU, KVM, Xen & libvirt]'' by Robert Warnke and Thomas Ritzau</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=Adb&diff=263649Adb2013-06-20T14:24:02Z<p>Txus.palacios: Most users that look for adb are looking for the Android page.</p>
<hr />
<div>#REDIRECT [[Android]]</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=Awesome&diff=263165Awesome2013-06-17T21:25:17Z<p>Txus.palacios: /* Transparency */</p>
<hr />
<div>[[Category:Dynamic WMs]]<br />
[[Category:Tiling WMs]]<br />
[[cs:Awesome]]<br />
[[es:Awesome]]<br />
[[fr:Awesome3]]<br />
[[it:Awesome]]<br />
[[ja:Awesome]]<br />
[[ko:Awesome]]<br />
[[ru:Awesome]]<br />
[[sv:Awesome]]<br />
[[zh-CN:Awesome]]<br />
{{Lowercase title}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|A guide on how to install, use, configure, and customize awesome window manager.}}<br />
{{Article summary end}}<br />
<br />
From the [[Wikipedia:awesome (window manager)|awesome]] website:<br />
<br />
"''[http://awesome.naquadah.org/ awesome] is a highly configurable, next generation framework window manager for X. It is very fast, extensible and licensed under the GNU GPLv2 license.''<br />
<br />
''It is primarly targeted at power users, developers and any people dealing with every day computing tasks and who want to have fine-grained control on its graphical environment.''"<br />
<br />
==Installation==<br />
<br />
Install {{pkg|awesome}} from the [[official repositories]].<br />
<br />
For pre-release versions, an {{aur|awesome-git}} build is in the [[Arch User Repository|AUR]]. These versions are not considered stable and may have a different configuration syntax.<br />
<br />
== Run awesome ==<br />
<br />
=== Without login manager ===<br />
To run awesome without a login manager, simply add {{Ic|exec awesome}} to the startup script of your choice (e.g. ~/.xinitrc.)<br />
<br />
See [[xinitrc]] for details, such as preserving the logind (and/or consolekit) session.<br />
<br />
You can also start awesome as preferred user without even logging in. See [[Start X at Login]].<br />
<br />
=== With login manager ===<br />
To start awesome from a login manager, see [[Display Manager|this article]].<br />
<br />
==== GDM, LightDM, others using /usr/share/xsessions/ ====<br />
<br />
Awesome automatically installs a config file for these display managers. You don't need to do anything special to see awesome offered at login.<br />
<br />
==== KDM ====<br />
<br />
Create as root:<br />
{{hc|/usr/share/apps/kdm/sessions/awesome.desktop|2=<br />
[Desktop Entry]<br />
Name=Awesome<br />
Comment=Tiling Window Manager<br />
Type=Application<br />
Exec=/usr/bin/awesome<br />
TryExec=/usr/bin/awesome<br />
}}<br />
<br />
==Configuration==<br />
Awesome includes some good default settings right out of the box, but sooner or later you'll want to change something. The lua based configuration file is at {{Ic|~/.config/awesome/rc.lua}}.<br />
<br />
===Creating the configuration file===<br />
First, run the following to create the directory needed in the next step:<br />
$ mkdir -p ~/.config/awesome/<br />
<br />
Whenever compiled, awesome will attempt to use whatever custom settings are contained in ~/.config/awesome/rc.lua. This file is not created by default, so we must copy the template file first:<br />
$ cp /etc/xdg/awesome/rc.lua ~/.config/awesome/<br />
<br />
The syntax of the configuration often changes when awesome updates. So, remember to repeat the command above when you get something strange with awesome, or you'd like to modify the configuration.<br />
<br />
For more information about configuring awesome, check out the [http://awesome.naquadah.org/wiki/Awesome_3_configuration configuration page at awesome wiki]<br />
<br />
===More configuration resources===<br />
{{Note|The syntax of awesome configuration changes regularly, so you will likely have to modify any file you download.}}<br />
<br />
Some good examples of rc.lua would be as follows:<br />
<br />
* http://git.sysphere.org/awesome-configs/tree/ - Awesome 3.4 configurations from Adrian C. (anrxc).<br />
* http://pastebin.com/f6e4b064e - Darthlukan's awesome 3.4 configuration. <br />
* http://www.ugolnik.info/downloads/awesome/rc.lua - Awesome 3.1 configuration with small titlebar and statusbar.<br />
* https://github.com/setkeh/Awesome - [[User:Setkeh|Setkeh]]'s 3.4 Configuration.<br />
* https://github.com/setkeh/Awesome-Laptop-3.5 - [[User:Setkeh|Setkeh]]'s 3.5 Configuration.<br />
* http://awesome.naquadah.org/wiki/User_Configuration_Files - Collection of user configurations on the awesome homepage.<br />
<br />
===Debugging rc.lua===<br />
<br />
====Using Xephyr====<br />
[https://www.archlinux.org/packages/?q=xephyr Xephyr] allows you to run X nested in another X's client window. This allows you to debug rc.lua without breaking your current desktop. Start by copying rc.lua into a new file (e.g. rc.lua.new), and modify it as needed. Then run new instance of awesome in Xephyr, supplying rc.lua.new as a config file like this:<br />
<br />
$ Xephyr :1 -ac -br -noreset -screen 1152x720 &<br />
$ DISPLAY=:1.0 awesome -c ~/.config/awesome/rc.lua.new<br />
<br />
The advantage of this approach is that if you introduce bugs you do not break your current awesome desktop, potentially crashing X apps and losing work. Once you are happy with the new configuration, copy rc.lua.new to rc.lua and restart awesome.<br />
<br />
====Using awmtt====<br />
{{aur|awmtt}} (Awesome WM Testing Tool) is an easy to use wrapper script around Xephyr. If you want to debug your rc.lua.new, just pass it as a parameter:<br />
<br />
$ awmtt start --config=~/.config/awesome/rc.lua.new<br />
<br />
When you are done testing, close the window with:<br />
<br />
$ awmtt stop<br />
<br />
===Changing Keyboard Layout===<br />
<br />
If it were necessary for someone to need a different keyboard layout [qwerty -> dvorak] there are methods for such listed [http://awesome.naquadah.org/wiki/Change_keyboard_maps#Display.2Fchange_keyboard_map here on the awesome wiki].<br />
<br />
==Themes==<br />
<br />
[http://awesome.naquadah.org/wiki/Beautiful Beautiful] is a lua library that allows you to theme awesome using an external file, it becomes very easy to dynamically change your whole awesome colours and wallpaper without changing your {{ic|rc.lua}}. <br />
<br />
The default theme is at {{ic|/usr/share/awesome/themes/default}}. Copy it to {{ic|~/.config/awesome/themes/default}} and change {{ic|theme_path}} in {{ic|rc.lua}}. <br />
beautiful.init(awful.util.getdir("config") .. "/themes/default/theme.lua")<br />
<br />
More details [http://awesome.naquadah.org/wiki/Beautiful here]<br />
<br />
A few sample [http://awesome.naquadah.org/wiki/Beautiful_themes themes]<br />
<br />
===Setting up your wallpaper===<br />
{{out of date | With version 3.5 Awesome no longer provides a awsetbg command, instead it has a gears module. You can find how to use it in default config}}<br />
Beautiful can handle your wallpaper, thus you do not need to set it up in your {{ic|.xinitrc}} or {{ic|.xsession}} files. This allows you to have a specific wallpaper for each theme. If you take a look at the default theme file you'll see a wallpaper_cmd key, the given command is executed when {{ic|beautiful.init}}("path_to_theme_file") is run. You can put here you own command or remove/comment the key if you do not want Beautiful to interfere with your wallpaper business.<br />
<br />
For instance, if you use {{ic|awsetbg}} to set your wallpaper, you can write in the {{ic|theme.lua}} page that you just selected:<br />
<br />
theme.wallpaper_cmd = { "awsetbg -f .config/awesome/themes/awesome-wallpaper.png" }<br />
<br />
{{Note|For awsetbg to work you need to have a program that can manage desktop backgrounds installed. For example '''[[Feh]]'''.}}<br />
<br />
====Random Background Image====<br />
<br />
add this to your {{ic|rc.lua}}(for awesome >= 3.5 ):<br />
{{bc|1=<br />
-- configuration - edit to your liking<br />
wp_index = 1<br />
wp_timeout = 10<br />
wp_path = "/path/to/wallpapers/"<br />
wp_files = { "01.jpg", "02.jpg", "03.jpg" }<br />
<br />
-- setup the timer<br />
wp_timer = timer { timeout = wp_timeout }<br />
wp_timer:connect_signal("timeout", function()<br />
<br />
-- set wallpaper to current index<br />
gears.wallpaper.maximized( wp_path .. wp_files[wp_index] , s, true)<br />
<br />
-- stop the timer (we don't need multiple instances running at the same time)<br />
wp_timer:stop()<br />
<br />
-- get next random index<br />
wp_index = math.random( 1, #wp_files)<br />
<br />
--restart the timer<br />
wp_timer.timeout = wp_timeout<br />
wp_timer:start()<br />
end)<br />
<br />
-- initial start when rc.lua is first run<br />
wp_timer:start()<br />
}}<br />
<br />
To rotate the wallpapers randomly, just comment the {{ic|wallpaper_cmd}} line above, and add a script into your {{ic|.xinitrc}} with the codes below(for awesome <= 3.4 ):<br />
{{bc|<br />
while true;<br />
do<br />
awsetbg -r <path/to/the/directory/of/your/wallpapers><br />
sleep 15m<br />
done &<br />
}}<br />
<br />
==Tips & Tricks==<br />
Feel free to add any tips or tricks that you would like to pass on to other awesome users.<br />
<br />
===Use awesome as GNOME's window manager===<br />
GNOME has the advantage of being very "ready to use" and integrating. You can set up GNOME to use awesome as the visual interface, but have GNOME work in the background for your pleasure. If you are using GNOME 3, you can simply install the [https://aur.archlinux.org/packages.php?ID=53096 awesome-gnome] package, then when logging in with GDM, choose the session type "Awesome GNOME". See the [http://awesome.naquadah.org/wiki/Quickly_Setting_up_Awesome_with_Gnome awesome wiki] for details.<br />
<br />
===Expose effect like compiz===<br />
{{out of date | Revelation has been marked as deprecated in the awesome wiki and the repository may be deleted at any time.}}<br />
Revelation brings up a view of all your open clients; left-clicking a client pops to the first tag that client is visible on and raises/focuses the client. In addition, the Enter key pops to the currently focused client, and Escape aborts. <br />
<br />
http://awesome.naquadah.org/wiki/Revelation<br />
<br />
===Hide / show wibox in awesome 3===<br />
<br />
To map Modkey-b to hide/show default statusbar on active screen (as default in awesome 2.3), add to your ''globalkeys'' in rc.lua:<br />
<br />
awful.key({ modkey }, "b", function ()<br />
mywibox[mouse.screen].visible = not mywibox[mouse.screen].visible<br />
end),<br />
<br />
===Enable printscreens===<br />
<br />
To enable printscreens in awesome through the PrtScr button you need to have a screen capturing program.<br />
Scrot is a easy to use utility for this purpose and is available in Arch repositories.<br />
<br />
Just type:<br />
# pacman -S scrot<br />
<br />
and install optional dependencies if you feel that you need them.<br />
<br />
Next of we need to get the key name for PrtScr, most often this is named "Print" but one can never be too sure.<br />
<br />
Start up:<br />
# xev<br />
<br />
And press the PrtScr button, the output should be something like:<br />
KeyPress event ....<br />
root 0x25c, subw 0x0, ...<br />
state 0x0, keycode 107 (keysym 0xff61, '''Print'''), same_screen YES,<br />
....<br />
<br />
In my case as you see, the keyname is Print.<br />
<br />
Now to the configuration of awesome!<br />
<br />
Somewhere in your globalkeys array (doesn't matter where) type:<br />
<br />
Lua code:<br />
<br />
awful.key({ }, "Print", function () awful.util.spawn("scrot -e 'mv $f ~/screenshots/ 2>/dev/null'") end),<br />
<br />
Also, this function saves screenshots inside ~/screenshots/, edit this to fit your needs.<br />
<br />
===Dynamic tagging===<br />
<br />
[http://awesome.naquadah.org/wiki/Eminent Eminent] is a small lua library that monkey-patches awful to provide you with effortless and quick wmii-style dynamic tagging. Unlike shifty, eminent does not aim to provide a comprehensive tagging system, but tries to make dynamic tagging as simple as possible. In fact, besides importing the eminent library, you do not have to change your rc.lua at all, eminent does all the work for you.<br />
<br />
[http://awesome.naquadah.org/wiki/Shifty Shifty] is an Awesome 3 extension that implements dynamic tagging. It also implements fine client matching configuration allowing YOU to be the master of YOUR desktop only by setting two simple config variables and some keybindings!<br />
<br />
===Space Invaders===<br />
[http://awesome.naquadah.org/wiki/Space_Invaders Space Invaders] is a demo to show the possibilities of the Awesome Lua API.<br />
<br />
Please note that it is no longer included in the Awesome package since the 3.4-rc1 release.<br />
<br />
===Naughty for popup notification===<br />
See [http://awesome.naquadah.org/wiki/Naughty the awesome wiki page on naughty].<br />
<br />
===Popup Menus===<br />
There's a simple menu by default in awesome3, and customed menus seem very easy now. However, if you're using 2.x awesome, have a look at ''[http://awesome.naquadah.org/wiki/Awful.menu awful.menu]''.<br />
<br />
If you want a freedesktop.org menu, you could take a look at ''[https://github.com/terceiro/awesome-freedesktop awesome-freedesktop]'' .<br />
<br />
An example for awesome3:<br />
{{bc|1=<br />
myawesomemenu = {<br />
{ "lock", "xscreensaver-command -activate" },<br />
{ "manual", terminal .. " -e man awesome" },<br />
{ "edit config", editor_cmd .. " " .. awful.util.getdir("config") .. "/rc.lua" },<br />
{ "restart", awesome.restart },<br />
{ "quit", awesome.quit }<br />
}<br />
<br />
mycommons = {<br />
{ "pidgin", "pidgin" },<br />
{ "OpenOffice", "soffice-dev" },<br />
{ "Graphic", "gimp" }<br />
}<br />
<br />
mymainmenu = awful.menu.new({ items = { <br />
{ "terminal", terminal },<br />
{ "icecat", "icecat" },<br />
{ "Editor", "gvim" },<br />
{ "File Manager", "pcmanfm" },<br />
{ "VirtualBox", "VirtualBox" },<br />
{ "Common App", mycommons, beautiful.awesome_icon },<br />
{ "awesome", myawesomemenu, beautiful.awesome_icon }<br />
}<br />
})<br />
}}<br />
<br />
===More Widgets in awesome===<br />
''Widgets in awesome are objects that you can add to any widget-box (statusbars and titlebars), they can provide various information about your system, and are useful for having access to this information, right from your window manager. Widgets are simple to use and offer a great deal of flexibility.'' -- Source [http://awesome.naquadah.org/wiki/Widgets_in_awesome Awesome Wiki: Widgets].<br />
<br />
There's a widely used widget library called '''Wicked''' (compatible with awesome versions '''prior to 3.4'''), that provides more widgets, like MPD widget, CPU usage, memory usage, etc. For more details see the [http://awesome.naquadah.org/wiki/Wicked Wicked page].<br />
<br />
As a replacement for Wicked in awesome v3.4 check '''[http://awesome.naquadah.org/wiki/Vicious Vicious]''', '''[http://awesome.naquadah.org/wiki/Obvious Obvious]''' and '''[http://awesome.naquadah.org/wiki/Bashets Bashets]'''. If you pick vicious, you should also take a good look at [http://git.sysphere.org/vicious/tree/README vicious documentation].<br />
<br />
===Transparency===<br />
Awesome has support for true transparency through a [[Xorg#Composite | compositing manager]] such as {{Pkg|xcompmgr}}({{AUR|xcompmgr-git}}), compton({{AUR|compton-git}}) or {{AUR|cairo-compmgr-git}}.<br />
<br />
To use xcompmgr, add this to your {{ic|~/.xinitrc}}:<br />
xcompmgr &<br />
See ''man xcompmgr'' or [[xcompmgr]] for more options.<br />
<br />
{{out of date | Awesome 3.5 has come and add_signal API has changed to connect_signal}}<br />
In awesome 3.4, window transparency can be set dynamically using signals. For example, your rc.lua could contain the following:<br />
<br />
client.add_signal("focus", function(c)<br />
c.border_color = beautiful.border_focus<br />
c.opacity = 1<br />
end)<br />
client.add_signal("unfocus", function(c)<br />
c.border_color = beautiful.border_normal<br />
c.opacity = 0.7<br />
end)<br />
'''If you got error messages about add_signal, use connect_signal instead.''' <br />
<br />
Note that if you are using conky, you must set it to create its own window instead of using the desktop. To do so, edit ~/.conkyrc to contain:<br />
<br />
own_window yes<br />
own_window_transparent yes<br />
own_window_type desktop<br />
<br />
Otherwise strange behavior may be observed, such as all windows becoming fully transparent. Note also that since conky will be creating a transparent window on your desktop, any actions defined in awesome's rc.lua for the desktop will not work where conky is.<br />
<br />
As of Awesome 3.1, there is built-in pseudo-transparency for wiboxes. To enable it, append 2 hexadecimal digits to the colors in your theme file (~/.config/awesome/themes/default, which is usually a copy of /usr/share/awesome/themes/default), like shown here:<br />
<br />
bg_normal = #000000AA<br />
<br />
where "AA" is the transparency value.<br />
<br />
To change transparency for the actual selected window by pressing Modkey + PageUp/PageDown you can also use tansset-df available through the community package repository and the following modification to your rc.lua:<br />
<br />
globalkeys = awful.util.table.join(<br />
-- your keybindings<br />
[...]<br />
awful.key({ modkey }, "Next", function (c)<br />
awful.util.spawn("transset-df --actual --inc 0.1")<br />
end),<br />
awful.key({ modkey }, "Prior", function (c)<br />
awful.util.spawn("transset-df --actual --dec 0.1")<br />
end),<br />
-- Your other key bindings<br />
[...]<br />
)<br />
<br />
==== ImageMagick ====<br />
You may have problems if you set your wallpaper with imagemagick's ''display'' command, it doesn't work well with xcompmgr. Please note that awsetbg may be using ''display'' if it doesn't have any other options. Installing habak, feh, hsetroot or whatever should fix the problem (''grep -A 1 wpsetters /usr/bin/awsetbg'' to see your options).<br />
<br />
===Autorun programs===<br />
''See also [https://awesome.naquadah.org/wiki/Autostart the Autostart page on the Awesome wiki].''<br />
<br />
awesome doesn't run programs set to autostart by the Freedesktop specification like GNOME or KDE. However, awesome does provide a few functions for starting programs (in addition to the Lua standard library function {{Ic|os.execute}}). To run the same programs on startup as GNOME or KDE, you can install [https://aur.archlinux.org/packages.php?ID=41099 dex] from the [[AUR]] and then run that in your rc.lua:<br />
<br />
os.execute"dex -a -e Awesome"<br />
<br />
If you just want to set up a list of apps for awesome to launch at startup, you can create a table of all the commands you want to spawn and loop through it:<br />
<br />
do<br />
local cmds = <br />
{ <br />
"swiftfox",<br />
"mutt",<br />
"consonance",<br />
"linux-fetion",<br />
"weechat-curses",<br />
--and so on...<br />
}<br />
<br />
for _,i in pairs(cmds) do<br />
awful.util.spawn(i)<br />
end<br />
end<br />
<br />
(You could also run calls to {{Ic|os.execute}} with commands ending in '{{Ic|&}}', but it's probably a better idea to stick to the proper spawn function.)<br />
<br />
To run a program only if it is not currently running, you can spawn it with a shell command that runs the program only if {{Ic|pgrep}} doesn't find a running process with the same name:<br />
function run_once(prg)<br />
awful.util.spawn_with_shell("pgrep -u $USER -x " .. prg .. " || (" .. prg .. ")")<br />
end<br />
<br />
So, for example, to run {{Ic|parcellite}} only if there is not a {{Ic|parcellite}} process already running:<br />
<br />
run_once("parcellite")<br />
<br />
===Passing content to widgets with awesome-client===<br />
<br />
You can easily send text to an awesome widget. Just create a new widget:<br />
{{bc|<nowiki><br />
mywidget = widget({ type = "textbox", name = "mywidget" })<br />
mywidget.text = "initial text"<br />
</nowiki>}}<br />
To update the text from an external source, use awesome-client:<br />
{{bc|<nowiki> <br />
echo -e 'mywidget.text = "new text"' | awesome-client<br />
</nowiki>}}<br />
Don't forget to add the widget to your wibox.<br />
<br />
===Using a different panel with awesome===<br />
<br />
If you like awesome's lightweightness and functionality but do not like the way its default panel looks, you can install a different panel. Just install xfce4-panel by issuing:<br />
{{bc|<br />
sudo pacman -S xfce4-panel<br />
}}<br />
Of course any other panel will do as well. <br />
Then add it to autorun section of your rc.lua (how to do that is written elsewhere on this wiki). You can also comment out the section which creates wiboxes for each screen (starting from "mywibox[s] = awful.wibox({ position = "top", screen = s })" ) but it isn't necessary. Any way do not forget to check your rc.lua for errors by typing <br />
{{bc|<br />
awesome -k rc.lua<br />
}}<br />
Also you should change your "modkey+R" keybinding, in order to start some other application launcher instead of built in awesome. Xfrun4, bashrun, etc. Check the Application launchers section of [[Openbox_Themes_and_Apps#Application_launchers|Openbox]] article for examples. Don't forget to add<br />
{{bc|<nowiki><br />
properties = { floating = true } },<br />
{ rule = { instance = "$yourapplicationlauncher" },<br />
</nowiki>}}<br />
to your rc.lua.<br />
<br />
===Fix Java (GUI appears gray only)===<br />
Guide taken from [https://bbs.archlinux.org/viewtopic.php?pid=450870].<br />
#Install {{Pkg|wmname}} from community<br />
#Run the following command or add it to your {{ic|.xinitrc}}: {{bc|wmname LG3D}}<br />
<br />
{{Note|<br />
If you use a non-reparenting window manager and Java 6, you should uncomment the corresponding line in {{Ic|/etc/profile.d/openjdk6.sh}}<br />
<br />
If you use a non-reparenting window manager and Java 7, you should uncomment the corresponding line in <br />
{{Ic|/etc/profile.d/jre.sh}} <br />
}}<br />
<br />
===Prevent Nautilus from displaying the desktop (Gnome3)===<br />
Run dconf-editor. Navigate to org->gnome->desktop->background and uncheck "draw-background" as well as "show-desktop-icons" for good measure. That's it!<br />
<br />
Another option is moving /usr/bin/nautilus to a new location and replacing it with a script that runs 'nautilus --no-desktop' passing any arguments it receives along.<br />
<br />
#!/bin/sh<br />
/usr/bin/nautilus-real --no-desktop $@<br />
<br />
===Transitioning away from Gnome3===<br />
Run 'gnome-session-properties' and remove programs that you won't be needing anymore (e.g Bluetooth Manager, Login Sounds, etc).<br />
<br />
If you'd like to get rid of GDM, make sure that your rc.conf DAEMONS list includes "dbus" (and "cupsd" if you have a printer). It's advisable to get a different login manager (like [https://wiki.archlinux.org/index.php/SLiM SLiM]), but you can do things manually if you wish. That entails setting up your [https://wiki.archlinux.org/index.php/Udev .xinitrc properly] and installing something like devmon ([https://aur.archlinux.org/packages.php?ID=45842 AUR]).<br />
<br />
If you want to keep a few convenient systray applets and your GTK theme, append this to your rc.lua;<br />
function start_daemon(dae)<br />
daeCheck = os.execute("ps -eF | grep -v grep | grep -w " .. dae)<br />
if (daeCheck ~= 0) then<br />
os.execute(dae .. " &")<br />
end<br />
end<br />
<br />
procs = {"gnome-settings-daemon", "nm-applet", "kupfer", "gnome-sound-applet", "gnome-power-manager"}<br />
for k = 1, #procs do<br />
start_daemon(procs[k])<br />
end<br />
<br />
===Prevent the mouse scroll wheel from changing tags===<br />
In your rc.lua, change the Mouse Bindings section to the following;<br />
-- {{{ Mouse bindings<br />
root.buttons(awful.util.table.join(<br />
awful.button({ }, 3, function () mymainmenu:toggle() end)))<br />
-- }}}<br />
<br />
==Troubleshooting==<br />
<br />
===LibreOffice===<br />
If you encounter UI problems with libreoffice install libreoffice-gnome.<br />
<br />
===Mod4 key===<br />
<br />
The Mod4 is by default the '''Win key'''. If it's not mapped by default, for some reason, you can check the keycode of your Mod4 key with<br />
<br />
$ xev<br />
<br />
It should be 115 for the left one. Then add this to your ~/.xinitrc<br />
<br />
xmodmap -e "keycode 115 = Super_L" -e "add mod4 = Super_L"<br />
exec awesome<br />
<br />
The problem in this case is that some xorg installations recognize keycode 115, but incorrectly as the 'Select' key. The above command explictly remaps keycode 115 to the correct 'Super_L' key.<br />
<br />
====Mod4 key vs. IBM ThinkPad users====<br />
<br />
IBM ThinkPads do not come equipped with a Window key (although Lenovo have changed this tradition on their ThinkPads). As of writing, the Alt key is not used in command combinations by the default rc.lua (refer to the Awesome wiki for a table of commands), which allows it be used as a replacement for the Super/Mod4/Win key. To do this, edit your rc.lua and replace:<br />
<br />
modkey = "Mod4"<br />
<br />
by:<br />
<br />
modkey = "Mod1"<br />
<br />
Note: Awesome does a have a few commands that make use of Mod4 plus a single letter. Changing Mod4 to Mod1/Alt could cause overlaps for some key combinations. The small amount of instances where this happens can be changed in the rc.lua file.<br />
<br />
If you do not like to change the awesome standards, you might like to remap a key. For instance the caps lock key is rather useless (for me) adding the following contents to ~/.Xmodmap <br />
<br />
clear lock <br />
add mod4 = Caps_Lock<br />
<br />
and [[Extra Keyboard Keys in Xorg#Step 2: Testing|(re)load]] the file.<br />
This will change the caps lock key into the mod4 key and works nicely with the standard awesome settings. In addition, if needed, it provides the mod4 key to other X-programs as well.<br />
<br />
Not confirmed, but if recent updates of xorg related packages break mentioned remapping the second line can be replaced by (tested on a DasKeyboard with no left Super key):<br />
<br />
keysym Caps_Lock = Super_L Caps_Lock<br />
<br />
===Eclipse: cannot resize/move main window===<br />
If you get stuck and cannot move or resize the main window (using mod4 + left/right mouse button) edit the workbench.xml and set fullscreen/maximized to false (if set) and reduce the width and height to numbers smaller than your single screen desktop area.<br />
{{Note|workbench.xml can be found in: <eclipse_workspace>/.metadata/.plugins/org.eclipse.ui.workbench/ and the line to edit is <window height&#61;"xx" maximized&#61;"true" width&#61;"xx" x&#61;"xx" y&#61;"xx">.}}<br />
<br />
===YouTube: fullscreen appears in background===<br />
[https://bbs.archlinux.org/viewtopic.php?pid=1085494#p1085494] If YouTube videos appear underneath your web browser when in fullscreen mode, or underneath the panel with controls hidden, add this to your rc.lua<br />
<br />
{ rule = { instance = "plugin-container" },<br />
properties = { floating = true } },<br />
<br />
With Chromium add<br />
<br />
{ rule = { instance = "exe" },<br />
properties = { floating = true } },<br />
<br />
===Starting console clients on specific tags===<br />
It does not work when the console application is invoked from a GTK terminal (e.g. LXTerminal). [[URxvt]] is known to work. <br />
<br />
===Redirecting console output to a file===<br />
Some GUI application are very verbose when launched from a terminal. As a consequence, when started from Awesome, they output everything to the TTY from where Awesome was started, which tend to get messy. To remove the garbage output, you have to redirect it. However, the {{ic|awful.util.spawn}} function does not handle pipes and redirections very well as stated in [http://awesome.naquadah.org/wiki/FAQ#How_to_execute_a_shell_command.3F the official FAQ].<br />
<br />
As example, let's redirect [[Luakit]] output to a temporary file:<br />
<br />
awful.key({ modkey, }, "w", function () awful.util.spawn_with_shell("luakit 2>>/tmp/luakit.log") end),<br />
<br />
==External Links==<br />
* http://awesome.naquadah.org/wiki/FAQ - FAQ<br />
* http://www.lua.org/pil/ - Programming in Lua (first edition)<br />
* http://awesome.naquadah.org/ - The official awesome website<br />
* http://awesome.naquadah.org/wiki/Main_Page - the awesome wiki<br />
* http://www.penguinsightings.org/desktop/awesome/ - A review<br />
* http://compsoc.tardis.ed.ac.uk/wiki/AwesomeWM_guide - Awesome guide<br />
* https://bbs.archlinux.org/viewtopic.php?id=88926 - share your awesome!</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=Stalonetray&diff=263141Stalonetray2013-06-17T19:30:08Z<p>Txus.palacios: awesome recommends Stalonetray, so it works well with that WM.</p>
<hr />
<div>[[Category:X Server]]<br />
Stalonetray is a stand-alone freedesktop.org and KDE system tray for the [[Xorg|X Window System]]. It has full XEMBED support, minimal dependencies and works with virtually any EWMH-compliant window manager. Window managers that are reported to work well with stalonetray are: [[FVWM]], [[Openbox]], [[Enlightenment]], [[Ion3]], [[Compiz]], [[Xmonad]] and [[awesome]].<br />
<br />
== Installation ==<br />
Stalonetray is available from the community repository:<br />
<br />
# pacman -S stalonetray<br />
<br />
Once installed, copy the {{ic|stalonetrayrc}} file to your home directory. Note that you should do this as a regular user.<br />
<br />
$ cp /etc/stalonetrayrc ~/.stalonetrayrc<br />
<br />
== Configuration ==<br />
=== Openbox ===<br />
<br />
To run stalonetray in Openbox, you need to run:<br />
# stalonetray --dockapp-mode simple<br />
<br />
Alternatively, you can change the line:<br />
<br />
# dockapp-mode none <br />
<br />
to<br />
<br />
# dockapp-mode simple <br />
<br />
in your {{ic|.stalonetrayrc}} file. Openbox now treats the tray as the dock, and you can adjust its position by using the Openbox Configuration Tool.<br />
<br />
To run Stalonetray on start up, add the following to {{ic|~/.config/openbox/autostart}}: <br />
stalonetray &<br />
<br />
If the dockapp-mode is not specified in {{ic|~/.stalonetrayrc}}, add the following instead:<br />
stalonetray --dockapp-mode simple &<br />
<br />
See also [http://stalonetray.sourceforge.net/wmhints.html#openbox Stalonetray WM hints for OpenBox]<br />
<br />
=== Ion3 ===<br />
<br />
To run stalonetray in Ion3:<br />
stalonetray --kludges=force_icons_size,fix_window_pos<br />
To include stalonetray in the statusbar, add the following to your configuration file in {{ic|~/.ion3/}} :<br />
<pre><br />
-- Create a statusbar<br />
mod_statusbar.create{<br />
screen=0,<br />
pos='bl',<br />
fullsize=true,<br />
systray=true,<br />
template="[ %date || %load || ... ] %systray%filler%systray_stalone",<br />
}<br />
<br />
defwinprop{class="stalonetray",instance="stalonetray",statusbar="systray_stalone"}<br />
defwinprop{instance="stalonetray",statusbar="systray_stalone"}<br />
defwinprop{class="stalonetray",statusbar="systray_stalone"}<br />
</pre><br />
<br />
See also [http://stalonetray.sourceforge.net/wmhints.html#ion3 Stalonetray WM hints for ion3]<br />
<br />
==Other resources==<br />
* [http://stalonetray.sourceforge.net/manpage.html stalonetray man page]</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=Ranger_File_Manger&diff=262209Ranger File Manger2013-06-10T14:10:56Z<p>Txus.palacios: Double redirect fixed.</p>
<hr />
<div>#REDIRECT [[Ranger]]</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=Ranger_File_Manger&diff=262208Ranger File Manger2013-06-10T14:10:34Z<p>Txus.palacios: Why does this link to a laptop page? - I think this page should be deleted.</p>
<hr />
<div>#REDIRECT [[Ranger File Manager]]</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=Polipo&diff=261544Polipo2013-06-06T17:55:52Z<p>Txus.palacios: /* DNS Error */</p>
<hr />
<div>[[Category:Proxy servers]]<br />
[[zh-CN:Polipo]]<br />
{{Article summary start}}<br />
{{Article summary text|Polipo is a light weight http proxy server for your small network. Polipo caches web data.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Squid}}<br />
{{Article summary end}}<br />
<br />
From [http://www.pps.jussieu.fr/~jch/software/polipo/ Polipo's site]:<br />
<br />
:"''Polipo is a small and fast caching web proxy (a web cache, an HTTP proxy, a proxy server). While Polipo was designed to be used by one person or a small group of people, there is nothing that prevents it from being used by a larger group.''"<br />
<br />
Unlike [[Squid]], Polipo is very light on resources and simple to configure. This makes it ideal for single user systems and other uncomplicated setups. Do keep in mind; however, that this versatility comes at a cost; Polipo will increase its space usage without restriction as it is not aware of how big its disk cache grows. This perceived fault is by design, since omitting these sanity checks drastically reduces Polipo's memory usage and overall toll on the system. A practical way of restricting disk usage is by making Polipo run as its own user and employing [[disk quota]].<br />
<br />
The following covers installing and setting up Polipo.<br />
<br />
== Installation ==<br />
<br />
Install {{Pkg|polipo}}, available in the [[Official Repositories]].<br />
<br />
Alternatively, install the newer development branch {{aur|polipo-git}} from the [[AUR]] instead.<br />
<br />
=== Run polipo as different user (not nobody) ===<br />
<br />
Polipo should run as an unprivileged user. Such a user can either be created or reused. Lets create the polipo cache folder first<br />
<br />
# mkdir /var/cache/polipo<br />
<br />
Now we add the new polipo group<br />
<br />
# groupadd -r polipo<br />
<br />
and we add the new polipo user afterwards to this group<br />
<br />
# useradd -d /var/cache/polipo -g polipo -r -s /bin/false polipo<br />
<br />
then we need a new polipo logfile which is assigned to the upper user and group<br />
<br />
# touch /var/log/polipo.log<br />
# chown -R polipo:polipo /var/log/polipo.log /var/cache/polipo<br />
<br />
To change user running polipo daemon, we have to create another {{ic|polipo.service}} file<br />
<br />
# touch /etc/systemd/system/polipo.service<br />
<br />
Copy the following code section to the new {{ic|/etc/systemd/system/polipo.service}} file<br />
<br />
.include /usr/lib/systemd/system/polipo.service<br />
[Service]<br />
User=polipo<br />
<br />
To make sure all files and folders are created before you start Polipo as a designated user. Restart Polipo and check its logfile.<br />
<br />
# systemctl restart polipo<br />
# tail /var/log/polipo.log<br />
<br />
If everything went well you should read something like this<br />
<br />
Established listening socket on port 8123.<br />
<br />
Also check, if polipo is running as polipo user:<br />
<br />
# ps aux | grep polipo<br />
<br />
Stop the polipo daemon<br />
<br />
# systemctl stop polipo<br />
<br />
== Starting the daemon ==<br />
<br />
To start the polipo daemon:<br />
<br />
# systemctl start polipo<br />
<br />
To start it automatically at boot:<br />
<br />
# systemctl enable polipo<br />
<br />
=== Multiple instances ===<br />
<br />
Polipo can also run without super user privileges. To do so, first copy {{ic|/etc/polipo/config.sample}} to a suitable directory:<br />
<br />
$ cp /etc/polipo/config.sample ~/.poliporc<br />
<br />
Edit it so that it points at a writable location, instead of {{ic|/var/cache/polipo}}:<br />
<br />
# Uncomment this if you want to put the on-disk cache in a<br />
# non-standard location:<br />
diskCacheRoot = "~/.polipo-cache/"<br />
<br />
Create the cache directory:<br />
<br />
$ mkdir ~/.polipo-cache<br />
<br />
Finally, launch Polipo with the new configuration:<br />
<br />
$ polipo -c ~/.poliporc<br />
<br />
== Configuration ==<br />
<br />
Management is mostly performed in {{ic|/etc/polipo/config}}. Most users can opt for using the sample configuration file, which is sufficient for most situations and well documented.<br />
<br />
# cd /etc/polipo; cp config.sample config<br />
<br />
One element of configuration that warrants mentioning is polipo's default behavior of blocking outbound connections by port. There are two variables in polipo's config file that control allowed outbound ports. {{Ic|allowedPorts}} specifies ports for outbound HTTP connections. It defaults to 80-100 and 1024-65535. {{Ic|tunnelAllowedPorts}} specifies ports polipo will allow tunnel traffic to as well as HTTPS traffic. By default it is much more restricted: "''It defaults to allowing ssh, HTTP, https, rsync, IMAP, imaps, POP, pops, Jabber, CVS and Git traffic.''"<br />
<br />
If you see a "403 Forbidden Port" error message from polipo when attempting to browse to a host:port, you need to configure polipo to accept traffic to more ports for either HTTP or HTTPS. To set them wide open, add the following to {{ic|/etc/polipo/config}}:<br />
<br />
allowedPorts = 1-65535<br />
tunnelAllowedPorts = 1-65535<br />
<br />
Unlike other proxies, Polipo needs to be restarted after alterations.<br />
<br />
=== Browser ===<br />
<br />
Set the browser so that it uses {{Ic|localhost:8123}} for proxying. Be sure to disable the browser's disk cache to avoid redundant IO operations and bad performance.<br />
<br />
=== Tunneling ===<br />
<br />
{{note|According to the [http://www.pps.jussieu.fr/~jch/software/polipo/faq.html Polipo FAQ] on "intercepting proxy" this is not possible/supported!}}<br />
<br />
{{note|this requires to run Polipo as its own user.}}<br />
<br />
Instead of manually configuring each browser or other utilities that might benefit from Polipo's caching, one can also use [[iptables]] to route traffic through polipo.<br />
<br />
After installing iptables, add the appropiate rules to {{ic|/etc/iptables/iptables.rules}}:<br />
<br />
*nat<br />
:PREROUTING ACCEPT [0:0]<br />
:POSTROUTING ACCEPT [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
''-A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner polipo -j ACCEPT''<br />
''-A OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 8123''<br />
COMMIT<br />
<br />
This routes HTTP traffic through Polipo. Remove all proxy settings from browsers, if any, and restart iptables.<br />
<br />
=== Privoxy ===<br />
<br />
[[Privoxy]] is a proxy useful for intercepting advertisement and other undesirables.<br />
<br />
According to Polipo's developer, in order to get the privacy enhancements of Privoxy and much (but not all) of the performance of Polipo, one should place Polipo upstream of Privoxy.<br />
<br />
In other words:<br />
<br />
* point the browser at Privoxy: {{Ic|localhost:8118}}<br />
<br />
* and direct Privoxy traffic to Polipo: {{Ic|forward / localhost:8123}} in the Privoxy configuration file.<br />
<br />
=== Tor ===<br />
<br />
[[Tor]] is an anonymizing proxy network.<br />
<br />
To use Polipo with Tor, uncomment or include the following in {{Ic|/etc/polipo/config}}:<br />
<br />
socksParentProxy = localhost:9050<br />
socksProxyType = socks5<br />
<br />
=== DansGuardian ===<br />
<br />
[[DansGuardian]] is a web content filter. The only difference to using [[DansGuardian]] with Polipo (rather than squid or tinyproxy) is that in {{ic|dansguardian.conf}} the proxyport needs to be set to polipo's 8123:<br />
<br />
# the port DansGuardian connects to proxy on<br />
proxyport = 8123<br />
<br />
== Troubleshooting ==<br />
<br />
=== DNS Error ===<br />
<br />
If the network is started in background there could be a error like this in the Polipo log file:<br />
<br />
Couldn't send DNS query: Connection refused<br />
Falling back on gethostbyname.<br />
Getaddrinfo failed: Temporary name server failure<br />
Host ***.com lookup failed: Getaddrinfo failed: Temporary name server failure (131072).<br />
<br />
This error occurs because in background mode the network hasn't initialised before Polipo wants to connect to the DNS server (especially using DHCP). Solving this error is possible on three ways:<br />
<br />
* Do not start the net-profiles in background mode (probably not wanted).<br />
* Set {{ic|dnsNameServer}} manually on the wanted DNS server.<br />
* Or add {{ic|sleep 10}} (or more, it depends) near the beginning of the Polipo daemon script {{ic|/etc/rc.d/polipo}} in the start section. This will make Polipo start after the network has initialised.<br />
<br />
See [https://bbs.archlinux.org/viewtopic.php?id=86452 this thread] for more information on this topic.<br />
<br />
== See also ==<br />
<br />
*[http://www.pps.jussieu.fr/~jch/software/polipo/faq.html Polipo FAQ]<br />
*[http://www.pps.jussieu.fr/~jch/software/polipo/manual/index.html The Polipo Manual]</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=I3&diff=261543I32013-06-06T17:44:25Z<p>Txus.palacios: Improved the installation section.</p>
<hr />
<div>{{DISPLAYTITLE:i3}}<br />
[[Category:Tiling WMs]]<br />
[[Category:Dynamic WMs]]<br />
[[ko:i3]]<br />
[[ru:i3]]<br />
[[zh-CN:i3]]<br />
[http://i3wm.org/ i3] is a dynamic [[Wikipedia:Tiling window manager|tiling window manager]] inspired by [[wmii]] that is primarily targeted at developers and advanced users.<br />
<br />
Clients (windows) are organized in a tree data structure within containers. The tree branches via horizontal or vertical splits, and containers can also be set to tabbed or stacked layouts. Floating windows are available for corner cases that don't mix well with tiling, and remain on a separate layer above the tiled windows.<br />
<br />
== Installation ==<br />
Install the {{Pkg|i3}} [[Pacman#Installing package groups|package group]] from the [[official repositories]], which includes: {{Pkg|i3wm}}, the window manager; {{Pkg|i3status}}, a package to write a status line to i3bar through [[Wikipedia:Standard streams#Standard output (stdout)|stdout]]; and {{Pkg|i3lock}}, an improved screenlocker.<br />
<br />
Additional packages are available in the [[Arch User Repository]]. Install {{AUR|i3-git}} for the development version. Install {{AUR|i3-gnome}} to add a [[GNOME]]-session.<br />
<br />
== Configuration ==<br />
<br />
Edit your {{ic|~/.xinitrc}} and add:<br />
exec i3<br />
If you want i3 to log its output (useful for debugging), add this line to {{ic|~/.xinitrc}}:<br />
exec i3 -V >> ~/.i3/i3log 2>&1<br />
If you use the Nvidia binary driver '''<302.17''' you need to add the --force-xinerama flag to {{ic|~/.xinitrc}}. A detailed explanation can be found at [http://i3wm.org/docs/multi-monitor.html i3wm.org].<br />
exec i3 --force-xinerama<br />
<br />
=== Status bar ===<br />
The internal status bar, i3-''ws''bar, was deprecated and replaced by i3bar in i3 v4.0.<br />
<br />
==== New method: i3bar ====<br />
Unlike i3-wsbar, which requires dzen2, i3bar does not have any dependencies other than {{Pkg|i3-wm}}. It can be used to view information generated by [[conky]] or i3status. For example (as of version 4.1):<br />
{{hc|~/.i3/config|<nowiki><br />
bar {<br />
output LVDS1<br />
status_command i3status<br />
position top<br />
mode hide<br />
workspace_buttons yes<br />
tray_output none<br />
<br />
font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1<br />
<br />
colors {<br />
background #000000<br />
statusline #ffffff<br />
<br />
focused_workspace #ffffff #285577<br />
active_workspace #ffffff #333333<br />
inactive_workspace #888888 #222222<br />
urgent_workspace #ffffff #900000<br />
}<br />
}<br />
</nowiki>}}<br />
<br />
For further information see the [http://i3wm.org/docs/userguide.html#_configuring_i3bar Configuring i3bar] section of the official User Guide.<br />
<br />
==== Comparison of i3bar and dzen2 ====<br />
This comparison of i3bar and dzen2 only takes into account how well the two programs can handle the input from conky or i3status.<br />
{| border="1" cellpadding="5" align="center"<br />
! Program !! Color Codes !! Formatting !! Special Fonts !! Dock !! Trayer<br />
|-<br />
| i3bar || Yes || No, right aligned || No (UTF8 only)|| Yes || Yes<br />
|-<br />
| dzen2 || Yes || No, left aligned || Yes || Yes (the svn version) || No<br />
|-<br />
|}<br />
<br />
Though development of i3bar is very active and support for custom formatting and fonts has been announced, dzen2-svn has an edge over i3bar (as of August 7th).<br />
<br />
==== Alternatives ====<br />
* [https://github.com/enkore/i3pystatus i3pystatus] - extensible i3status replacement with many modules and very flexible configuration. Multi-threaded and lock-up free.<br />
* [https://github.com/ultrabug/py3status py3status] – an extensible i3status wrapper written in python<br />
<br />
=== Quickly jumping to open window ===<br />
* [https://github.com/proxypoke/quickswitch-for-i3 quickswitch-for-i3] – A Python utility to quickly change to and locate windows in i3<br />
* [https://github.com/yiuin/i3-wm-scripts i3-wm-scripts] – search for and jump to windows with particular names matching regexp<br />
* [https://github.com/ziberna/i3-py/tree/master/examples#winmenupy winmenupy] launches dmenu with a list of clients, sorted after workspaces. Selecting a client jumps to that window.<br />
<br />
== Suspending with i3lock ==<br />
You need to add unit file below and enable it with {{ic|# systemctl enable suspend@<user>.service}}.<br />
<br />
{{hc|/etc/systemd/system/suspend@.service|2=<nowiki><br />
[Unit]<br />
Description=Starts i3lock at suspend time<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStartPre= <br />
ExecStart=/usr/bin/i3lock<br />
<br />
[Install]<br />
WantedBy=sleep.target</nowiki>}}<br />
<br />
== Usage ==<br />
{{Box BLUE||See the [http://i3wm.org/docs official documentation] on this subject for more information: [http://i3wm.org/docs/userguide.html i3 User’s Guide]}}<br />
<br />
i3 currently uses [[dmenu]] as a application launcher, which is bound by default to {{Keypress|Mod1|background=#FF0}}+{{Keypress|d}}.<br />
<br />
=== Clipboard (copy & paste issues) ===<br />
<br />
By default, when you close a window, the buffer with the clipboard info will disappear. You have to use a clipboard manager like {{Pkg|clipit}} to avoid that.<br />
<br />
== See also ==<br />
* [[Comparison of Tiling Window Managers]]<br />
* [http://i3wm.org Official website]<br />
* [http://code.stapelberg.de/git/i3 Source code]<br />
* [https://wiki.archlinux.org/index.php/Systemd#Suspend.2Fresume_service_files Suspend/resume service files]<br />
* [https://github.com/ashinkarov/i3-extras Collection of scripts and patches]<br />
'''Arch Linux Forums'''<br />
* [https://bbs.archlinux.org/viewtopic.php?id=99064 ''The i3 thread''] - A general discussion about i3<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1229978 ''i3 desktop screenshots and config sharing'']</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=LightDM&diff=251704LightDM2013-03-23T18:15:40Z<p>Txus.palacios: /* Installation */</p>
<hr />
<div>[[Category:Display managers]]<br />
[[es:LightDM]]<br />
[[fr:LightDM]]<br />
{{Article summary start}}<br />
{{Article summary text|Provides an overview and setup of the Light Display Manager.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Display Manager}}<br />
{{Article summary wiki|GDM}}<br />
{{Article summary wiki|KDM}}<br />
{{Article summary wiki|SLiM}}<br />
{{Article summary end}}<br />
<br />
[http://www.freedesktop.org/wiki/Software/LightDM LightDM] is a cross-desktop display manager that aims to be the standard display manager for the X server. Its key features are:<br />
* A lightweight codebase<br />
* Standards compliant (PAM, ConsoleKit, etc)<br />
* A well defined interface between the server and the user interface.<br />
* Cross-desktop (user interfaces can be written in any toolkit).<br />
<br />
More details about LightDM's design can be found [http://www.freedesktop.org/wiki/Software/LightDM/Design here].<br />
<br />
== Installation ==<br />
Install {{Pkg|lightdm}} from the [[official repositories]]. You can also install {{AUR|lightdm-devel}} for the development branch or {{AUR|lightdm-bzr}} from the [[AUR]].<br />
<br />
=== Greeter===<br />
You will also need to install a greeter (a user interface for LightDM). The reference greeter is ''lightdm-gtk-greeter'', which is provided by {{Pkg|lightdm-gtk3-greeter}}. KDE users can install {{Pkg|lightdm-kde-greeter}}, a greeter based on Qt.<br />
<br />
Other greeters can be installed from the [[AUR]] as well: <br />
* {{AUR|lightdm-webkit-greeter}}: A greeter that uses Webkit for theming.<br />
* {{AUR|lightdm-crowd-greeter}}: A 3D greeter that lets you select your profile from 3D characters walking around.<br />
* {{AUR|lightdm-unity-greeter}}: The greeter used by Ubuntu's [[Unity]].<br />
* {{AUR|razor-lightdm-greeter}}: A greeter for the [[Razor-qt]] desktop environment.<br />
* {{AUR|lightdm-pantheon-greeter}}: A LightDM greeter from the ElementaryOS Project.<br />
<br />
You can change the default greeter by changing the configuration file to state:<br />
{{hc|/etc/lightdm/lightdm.conf|<br />
greeter-session&#61;lightdm-yourgreeter-greeter<br />
}}<br />
<br />
It is also possible to change the default greeter at compile time by changing the line containing:<br />
--with-greeter-session=lightdm-gtk-greeter<br />
to<br />
--with-greeter-session=lightdm-yourgreeter-greeter<br />
<br />
== Enabling LightDM ==<br />
Make sure that the '''lightdm''' daemon is [[Daemons#Managing_daemons|started]] at boot.<br />
<br />
=== Testing ===<br />
First, [[Pacman|install]] {{Pkg|xorg-server-xephyr}} from the [[official repositories]].<br />
<br />
Then, run LightDM as an X application:<br />
$ lightdm --test-mode --debug<br />
<br />
== Optional Configuration and Tweaks ==<br />
Some greeters have their own configuration files. For example, {{Pkg|lightdm-gtk3-greeter}} has:<br />
/etc/lightdm/lightdm-gtk-greeter.conf<br />
and {{Pkg|lightdm-kde-greeter}} has:<br />
/etc/lightdm/lightdm-kde-greeter.conf<br />
as well as a section in KDE's System Settings (recommended).<br />
<br />
LightDM can be configured by directly modifying its configuration script or by using the {{ic|lightdm-set-defaults}} applications<br />
that can be found in {{ic|/usr/lib/lightdm/lightdm/}}. To see some of the options available, execute:<br />
$ man lightdm-set-defaults<br />
<br />
There are, however, a lot more variables to modify in the configuration file than by using the {{ic|lightdm-set-defaults}} application.<br />
<br />
=== Changing Background Images/Colors ===<br />
Users wishing to have a flat color (no image) may simply set the '''background''' variable to a hex color.<br />
<br />
Example:<br />
background=#000000<br />
<br />
If you want to use an image instead, see below.<br />
<br />
==== GTK+ Greeter ====<br />
Users wishing to customize the wallpaper on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} defining the '''background''' variable.<br />
<br />
Example:<br />
background=/usr/share/pixmaps/black_and_white_photography-wallpaper-1920x1080.jpg<br />
<br />
==== Unity Greeter ====<br />
Users using the {{AUR|lightdm-unity-greeter}} must edit the {{ic|/usr/share/glib-2.0/schemas/com.canonical.unity-greeter.gschema.xml}} file and then execute:<br />
# glib-compile-schemas /usr/share/glib-2.0/schemas/<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id=149945 this] page.<br />
<br />
{{Note|It is recommended to place the PNG or JPG file in {{ic|/usr/share/pixmaps}} since the LightDM user needs read access to the wallpaper file.}}<br />
<br />
==== KDE Greeter ====<br />
Go to ''System Settings > Login Screen (LightDM)'' and change the background image for your theme.<br />
<br />
=== Changing the Icon ===<br />
Users wishing to customize the icon on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} defining the '''logo''' variable.<br />
<br />
Example:<br />
logo=/usr/share/icons/hicolor/64x64/devices/archlinux-icon-crystal-64.svg<br />
<br />
==== Sources of Arch-centric 64x64 Icons ====<br />
The {{Pkg|archlinux-artwork}} package from the [[official repositories]] contains some nice examples that install to {{ic|/usr/share/archlinux/icons}} and that can be copied to {{ic|/usr/share/icons/hicolor/64x64/devices}} as follows:<br />
# find /usr/share/archlinux/icons -name "*64*" -exec cp {} /usr/share/icons/hicolor/64x64/devices \;<br />
<br />
After copying, the {{Pkg|archlinux-artwork}} package can be removed.<br />
<br />
=== Enabling Autologin ===<br />
Edit the LightDM configuration file and change these lines to:<br />
{{hc|/etc/lightdm/lightdm.conf|<nowiki><br />
autologin-user=<your_username><br />
autologin-user-timeout=0</nowiki><br />
}}<br />
or execute:<br />
<br />
# /usr/lib/lightdm/lightdm/lightdm-set-defaults --autologin=USERNAME<br />
<br />
LightDM goes through PAM even when {{ic|autologin}} is enabled. You must be part of the {{ic|autologin}} group to be able to login without entering your password:<br />
<br />
# groupadd autologin<br />
# gpasswd -a ''username'' autologin<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user will have to set up a blank password to their keyring for it to be unlocked automatically.}}<br />
<br />
=== NumLock ON ===<br />
Install the {{ic|numlockx}} package and the edit {{ic| /etc/lightdm/lightdm.conf}} adding the following line:<br />
greeter-setup-script=/usr/bin/numlockx on<br />
<br />
=== User switching under xfce4 ===<br />
With the release of Xfce4 4.10, user switching is supported natively. To use it with LightDM, users need only to create a symlink:<br />
# ln -s /usr/lib/lightdm/lightdm/gdmflexiserver /usr/bin/gdmflexiserver<br />
<br />
Alternatively, see the [[XScreenSaver#Lightdm]] article.<br />
<br />
== See Also ==<br />
* [https://wiki.ubuntu.com/LightDM Ubuntu Wiki article]<br />
* [http://wiki.gentoo.org/wiki/LightDM Gentoo Wiki article]<br />
* [https://launchpad.net/lightdm Launchpad Page]<br />
* [http://www.mattfischer.com/blog/?tag=lightdm LightDM blog]</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=251666Solid state drive2013-03-23T12:42:04Z<p>Txus.palacios: /* Intelligent Partition Scheme */ physical -> magnetic</p>
<hr />
<div>[[Category:Storage]]<br />
[[it:Solid State Drives]]<br />
[[ru:Solid State Drives]]<br />
[[zh-CN:Solid State Drives]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers many aspects of SSDs (solid state drives) as they relate to Linux; however, the underlying principals and key learning presented within are general enough to be applicable to users running SSDs on other operating systems such as the Windows family of products as well as Mac OS X. Beyond the aforementioned information, Linux users will benefit from the tweaks/optimization presented herein.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary wiki|profile-sync-daemon}} <br />
{{Article summary end}}<br />
<br />
==Overview==<br />
===Introduction===<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to set up SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using other operating systems like BSD, Mac OS X or Windows.}}<br />
===Advantages over HDDs===<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - no decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - approximately 100x faster than an HDD. For example, 0.1 ms (100 us) vs. 12-20 ms (12,000-20,000 us) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
*Per-storage cost (close to a dollar per GB, vs. around a dime or two per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size are not autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes are not amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell does not lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection is not universally well implemented, meaning freed space is not always collected into entirely free cells.<br />
<br />
===Pre-Purchase Considerations===<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
====Reviews====<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and Testing SSD TRIM Support Under Linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===TRIM===<br />
Most SSDs support the [http://en.wikipedia.org/wiki/TRIM ATA_TRIM command] for sustained long-term performance and wear-leveling. For more including some before and after benchmark, see [https://sites.google.com/site/lightrush/random-1/howtoconfigureext4toenabletrimforssdsonubuntu this] tutorial. <br />
<br />
As of linux kernel version 3.7, the following filesystems support TRIM: ext4, btrfs, JFS, and XFS.<br />
<br />
The [https://wiki.archlinux.org/index.php/Solid_State_Drives#Choice_of_Filesystem Choice_of_Filesystem] section of this article offers more details.<br />
==== Enable TRIM by Mount Flags ====<br />
Using this flag in one's {{ic|/etc/fstab}} enables the benefits of the TRIM command stated above.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,'''discard''' 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,'''discard''' 0 2<br />
<br />
{{Note|It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.}}<br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the {{ic|discard}} flag. Data loss can occur otherwise!}}<br />
<br />
====Apply TRIM via cron====<br />
Enabling TRIM on supported SSDs is definitely recommended. But sometimes it may cause some SSDs to [https://patrick-nagel.net/blog/archives/337 perform slowly] during deletion of files. If this is the case, one may choose to use fstrim as an alternative.<br />
# fstrim -v /<br />
The partition for which fstrim is to be applied must be mounted, and must be indicated by the mount point. <br />
<br />
If this method seems like a better alternative, it might be a good idea to have this run from time to time using cron. To have this run daily, the default cron package (cronie) includes an anacron implementation which, by default, is set up for hourly, daily, weekly, and monthly jobs. To add to the list of daily cron tasks, simply create a script that takes care of the desired actions and put it in /etc/cron.daily, /etc/cron.weekly, etc. Appropriate nice and ionice values are recommended if this method is chosen. If implemented, remove the "discard" option from {{ic|/etc/fstab}}.<br />
<br />
{{Note|Use the 'discard' mount option as a first choice. This method should be considered second to the normal implementation of TRIM.}}<br />
<br />
=====Enable TRIM for LVM=====<br />
Enable '''issue_discards''' option in /etc/lvm/lvm.conf<br />
<br />
====Enable TRIM With mkfs.ext4 or tune2fs (Discouraged) ====<br />
One can set the trim flag statically with tune2fs or when the filesystem is created.<br />
# tune2fs -o discard /dev/sdXY<br />
or<br />
# mkfs.ext4 -E discard /dev/sdXY<br />
<br />
{{Note|After this option is set as described above, any time the user checks mounted filesystems with "mount", the discard option will not show up. Even when discard is passed on the CLI in addition to the option being set with tune2fs or mkfs.ext4, it will not show up. See the following thread for a discussion about his: https://bbs.archlinux.org/viewtopic.php?id&#61;137314 }}<br />
<br />
=== I/O Scheduler ===<br />
Consider switching from the default [https://en.wikipedia.org/wiki/CFQ CFQ] scheduler (Completely Fair Queuing) to [http://en.wikipedia.org/wiki/NOOP_scheduler NOOP] or [http://en.wikipedia.org/wiki/Deadline_scheduler Deadline]. The latter two offer performance boosts for SSDs. The NOOP scheduler, for example, implements a simple queue for all incoming I/O requests, without re-ordering and grouping the ones that are physically closer on the disk. On SSDs seek times are identical for all sectors, thus invalidating the need to re-order I/O queues based on them.<br />
<br />
For more on schedulers, see these: [http://www.linux-mag.com/id/7564 Linux Magazine article], [http://www.phoronix.com/scan.php?page=article&item=linux_iosched_2012 Phoronix benchmark] and {{Bug|22605}}.<br />
<br />
The CFQ scheduler is enabled by default on Arch. Verify this by viewing the contents {{ic|/sys/block/sdX/queue/scheduler}}:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
Users can change this on the fly without the need to reboot.<br />
<br />
As root:<br />
# echo noop > /sys/block/sdX/queue/scheduler<br />
As a regular user:<br />
$ echo noop | sudo tee /sys/block/sdX/queue/scheduler<br />
<br />
This method is non-persistent (eg. change will be lost upon rebooting). Confirm the change was made by viewing the contents of the file again and ensuring noop is between brackets.<br />
<br />
===== Kernel parameter (for a single device) =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the {{ic|1=elevator=noop}} kernel parameter. See [[Kernel parameters]] for more info.<br />
<br />
===== Using the sys virtual filesystem (for multiple devices) =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
<br />
Create the following tmpfile where "X" is the letter for the SSD device.<br />
<br />
{{hc| /etc/tmpfiles.d/set_IO_scheduler.conf |<nowiki><br />
w /sys/block/sdX/queue/scheduler - - - - noop<br />
</nowiki>}}<br />
<br />
Because of the potential for udev to assign different {{ic|/dev/}} nodes to drives before and after a kernel update, users must take care that the NOOP scheduler is applied to the correct device upon boot. One way to do this is by using the SSD's device ID to determine its {{ic|/dev/}} node. To do this automatically, use the following snippet instead of the line above and add it to {{ic|/etc/rc.local}}:<br />
declare -ar SSDS=(<br />
'scsi-SATA_SAMSUNG_SSD_PM8_S0NUNEAB861972'<br />
'ata-SAMSUNG_SSD_PM810_2.5__7mm_256GB_S0NUNEAB861972'<br />
)<br />
<br />
for SSD in "${SSDS[@]}" ; do<br />
BY_ID=/dev/disk/by-id/$SSD<br />
<br />
if &#91;&#91; -e $BY_ID ]] ; then<br />
DEV_NAME=`ls -l $BY_ID | awk '{ print $NF }' | sed -e 's/[/\.]//g'`<br />
SCHED=/sys/block/$DEV_NAME/queue/scheduler<br />
<br />
if &#91;&#91; -w $SCHED ]] ; then<br />
echo noop > $SCHED<br />
fi<br />
fi<br />
done<br />
where {{ic|SSDS}} is a Bash array containing the device IDs of all SSD devices. Device IDs are listed in {{ic|/dev/disk/by-id/}} as symbolic links pointing to their corresponding {{ic|/dev/}} nodes. To view the links listed with their targets, issue the following command:<br />
ls -l /dev/disk/by-id/<br />
<br />
=====Using udev for one device or HDD/SSD mixed environment=====<br />
Though the above will undoubtedly work, it is probably considered a reliable workaround. It should also be noted that with the move to [[systemd]] there will be no rc.local. Ergo, it would be preferred to use the system that is responsible for the devices in the first place to implement the scheduler. In this case it is udev, and to do this, all one needs is a simple [[udev]] rule.<br />
<br />
To do this, create and edit a file in /etc/udev/rules.d named something like '60-schedulers.rules'. In the file include the following:<br />
# set deadline scheduler for non-rotating disks<br />
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"<br />
<br />
# set cfq scheduler for rotating disks<br />
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"<br />
Of course, set deadline/cfq to the desired schedulers. Changes should occur upon next boot. To check success of the new rule:<br />
$ cat /sys/block/sdX/queue/scheduler #where X is the device in question<br />
<br />
{{note|Keep in mind cfq is the default scheduler, so the second rule with the standard kernel is not actually necessary. Also, in the example sixty is chosen because that is the number udev uses for its own persistent naming rules. Thus, it would seem that block devices are at this point able to be modified and this is a safe position for this particular rule. But the rule can be named anything so long as it ends in '.rules'. (Credit: falconindy and w0ng for posting on his blog)}}<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is a recommendeded tweak for SSDs using a swap partition that will reduce the "swappiness" of the system thus avoiding writes to swap:<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{ic|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use {{ic|iotop -oPa}} and sort by disk writes to see how much programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
*For systems with both an SSD and an HDD, consider relocating the {{ic|/var}} partition to a magnetic disc on the system rather than on the SSD itself to avoid read/write wear. <br />
*For systems with only an SSD (i.e. no HDDs), consider allocating a separate partition for {{ic|/var}} to allow for better crash recovery for example in the event of a broken program wasting all the space on {{ic|/}} or if some run away log file maxes out the space, etc.<br />
<br />
===noatime Mount Flag===<br />
Using this flag in one's {{ic|/etc/fstab}} halts the logging of read accesses to the file system via an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
<br />
/dev/sda1 / ext4 defaults,'''noatime''' 0 1<br />
/dev/sda2 /home ext4 defaults,'''noatime''' 0 2<br />
<br />
{{Note|This setting will cause issues with some programs such as [[Mutt]], as the access time of the file will eventually be previous than the modification time, which would make no sense. Using the '''relatime''' option instead of noatime will ensure that the atime field will never be prior to the last modification time of a file.}}<br />
<br />
=== Locate High-Use Files to RAM ===<br />
==== Browser Profiles ====<br />
One can ''easily'' mount browser profile(s) such as chromium, firefox, opera, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
The AUR contains several packages to automate this process, for example {{AUR|profile-sync-daemon}}.<br />
<br />
==== Others ====<br />
For the same reasons a browser's profile can be relocated to RAM, so can highly used directories such as {{ic|/srv/http}} (if running a web server). A sister project to {{AUR|profile-sync-daemon}} is {{AUR|anything-sync-daemon}}, which allows users to define '''any''' directory to sync to RAM using the same underlying logic and safe guards.<br />
<br />
=== Compiling in tmpfs ===<br />
Intentionally compiling in {{ic|/tmp}} is a great idea to minimize this problem. Arch Linux defaults {{ic|/tmp}} to 50 % of the physical memory. For systems with >4 GB of memory, one can create a {{ic|/scratch}} and mount it to tmpfs set to use more than 50 % of the physical memory.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
tmpfs /scratch tmpfs nodev,nosuid,size=7G 0 0<br />
<br />
=== Disabling Journaling on the filesystem ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://tytso.livejournal.com/61830.html Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in tmpfs as recommended in the [[Solid_State_Drives#Compiling_in_tmpfs|preceding section]] of this article!}}<br />
<br />
== Choice of Filesystem ==<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. Users are encouraged to read the [[Btrfs]] article for more info.<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. ext4 users must explicitly enable the TRIM command support using the {{ic|discard}} mount option in [[fstab]] (or with {{ic|tune2fs -o discard /dev/sdaX}}).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/filesystems/ext4.txt official in kernel tree documentation] for further information on ext4.<br />
<br />
====XFS====<br />
Many users do not realize that in addition to ext4 and btrfs, [http://en.wikipedia.org/wiki/XFS XFS] has TRIM support as well. This can be enabled in the usual ways. That is, the choice may be made of either using the discard option mentioned above, or by using the fstrim command. More information can be found on the [http://xfs.org/index.php/FITRIM/discard XFS wiki].<br />
<br />
====JFS====<br />
As of Linux kernel version 3.7, proper TRIM support has been added. So far, there is not a great wealth of information of the topic but it has certainly been picked up by [http://www.phoronix.com/scan.php?page=news_item&px=MTE5ODY Linux news sites.] It is apparent that it can be enabled via the {{ic|discard}} mount option, or by using the method of batch TRIMs with fstrim.<br />
<br />
== Firmware Updates ==<br />
=== ADATA ===<br />
ADATA has a utility available for Linux (i686) on their support page [http://www.adata.com.tw/index.php?action=ss_main&page=ss_content_driver&lan=en here]. The link to the utility will appear after selecting the model.<br />
===Kingston===<br />
Kingston has a Linux utilty to update the firmware of their Sandforce based drives. It can be found on their [http://www.kingston.com/us/support support page].<br />
<br />
===Mushkin===<br />
The lesser known Mushkin brand Solid State drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.<br />
<br />
=== OCZ ===<br />
OCZ has a command line utility available for Linux (i686 and x86_64) on their forum [http://www.ocztechnology.com/ssd_tools/ here].<br />
<br />
===Samsung===<br />
Samsung notes that update methods other than by using their Magician Software is "not supported", but it is possible. Apparently the Magician Software can be used to make a USB drive bootable with the firmware update. However, I couldn't get the Magician Software to cooperate with me. The easiest method is to use the bootable ISO images they provide for updating the firmware. They can be grabbed from [http://www.samsung.com/global/business/semiconductor/samsungssd/downloads.html here]. Note Samsung doesn't make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages each referencing different ways of doing things.<br />
<br />
=== SanDisk ===<br />
SanDisk makes '''ISO firmware images''' to allow SSD firmware update on operating systems that are unsupported by their SanDisk SSD Toolkit. Note that one must choose the firmware for the right ''SSD model'', as well as for the ''capacity'' that it has (e.g. 60GB, '''or''' 256GB). After burning the adequate ISO firmware image, simply restart your computer to boot with the newly created CD/DVD boot disk (may work from a USB stick.<br />
<br />
I couldn't find a single page listing the firmware updates yet (site is a mess IMHO), but here are some relevant links:<br />
<br />
SanDisk Extreme SSD [http://kb.sandisk.com/app/answers/detail/a_id/10127 Firmware Release notes] and [http://kb.sandisk.com/app/answers/detail/a_id/10476 Manual Firmware update version R211] <br />
<br />
SanDisk Ultra SSD [http://kb.sandisk.com/app/answers/detail/a_id/10192 Firmware release notes] and [http://kb.sandisk.com/app/answers/detail/a_id/10477 Manual Firmware update version 365A13F0]<br />
<br />
== See also ==<br />
* [http://www.reddit.com/r/archlinux/comments/rkwjm/what_should_i_keep_in_mind_when_installing_on_ssd/ Discussion on Reddit about installing Arch on an SSD]<br />
* See the [[Flashcache]] article for advanced information on using solid-state with rotational drives for top performance.<br />
* [http://lifehacker.com/5837769/make-sure-your-partitions-are-correctly-aligned-for-optimal-solid-state-drive-performance Speed Up Your SSD By Correctly Aligning Your Partitions] (using GParted)</div>Txus.palacioshttps://wiki.archlinux.org/index.php?title=Chromium/Tips_and_tricks&diff=251545Chromium/Tips and tricks2013-03-21T17:15:24Z<p>Txus.palacios: /* Making it all persistent */ - Chromium does not load Pepperflash unless you feed it the ppapi arguments. As CHROMIUM_USER_FLAGS takes precedence over CHROMIUM_FLAGS, when the user flags are present, Pepperflash breaks.</p>
<hr />
<div>[[Category:Web Browser]]<br />
[[zh-CN:Chromium Tips and Tweaks]]<br />
{{Article summary start}}<br />
{{Article summary text|Tips and Tweaks for Chromium are captured in this article.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Chromium}}<br />
{{Article summary wiki|Firefox Tweaks}}<br />
{{Article summary end}}<br />
<br />
== Browsing experience ==<br />
=== about:xxx ===<br />
A number of tweaks can be accessed via typing ''about:xxx'' in the URL field. A complete list is available by typing '''about:chrome-urls''' into the URL field. Some of note are listed below:<br />
<br />
* '''about:flags''' - access experimental features such as WebGL and rendering webpages with GPU, etc.<br />
* '''about:plugins''' - view, enable and disable the currently used Chromium plugins.<br />
* '''about:gpu-internals''' - status of different GPU options.<br />
* '''about:sandbox''' - indicate sandbox status.<br />
* '''about:version''' - display version and switches used to invoke the active {{ic|/usr/bin/chromium}}.<br />
<br />
An automatically updated, complete listing of Chromium switches is available [http://peter.sh/experiments/chromium-command-line-switches/ here].<br />
<br />
=== Broken icons in Download Tab ===<br />
If Chromium shows icon placeholders (icons representing broken documents) instead of appropriate icons in its download tab, the likely cause is that the {{Pkg|gnome-icon-theme}} package is not installed.<br />
<br />
=== Chromium overrides/overwrites Preferences file ===<br />
<br />
If you enabled syncing with a Google Account, then Chromium will tend to override any edits made by hand to the Preferences file found under {{ic|$HOME/.config/google-chrome/Default/Preferences}}. To work around this, start Chromium with the {{ic|--disable-sync-preferences}} switch:<br />
$ chromium --disable-sync-preferences<br />
<br />
If Chromium is started in the background when you login to your desktop environment, make sure the command your desktop environment uses is<br />
$ chromium --disable-sync-preferences --no-startup-window<br />
<br />
=== Memory usage ===<br />
Chromium offers some command-line options to help control how efficient it is with system memory, by determining how often it should release memory back to the operating system. It is done with the flag {{ic|1=--memory-model=X}}, where X is one of the following:<br />
<br />
* '''high''' - Never voluntarily relinquish memory.<br />
* '''medium''' - Voluntarily reduce working set when switching tabs.<br />
* '''low''' - Voluntarily reduce working set when switching tabs and also when the browser is not actively being used.<br />
<br />
It is also possible to manually force Chromium to purge its memory. The flag {{ic|--purge-memory-button}} enables a button in the task manager (available in ''Tools > Task Manager'', or by pressing {{keypress|Shift+Esc}}) to do this.<br />
<br />
=== Scroll speed of mouse wheel ===<br />
{{Note|1=As of 22-Feb-2013, this method is deprecate upstream. See [https://code.google.com/p/chromium/issues/detail?id=154776 this].}}<br />
{{AUR|chromium-scroll-pixels}} in the AUR reverses this patch.<br />
<br />
[https://wiki.archlinux.org/index.php/User:Graysky Graysky] provides this package compiled for x86_64 only on his unofficial repo, [[Repo-ck]].<br />
<br />
The following switch can be used to set the scroll speed of the wheel mouse: {{ic|--scroll-pixels&#61;X}}<br />
<br />
$ chromium --scroll-pixels=320<br />
<br />
=== Search Engines ===<br />
Make sites like wiki.archlinux.org and wikipedia.org easily searchable by first executing a search on those pages, then going to ''Settings > Search'' and click the ''Manage search engines..'' button. From there, "Edit" the Wikipedia entry and change its keyword to "w" (or some other shortcut you prefer). Now searching Wikipedia for "Arch Linux" from the address bar is done simply by entering "w arch linux".<br />
<br />
{{Note| Google search is used automatically when typing something into the URL bar. A hard-coded keyword trigger is also available using the '''?''' prefix.}}<br />
<br />
=== Tmpfs ===<br />
==== Cache in tmpfs ====<br />
{{Note|Chromium actually keeps its cache directory '''separate''' from its browser profile directory.}}<br />
<br />
To limit Chromium from writing its cache to a physical disk, one can define an alternative location via the {{ic|1=--disk-cache-dir=/foo/bar}} flag:<br />
$ chromium --disk-cache-dir=/tmp/cache<br />
<br />
Cache should be considered temporary and will '''not''' be saved after a reboot or hard lock.<br />
<br />
Alternative way, in {{ic|/etc/fstab}}:<br />
tmpfs /home/<USER>/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0<br />
<br />
{{Note|Adjust the size as needed.}}<br />
<br />
==== Profile in tmpfs ====<br />
Relocate the browser profile to a [[Wikipedia:Tmpfs|tmpfs]] filesystem, including {{ic|/tmp}}, or {{ic|/dev/shm}} for improvements in application response as the entire profile is now stored in RAM.<br />
<br />
Use an active profile management script for maximal reliability and ease of use.<br />
<br />
{{AUR|profile-sync-daemon}} is such a script and is directly available from the [[AUR]]. It symlinks and syncs the browser profile directories to RAM. Refer to the [[Profile-sync-daemon]] wiki article for additional information on it.<br />
<br />
==Profile Maintenance ==<br />
Chromium uses [[Sqlite]] databases to manage history and the like. Sqlite databases become fragmented over time and empty spaces appear all around. But, since there are no managing processes checking and optimizing the database, these factors eventually result in a performance hit. A good way to improve startup and some other bookmarks and history related tasks is to defragment and trim unused space from these databases.<br />
<br />
{{AUR|profile-cleaner}} and {{AUR|browser-vacuum}} in the [[AUR]] do just this.<br />
<br />
== Security ==<br />
=== Run in a Sandbox ===<br />
Run chromium in a sandbox for added security:<br />
$ chromium --enable-seccomp-sandbox<br />
<br />
=== User Agent===<br />
By default Chromium already sends an excessively detailed User Agent, as is viewable via the EFF's [https://panopticlick.eff.org/ Panopticlick] test. That alone makes each browser readily identifiable with high accuracy — and is further exacerbated by the use of non-stable versions, ones not recently provided by Google's release channels, ones customized e.g. by a distribution (such as the AUR's {{AUR|chromium-browser-ppa}}), etc.<br />
<br />
However, this User Agent can be arbitrarily modified at the start of Chromium's base instance via its {{Ic|<nowiki>--user-agent="[string]"</nowiki>}} parameter.<br />
<br />
For the same User Agent as the stable Chrome release for Linux i686 (at the time of writing the most popular Linux edition of Chrome) one would use:<br />
--user-agent="Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11"<br />
<br />
An official, automatically updated listing of Chromium releases which also shows the included WebKit version is available as the [https://omahaproxy.appspot.com/ OmahaProxy Viewer].<br />
<br />
=== Making it all persistent ===<br />
You can export your flags from {{ic|~/.profile}}:<br />
export CHROMIUM_USER_FLAGS="--disk-cache-dir=/tmp --disk-cache-size=50000000"<br />
<br />
Or add them to {{ic|/etc/chromium/default}}:<br />
{{bc|<nowiki><br />
# Default settings for chromium. This file is sourced by /usr/bin/chromium<br />
#<br />
# Options to pass to chromium<br />
CHROMIUM_FLAGS="--scroll-pixels=200"</nowiki><br />
}}<br />
<br />
Chromium will prefer the user defined flags in {{ic|CHROMIUM_USER_FLAGS}} to those defined in {{ic|/etc/chromium/default}}.<br />
<br />
If you want to use {{ic|CHROMIUM_USER_FLAGS}} and Pepperflash, you should add Chromium Pepperflash arguments to your {{ic|~/.profile}} file. <br />
export CHROMIUM_USER_FLAGS="--ppapi-flash-path=/usr/lib/PepperFlash/libpepflashplayer.so --ppapi-flash-version=11.7.700.141"<br />
<br />
=== SSL Certificates ===<br />
Unfortunately, Chromium doesn't have a SSL certificate manager. It relies on the NSS Shared DB {{ic|~/.pki.nssdb}}. In order to add SSL certificates to the database, users will have to use the shell. <br />
<br />
==== Adding CAcert Certificates for Self-Signed Certificates ====<br />
Grab the CAcerts and create a nssdb if one does not already exist. To do this, first install the {{Pkg|nss}} package, then complete these steps:<br />
{{bc|<nowiki>[[ ! -e $HOME/.pki/nssdb ]] && mkdir -p $HOME/.pki/nssdb && cd $HOME/.pki/nssdb && certutil -N -d sql:.</nowiki>}}<br />
{{Note|Users will need to create a password for the database should it not exist.}}<br />
<br />
{{bc|<nowiki>curl -k -o "cacert-root.crt" "http://www.cacert.org/certs/root.crt"<br />
curl -k -o "cacert-class3.crt" "http://www.cacert.org/certs/class3.crt"<br />
certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org" -i cacert-root.crt <br />
certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "CAcert.org Class 3" -i cacert-class3.crt<br />
</nowiki>}}<br />
<br />
{{Note|Users will need to create a password for the database should it not exist.}}<br />
<br />
Now users may manually import a self-signed certificate.<br />
<br />
==== Example 1: Using a Shell Script Isolate the Certificate from TomatoUSB ====<br />
Below is a simple script that will extract and add a certificate to the user's nssdb:<br />
<br />
#!/bin/sh<br />
#<br />
# usage: import-cert.sh remote.host.name [port]<br />
#<br />
REMHOST=$1<br />
REMPORT=${2:-443}<br />
exec 6>&1<br />
exec > $REMHOST<br />
echo | openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'<br />
certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "$REMHOST" -i $REMHOST <br />
exec 1>&6 6>&-<br />
<br />
Syntax is advertised in the commented lines.<br />
<br />
Reference:<br />
*http://blog.avirtualhome.com/adding-ssl-certificates-to-google-chrome-linux-ubuntu<br />
<br />
==== Example 2: Using Firefox to Isolate the Certificate from TomatoUSB ====<br />
The {{Pkg|firefox}} browser can used to save the certificate to a file for manunal import into the DB.<br />
<br />
Using firefox:<br />
#Browse to the target URL.<br />
#Upon seeing the "This Connection is Untrusted" warning screen, click I understand the Risks>Add Exception...<br />
#Click View>Details>Export and save the certificate to a temporary location ({{ic|/tmp/easy.pem}} in this example).<br />
<br />
Now import the certificate for use in Chromium:<br />
certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "easy" -i /tmp/easy.pem<br />
<br />
{{Note|Adjust the name to match that of the certificate. In the example above, "easy" is the name on the certificate.}}<br />
<br />
Reference:<br />
*http://sahissam.blogspot.com/2012/06/new-ssl-certificates-for-tomatousb-and.html</div>Txus.palacios