https://wiki.archlinux.org/api.php?action=feedcontributions&user=Pelzflorian&feedformat=atomArchWiki - User contributions [en]2024-03-29T08:10:57ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=WebDAV&diff=479557WebDAV2017-06-10T18:40:41Z<p>Pelzflorian: Add nginx instructions.</p>
<hr />
<div>[[Category:Network sharing]]<br />
[[ja:WebDAV]]<br />
WebDAV ('''Web''' '''D'''istributed '''A'''uthoring and '''V'''ersioning) is an extension of HTTP 1.1 and therefore can be considered to be a procotol. It contains a set of concepts and accompanying extension methods to allow read and write across the HTTP 1.1 protocol. Instead of using [[NFS]] or [[SMB]], WebDAV offers file transfers via HTTP. <br />
<br />
The goal of this how to is to setup a simple WebDAV configuration using a [[:Category:Web server|web server]].<br />
<br />
== Server ==<br />
=== Apache ===<br />
Install the [[Apache HTTP Server]].<br />
<br />
Uncomment the modules for DAV:<br />
{{bc|<br />
LoadModule dav_module modules/mod_dav.so<br />
LoadModule dav_fs_module modules/mod_dav_fs.so<br />
LoadModule dav_lock_module modules/mod_dav_lock.so<br />
}}<br />
<br />
Add the following line to {{ic|/etc/httpd/conf/httpd.conf}}.<br />
DAVLockDB /home/httpd/DAV/DAVLock<br />
<br />
Make sure you add it outside of any other directives, for instance right under the {{ic|DocumentRoot}} definition.<br />
<br />
Next, add the following (also outside of any directives):<br />
{{bc|<br />
Alias /dav "/home/httpd/html/dav"<br />
<br />
<Directory "/home/httpd/html/dav"><br />
DAV On<br />
AllowOverride None<br />
Options Indexes FollowSymLinks<br />
Require all granted<br />
</Directory><br />
}}<br />
<br />
Create the directory:<br />
# mkdir -p /home/httpd/DAV<br />
<br />
Check the permissions of DavLockDB's directory and ensure it is writable by the webserver [[user]] {{ic|http}}:<br />
# chown -R http:http /home/httpd/DAV<br />
# mkdir -p /home/httpd/html/dav<br />
# chown -R http:http /home/httpd/html/dav<br />
<br />
===Nginx===<br />
Install the mainline variant of [[nginx]] and {{AUR|nginx-mainline-mod-dav-ext}}.<br />
<br />
At the top of your {{ic|/etc/nginx/nginx.conf}} and outside any blocks, add<br />
{{bc|<br />
load_module /usr/lib/nginx/modules/ngx_http_dav_ext_module.so;<br />
}}<br />
<br />
Add a new {{ic|location}} for WebDAV to your {{ic|server}} block, for example:<br />
{{bc|<br />
location /dav {<br />
root /srv/http;<br />
<br />
dav_methods PUT DELETE MKCOL COPY MOVE;<br />
dav_ext_methods PROPFIND OPTIONS;<br />
<br />
# Adjust as desired:<br />
dav_access all:rw;<br />
client_max_body_size 0;<br />
create_full_put_path on;<br />
client_body_temp_path /srv/client-temp;<br />
autoindex on;<br />
<br />
allow 192.168.178.0/24;<br />
deny all;<br />
}<br />
}}<br />
<br />
The above example requires the directories {{ic|/srv/http/dav}} and {{ic|/srv/client-temp}} to exist.<br />
<br />
You may want to use bind mounts to make other directories accessible via WebDAV.<br />
<br />
== Client ==<br />
=== Cadaver ===<br />
[[Install]] the package {{Pkg|cadaver}}.<br />
<br />
After installation, test the WebDAV server:<br />
# cadaver http://localhost/dav<br />
dav:/dav/> mkcol test<br />
Creating `test': succeeded.<br />
dav:/dav/> ls<br />
Listing collection `/dav/': succeeded.<br />
Coll: test<br />
<br />
=== Thunar ===<br />
<br />
In [[Thunar]] just press {{ic|Ctrl+l}} and enter the address with ''dav'' or ''davs'' protocol specified:<br />
<br />
davs://webdav.yandex.ru<br />
<br />
== Authentication ==<br />
There are numerous different protocols you can use:<br />
* plain<br />
* digest<br />
* others<br />
<br />
=== Apache ===<br />
Using digest:<br />
# basic form: htdigest -c /path/to/file AuthName username<br />
htdigest -c /etc/httpd/conf/passwd WebDAV '''username'''<br />
<br />
{{Note|Make sure digest authentication is enabled in {{ic|httpd.conf}} by the presence of this entry: {{ic|LoadModule auth_digest_module modules/mod_auth_digest.so}}}}<br />
<br />
Using plain:<br />
# basic form: htpasswd -c /path/to/file username<br />
htpasswd -c /etc/httpd/conf/passwd '''username'''<br />
<br />
Next, {{ic|httpd.conf}} must be edited to enable authentication. One method would be to require the user {{ic|foo}} for everything:<br />
{{bc|<br />
<Directory "/home/httpd/html/dav"><br />
DAV On<br />
AllowOverride None<br />
Options Indexes FollowSymLinks<br />
AuthType Digest # substitute "Basic" for "Digest" if you used htpasswd above<br />
AuthName "WebDAV"<br />
AuthUserFile /etc/httpd/conf/passwd<br />
Require user foo<br />
</Directory><br />
}}<br />
<br />
{{Note|{{ic|AuthName}} must match the name passed when using the {{ic|htdigest}} command for digest authentication. For basic/plain authentication, this line may be removed. Also, make sure that the {{ic|AuthUserFile}} path matches that used with the {{ic|htdigest}} or {{ic|htpasswd}} commands above}}<br />
<br />
If you want to permit everybody to read, you could use this in your httpd.conf<br />
{{bc|<br />
<Directory "/home/httpd/html/dav"><br />
DAV On<br />
AllowOverride None<br />
Options Indexes FollowSymLinks<br />
AuthType Digest # substitute "Basic" for "Digest" if you used htpasswd above<br />
AuthName "WebDAV"<br />
AuthUserFile /etc/httpd/conf/passwd<br />
Require all granted<br />
<LimitExcept GET HEAD OPTIONS PROPFIND><br />
Require user foo<br />
</LimitExcept><br />
</Directory><br />
}}<br />
<br />
Do not forget to restart apache after making changes!<br />
# systemctl restart httpd</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=474169Flatpak2017-04-15T09:54:16Z<p>Pelzflorian: Warn: Don’t use custom runtimes for public release. /* Creating a custom base runtime */</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
If you want to have desktop integration using [https://github.com/flatpak/flatpak/wiki/Portals portals]<br />
you can install the {{Pkg|xdg-desktop-portal-gtk}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak list<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
=== Adding Flatpak .desktop files to your menu ===<br />
Flatpak expects window managers to respect the XDG_DATA_DIRS environment variable to discover applications. This may require restarting the session or the launcher may not support this. In such a case where you can edit the list of directories scanned, add these to it:<br />
<br />
~/.local/share/flatpak/exports/applications<br />
/var/lib/flatpak/exports/applications<br />
<br />
This is known to be necessary in Awesome.<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
{{Warning|If you want to release your software to the public as a Flatpak, an Arch-based runtime is unsuitable. In this case, you will want to follow [http://docs.flatpak.org official documentation] to integrate your software into the proper Flatpak ecosystem using the [http://flatpak.org/runtimes.html common runtimes].}}<br />
<br />
{{Note|You may want to use an untrusted, unprivileged user account for bundling untrusted software because the software is not sandboxed during app and runtime creation.}}<br />
<br />
{{Note|When distributing bundles to others, you may be legally obliged to provide the source code of some of the bundled software upon request. You may want to use [[ABS]] to build these packages from source.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
In addition to {{Pkg|flatpak}}, you need to have installed {{Pkg|fakeroot}} and for pacman hooks support also {{Pkg|fakechroot}}.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir ''myflatpakbuilddir''<br />
$ cd ''myflatpakbuilddir''<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p ''myruntime''/files/var/lib/pacman<br />
$ touch ''myruntime''/files/.ref<br />
$ ln -s /usr/usr/share ''myruntime''/files/share<br />
$ ln -s /usr/usr/include ''myruntime''/files/include<br />
$ ln -s /usr/usr/local ''myruntime''/files/local<br />
<br />
Make your host OS fonts available to the Arch runtime:<br />
<br />
$ mkdir -p ''myruntime''/files/usr/share/fonts<br />
$ ln -s /run/host/fonts ''myruntime''/files/usr/share/fonts/flatpakhostfonts<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Copy {{ic|/etc/pacman.conf}} to your build directory and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root ''myruntime''/files --dbpath ''myruntime''/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf ''myruntime''/files/etc/pacman.conf<br />
<br />
Set up the [[Locale|locales]] to be used by editing {{ic|''myruntime''/files/etc/locale.gen}}. Then regenerate the runtime’s locales.<br />
<br />
$ fakechroot chroot ''myruntime''/files locale-gen<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r ''myruntime'' mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot --needed<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|''myruntime''/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=''myruntime''<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
<br />
Now finish the dummy app. You can fine-tune the app’s access permissions when sandboxed by giving additional options when finishing the build. For possible options see the [[#See also|Flatpak documentation]] and the [https://git.gnome.org/browse/gnome-apps-nightly/tree GNOME manifest files]. Alternatively, adapt {{ic|geditapp/metadata}} to your needs after finishing the build but before exporting. When the metadata file is complete, export the app to the repository.<br />
<br />
$ flatpak build-finish geditapp --socket=x11 ''[possibly other options]'' --command=gedit<br />
$ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]<br />
* [https://community.kde.org/Guidelines_and_HOWTOs/Flatpak KDE Testing Runtime and Applications]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Bubblewrap&diff=468493Bubblewrap2017-02-18T08:03:54Z<p>Pelzflorian: Improve wording for warning.</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Kernel]]<br />
[[Category:Security]]<br />
[[ja:Bubblewrap]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|Flatpak}}<br />
{{Related articles end}}<br />
[https://github.com/projectatomic/bubblewrap bubblewrap] is a lightweight [[wikipedia:Setuid|setuid]] sandbox application developed from [[wikipedia:Flatpak|Flatpak]] with a small installation footprint and minimal resource requirements. While the application package is named bubblewrap, the actual executable binary and manpage reference is ''bwrap''. bubblewrap is expected to [https://blog.torproject.org/blog/q-and-yawning-angel anchor the sandbox mechanism] of the [https://www.torproject.org/projects/torbrowser.html Tor Browser] (Linux) in the future. Notable features include support for cgroup/IPC/mount/network/PID/user/UTS [[wikipedia:Linux_namespaces|namespaces]] and [[wikipedia:Seccomp|seccomp]] filtering. Note that bubblewrap drops all [[Capabilities|capabilities]] within a sandbox and that child tasks cannot gain greater privileges than its parent. Notable feature exclusions include the lack of explicit support for blacklisting/whitelisting file paths. <br />
<br />
{{Warning|Unlike when using a separate user and a separate log-in session, bubblewrap not only exposes security vulnerabilities in the kernel but also in the window compositor. Users should be aware that running untrustworthy code in bubblewrap is still not safe.}}<br />
<br />
==Installation==<br />
[[Install]] {{Pkg|bubblewrap}} or {{AUR|bubblewrap-git}}.<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel per [https://bugs.archlinux.org/task/36969 FS#36969]. This prevents the kernel from exposing user namespaces as a means to accomodate separate user information for separate virtualized services. An example would be running ''syslog'' in a namespace with a UID and GID different than that of the host system. The {{Pkg|linux-grsec}} package sets {{ic|1=CONFIG_USER_NS=y}} but restricts it's use to privileged users for security reasons. It is a viable alternative to the stock kernel if the ability to create user namepaces is desired.}}<br />
<br />
==Configuration==<br />
bubblewrap can be called directly from the command-line and/or within [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh shell scripts] as part of a [https://github.com/projectatomic/bubblewrap/blob/master/demos/flatpak-run.sh complex wrapper]. Unlike applications such as [[Firejail]] which automatically set {{Ic|/var}} and {{Ic|/etc}} to read-only within the sandbox, bubblewrap makes no such operating assumptions. It is up to the user to determine which configuration options to pass in accordance to the application being sandboxed. bubblewrap does not automatically create user namespaces when running with setuid privileges and can accomodate typical environment variables including {{Ic|$HOME}} and {{Ic|$USER}}.<br />
<br />
==Usage examples==<br />
<br />
===Bash===<br />
Create a simple [[Bash]] sandbox: <br />
* Determine available kernel namespaces<br />
$ ls /proc/self/ns <br />
cgroup ipc mnt net pid user uts<br />
{{Note|The presence of {{Ic|user}} indicates that the kernel has exposed support for user namespaces with {{ic|1=CONFIG_USER_NS=y}}}}<br />
* Bind as read-only the entire host {{ic|/}} directory to {{ic|/}} in the sandbox <br />
* Create a new user namespace and set the [[wikipedia:User_identifier|user ID]] to {{ic|256}} and the [[wikipedia:Group_identifier|group ID]] to {{Ic|512}}<br />
$ bwrap --ro-bind / / --unshare-user --uid 256 --gid 512 bash<br />
bash-4.4$ id<br />
uid=256 gid=512 groups=512,65534(nobody)<br />
bash-4.4$ ls -l /usr/bin/bash<br />
-rwxr-xr-x 1 nobody nobody 811752 2017-01-01 04:20 /usr/bin/bash<br />
<br />
===dhcpcd===<br />
Create a simple [[dhcpcd]] sandbox: <br />
* Determine available kernel namespaces<br />
$ ls /proc/self/ns <br />
cgroup ipc mnt net pid uts<br />
{{Note|The absence of {{Ic|user}} indicates that the kernel has been built with {{ic|1=CONFIG_USER_NS=n}} or is user namespace restricted.}}<br />
<br />
* Bind as read-write the entire host {{ic|/}} directory to {{ic|/}} in the sandbox <br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create new [[wikipedia:Inter-process_communication|IPC]] and [[Cgroups|control group]] namespaces<br />
* Create a new UTS namespace and set {{ic|dhcpcd}} as the hostname<br />
<br />
# /usr/bin/bwrap --bind / / --dev /dev --unshare-ipc --unshare-cgroup --unshare-uts --hostname dhcpcd /usr/bin/dhcpcd -q -b<br />
<br />
===Unbound===<br />
Create a more granular and complex [[Unbound]] sandbox: <br />
* Bind as read-only the system {{ic|/usr}} directory to {{ic|/usr}} in the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Bind as read-only the system {{ic|/etc}} directory to {{ic|/etc}} in the sandbox<br />
* Create empty {{ic|/var}} and {{ic|/run}} directories within the sandbox<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create new IPC and [[wikipedia:Process_identifier|PID]] and control group namespaces<br />
* Create a new UTS namespace and set {{ic|unbound}} as the hostname<br />
<br />
# /usr/bin/bwrap --ro-bind /usr /usr --symlink usr/lib /lib64 --ro-bind /etc /etc --dir /var --dir /run --dev /dev --unshare-ipc --unshare-pid --unshare-cgroup --unshare-uts --hostname unbound /usr/bin/unbound -d<br />
<br />
{{Tip|See [[systemd#Editing provided units]] to enable the bubblewrapping of systemd unit files including {{ic|unbound.service}}}}<br />
<br />
===Desktop===<br />
Leverage bubblewrap within [[Desktop entries|desktop entries]]:<br />
* Bind as read-write the entire host {{ic|/}} directory to {{ic|/}} in the sandbox<br />
* Re-bind as read-only the {{ic|/var}} and {{ic|/etc}} directories in the sandbox<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create a tmpfs filesystem over the sandboxed {{ic|/run}} directory<br />
* Disable network access by creating new network namespace<br />
<br />
[Desktop Entry]<br />
Name=nano Editor<br />
Exec=bwrap --bind / / --dev /dev --tmpfs /run --unshare-net st -e nano -o . %f<br />
Type=Application<br />
MimeType=text/plain;<br />
{{Note|{{Ic|--dev /dev}} is required to write to {{Ic|/dev/pty}}}}<br />
<br />
* Example MuPDF desktop entry incorporating a {{Ic|mupdf.sh}} shell wrapper:<br />
<br />
[Desktop Entry]<br />
Name=MuPDF<br />
Exec=mupdf.sh %f<br />
Icon=application-pdf.svg<br />
Type=Application<br />
MimeType=application/pdf;application/x-pdf;<br />
<br />
{{Note|Ensure that {{Ic|mupdf.sh}} is located within your executable PATH e.g. {{Ic|1=PATH=$PATH:$HOME/bwrap}}}}<br />
<br />
===MuPDF===<br />
The power and flexibility of ''bwrap'' is best revealed when used to create an environment within a shell wrapper:<br />
<br />
* Bind as read-only the host {{ic|/usr/bin}} directory to {{ic|/usr/bin}} in the sandbox <br />
* Bind as read-only the host {{ic|/usr/lib}} directory to {{ic|/usr/lib}} in the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Create a [[tmpfs]] filesystem overlaying {{ic|/usr/lib/gcc}} in the sandbox<br />
** This effectively [[wikipedia:Blacklist_(computing)|blacklists]] the contents of {{ic|/usr/lib/gcc}} from appearing in the sandbox<br />
* Create a new tmpfs filesystem as the {{ic|$HOME}} directory in the sandbox<br />
* Bind as read-only an {{Ic|.Xauthority}} file and ''Documents'' directory into the sandbox<br />
** This effectively whitelists the {{Ic|.Xauthority}} file and ''Documents'' directory with recursion<br />
* Create a new tmpfs filesystem as the {{ic|/tmp}} directory in the sandbox<br />
* Whitelist the [[wikipedia:X_Window_System|X11]] socket by binding it into the sandbox as read-only<br />
* Clone and create private containers for all namespaces supported by the running kernel<br />
** If the kernel does not support non-privileged user namespaces, skip its creation and continue<br />
* Do not place network components into a private namespace<br />
** This allows for network access to follow URI hyperlinks<br />
<br />
#!/bin/sh<br />
#~/bwrap/mupdf.sh<br />
(exec bwrap \<br />
--ro-bind /usr/bin /usr/bin \<br />
--ro-bind /usr/lib /usr/lib \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/gcc \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Documents $HOME/Documents \<br />
--tmpfs /tmp \<br />
--ro-bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 \<br />
--unshare-all \<br />
--share-net \<br />
/usr/bin/mupdf "$@")<br />
<br />
{{Tip|Execute a shell wrapper substituting the existing executable with ''/usr/bin/sh'' to debug and verify the contents and filesystem structure of the sandbox.}}<br />
<br />
$ bwrap \<br />
--ro-bind /usr/bin /usr/bin \<br />
--ro-bind /usr/lib /usr/lib \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/gcc \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Desktop $HOME/Desktop \<br />
--tmpfs /tmp \<br />
--ro-bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 \<br />
--unshare-all \<br />
--share-net \<br />
/usr/bin/sh<br />
bash-4.4$ ls -AF<br />
.Xauthority Documents/<br />
<br />
Perhaps the most important rule to consider when building a bubblewrapped filesystem is that ''commands are executed in the order they appear''. From the [http://mupdf.com/ MuPDF] example above:<br />
<br />
* A tmpfs system is created followed by the bind mounting of an {{Ic|.Xauthority}} file and a ''Documents'' directory:<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Documents $HOME/Documents \<br />
<br />
bash-4.4$ ls -a<br />
. .. .Xauthority Desktop<br />
<br />
* A tmpfs filesystem is created after the bind mounting of {{Ic|.Xauthority}} and overlays it so that only the ''Documents'' directory is visible within the sandbox:<br />
<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/Desktop $HOME/Desktop \<br />
<br />
bash-4.4$ ls -a<br />
. .. Desktop<br />
<br />
===p7zip===<br />
Applications which have not yet been patched against [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9296 known vulnerabilities] constitute prime candidates for bubblewrapping:<br />
<br />
* Bind as read-only the host {{ic|/usr/bin/7za}} executable path to the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Blacklist the sandboxed contents of {{ic|/usr/lib/modules}} and {{ic|/usr/lib/systemd}} with tmpfs overlays<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Bind as read-write the host {{ic|/sandbox}} directory to the {{ic|/sandbox}} directory in the sandbox<br />
** ''7za'' will only run in the host {{ic|/sandbox}} directory and/or its subdirectories when called from the shell wrapper<br />
* Create new cgroup/IPC/network/PID/UTS namespaces for the application and its processes<br />
** If the kernel does not support non-privileged user namespaces, skip its creation and continue<br />
** Creation of a new network namespace prevents the sandbox from obtaining network access <br />
* Add a custom or an arbitrary [[Network_configuration#Set_the_hostname|hostname]] to the sandbox such as {{ic|p7zip}}<br />
* Unset the {{ic|XAUTHORITY}} [[Environment_variables|environment variable]] to hide the location of the X11 connection cookie<br />
** ''7za'' does not need to connect to an X11 display server to function properly<br />
* Start a new terminal session to prevent keyboard input from escaping the sandbox <br />
<br />
#!/bin/sh<br />
#~/bwrap/pz7ip.sh<br />
(exec bwrap \<br />
--ro-bind /usr/bin/7za /usr/bin/7za \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/modules \<br />
--tmpfs /usr/lib/systemd \<br />
--dev /dev \<br />
--bind /sandbox /sandbox \<br />
--unshare-all \<br />
--hostname p7zip \<br />
--unsetenv XAUTHORITY \<br />
--new-session \<br />
/usr/bin/7za "$@")<br />
<br />
{{Note|''/usr/bin/sh'' and ''/usr/bin/ls'' must reside in the executable path in order to traverse and verify the sandbox filesystem.}}<br />
<br />
bwrap \<br />
--ro-bind /usr/bin/7za /usr/bin/7za \<br />
'''--ro-bind /usr/bin/ls /usr/bin/ls \'''<br />
'''--ro-bind /usr/bin/sh /usr/bin/sh \'''<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/modules \<br />
--tmpfs /usr/lib/systemd \<br />
--dev /dev \<br />
--bind /sandbox /sandbox \<br />
--unshare-all \<br />
--hostname p7zip \<br />
--unsetenv XAUTHORITY \<br />
--new-session \<br />
/usr/bin/sh<br />
bash: no job control in this shell<br />
bash-4.4$ ls -AF <br />
dev/ lib64@ usr/<br />
bash-4.4$ ls -l /usr/lib/modules <br />
total 0<br />
bash-4.4$ ls -l /usr/lib/systemd<br />
total 0<br />
bash-4.4$ ls -AF /dev<br />
console full null ptmx@ pts/ random shm/ stderr@ stdin@ stdout@ tty urandom zero<br />
bash-4.4$ ls -A /usr/bin<br />
7za ls sh<br />
<br />
===Filesystem isolation===<br />
<br />
{{Warning|It is the bubblewrap user’s responsibility to update the filesystem trees regularly.}}<br />
<br />
To further hide the contents of the file system (such as those in {{ic|/var}}, {{ic|/usr/bin}} and {{ic|/usr/lib}}) and to sandbox even the installation of software, pacman can be made to install Arch packages into isolated filesystem trees.<br />
<br />
In order to use pacman for installing software into the filesystem trees, you will need to install {{Pkg|fakeroot}} and {{Pkg|fakechroot}}.<br />
<br />
Suppose you want to install the {{ic|xterm}} package with pacman into an isolated filesystem tree. You should prepare your tree like this:<br />
<br />
$ MYPACKAGE=xterm<br />
$ mkdir -p ~/sandboxes/${MYPACKAGE}/files/var/lib/pacman<br />
$ mkdir -p ~/sandboxes/${MYPACKAGE}/files/etc<br />
$ cp /etc/pacman.conf ~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf<br />
<br />
You may want to edit {{ic|~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf}} and adjust the pacman configuration used:<br />
<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
* You may need to remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
<br />
Then install the {{ic|base}} group along with the needed fakeroot into the isolated filesystem tree:<br />
<br />
$ fakechroot fakeroot pacman -Syu \<br />
--root ~/sandboxes/${MYPACKAGE}/files \<br />
--dbpath ~/sandboxes/${MYPACKAGE}/files/var/lib/pacman \<br />
--config ~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf \<br />
base fakeroot<br />
<br />
Since you will be repeatedly calling bubblewrap with the same options, make an alias:<br />
<br />
$ alias bw-install='bwrap \<br />
--bind ~/sandboxes/${MYPACKAGE}/files/ / \<br />
--ro-bind /etc/resolv.conf /etc/resolv.conf \<br />
--tmpfs /tmp \<br />
--proc /proc \<br />
--dev /dev \<br />
--chdir / '<br />
<br />
You will need to set up the [[Locale|locales]]:<br />
<br />
$ nano -w ~/sandboxes/${MYPACKAGE}/files/etc/locale.gen<br />
$ bw-install locale-gen<br />
<br />
Then set up pacman’s keyring:<br />
<br />
$ bw-install fakeroot pacman-key --init<br />
$ bw-install fakeroot pacman-key --populate archlinux<br />
<br />
Now you can install the desired {{ic|xterm}} package.<br />
<br />
$ bw-install fakeroot pacman -S ${MYPACKAGE}<br />
<br />
If the pacman command fails here, try running the command for populating the keyring again.<br />
<br />
Congratulations. You now have an isolated filesystem tree containing {{ic|xterm}}. You can use {{ic|bw-install}} again to upgrade your filesystem tree.<br />
<br />
You can now run your software with bubblewrap. {{ic|''command''}} should be {{ic|xterm}} in this case.<br />
<br />
$ bwrap \<br />
--ro-bind ~/sandboxes/${MYPACKAGE}/files/ / \<br />
--ro-bind /etc/resolv.conf /etc/resolv.conf \<br />
--tmpfs /tmp \<br />
--proc /proc \<br />
--dev /dev \<br />
--chdir / \<br />
''command''<br />
<br />
Note that some files can be shared between packages. You can hardlink to all files of an existing parent filesystem tree to reuse them in a new tree:<br />
<br />
$ cp -al ~/sandboxes/${MYPARENTPACKAGE} ~/sandboxes/${MYPACKAGE}<br />
<br />
Then proceed with the installation as usual by calling pacman from {{ic|bw-install fakechroot fakeroot pacman …}}.<br />
<br />
==Troubleshooting==<br />
===Using X11===<br />
Bind mounting the host X11 socket to an alternative X11 socket may not work:<br />
--bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X8 --setenv DISPLAY :8<br />
A workaround is to bind mount the host X11 socket to the same socket within the sandbox:<br />
--bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 --setenv DISPLAY :0<br />
<br />
===Sandboxing X11===<br />
<br />
While bwrap provides some very nice isolation for sandboxed application, there is an easy escape as long as access to the X11 socket is available.<br />
X11 does not include isolation between applications and is completely insecure. The only solution to this is to switch to a wayland compositor with no access to the Xserver from the sandbox.<br />
<br />
There are however some workarounds that use xpra or xephyr to run in a new X11 environment. This would work with bwrap as well.<br />
<br />
To test X11 isolation, run 'xinput test <id>' where <id> is your keyboard id shich you can find with 'xinput list'<br />
When run without additional X11 isolation, this will show that any application with X11 access can capture keyboard input of any other application, which is basically what a keylogger would do.<br />
<br />
<br />
===New Session===<br />
<br />
There is a security issue with TIOCSTI, (CVE-2017-522) which allows sandbox escape.<br />
To prevent this, bubblewrap has introduced the new option '--new-session' which calls setsid(). <br />
However this causes some behavioural issues that are hard to work with in some cases. <br />
For instance, it makes shell job control not work for the bwrap command.<br />
<br />
It is recommended to use this if possible, but if not the developers recommend that the issue is neutralized in some other way, for instance using SECCOMP, which is what flatpak does:<br />
https://github.com/flatpak/flatpak/commit/902fb713990a8f968ea4350c7c2a27ff46f1a6c4<br />
<br />
==See also==<br />
* [https://github.com/projectatomic/bubblewrap bubblewrap GitHub project page]<br />
* [https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt The Linux Kernel Archives: SECure COMPuting with filters]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Bubblewrap&diff=468302Bubblewrap2017-02-14T07:30:14Z<p>Pelzflorian: Warn users about security</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Kernel]]<br />
[[Category:Security]]<br />
[[ja:Bubblewrap]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|Flatpak}}<br />
{{Related articles end}}<br />
[https://github.com/projectatomic/bubblewrap bubblewrap] is a lightweight [[wikipedia:Setuid|setuid]] sandbox application developed from [[wikipedia:Flatpak|Flatpak]] with a small installation footprint and minimal resource requirements. While the application package is named bubblewrap, the actual executable binary and manpage reference is ''bwrap''. bubblewrap is expected to [https://blog.torproject.org/blog/q-and-yawning-angel anchor the sandbox mechanism] of the [https://www.torproject.org/projects/torbrowser.html Tor Browser] (Linux) in the future. Notable features include support for cgroup/IPC/mount/network/PID/user/UTS [[wikipedia:Linux_namespaces|namespaces]] and [[wikipedia:Seccomp|seccomp]] filtering. Note that bubblewrap drops all [[Capabilities|capabilities]] within a sandbox and that child tasks cannot gain greater privileges than its parent. Notable feature exclusions include the lack of explicit support for blacklisting/whitelisting file paths. <br />
<br />
{{Warning|Unlike when using a separate user, bubblewrap not only exposes security vulnerabilities in the kernel but also in the window compositor. Users should be aware that running untrustworthy code in bubblewrap is still not safe.}}<br />
<br />
==Installation==<br />
[[Install]] {{Pkg|bubblewrap}} or {{AUR|bubblewrap-git}}.<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel per [https://bugs.archlinux.org/task/36969 FS#36969]. This prevents the kernel from exposing user namespaces as a means to accomodate separate user information for separate virtualized services. An example would be running ''syslog'' in a namespace with a UID and GID different than that of the host system. The {{Pkg|linux-grsec}} package sets {{ic|1=CONFIG_USER_NS=y}} but restricts it's use to privileged users for security reasons. It is a viable alternative to the stock kernel if the ability to create user namepaces is desired.}}<br />
<br />
==Configuration==<br />
bubblewrap can be called directly from the command-line and/or within [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh shell scripts] as part of a [https://github.com/projectatomic/bubblewrap/blob/master/demos/flatpak-run.sh complex wrapper]. Unlike applications such as [[Firejail]] which automatically set {{Ic|/var}} and {{Ic|/etc}} to read-only within the sandbox, bubblewrap makes no such operating assumptions. It is up to the user to determine which configuration options to pass in accordance to the application being sandboxed. bubblewrap does not automatically create user namespaces when running with setuid privileges and can accomodate typical environment variables including {{Ic|$HOME}} and {{Ic|$USER}}.<br />
<br />
==Usage examples==<br />
<br />
===Bash===<br />
Create a simple [[Bash]] sandbox: <br />
* Determine available kernel namespaces<br />
$ ls /proc/self/ns <br />
cgroup ipc mnt net pid user uts<br />
{{Note|The presence of {{Ic|user}} indicates that the kernel has exposed support for user namespaces with {{ic|1=CONFIG_USER_NS=y}}}}<br />
* Bind as read-only the entire host {{ic|/}} directory to {{ic|/}} in the sandbox <br />
* Create a new user namespace and set the [[wikipedia:User_identifier|user ID]] to {{ic|256}} and the [[wikipedia:Group_identifier|group ID]] to {{Ic|512}}<br />
$ bwrap --ro-bind / / --unshare-user --uid 256 --gid 512 bash<br />
bash-4.4$ id<br />
uid=256 gid=512 groups=512,65534(nobody)<br />
bash-4.4$ ls -l /usr/bin/bash<br />
-rwxr-xr-x 1 nobody nobody 811752 2017-01-01 04:20 /usr/bin/bash<br />
<br />
===dhcpcd===<br />
Create a simple [[dhcpcd]] sandbox: <br />
* Determine available kernel namespaces<br />
$ ls /proc/self/ns <br />
cgroup ipc mnt net pid uts<br />
{{Note|The absence of {{Ic|user}} indicates that the kernel has been built with {{ic|1=CONFIG_USER_NS=n}} or is user namespace restricted.}}<br />
<br />
* Bind as read-write the entire host {{ic|/}} directory to {{ic|/}} in the sandbox <br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create new [[wikipedia:Inter-process_communication|IPC]] and [[Cgroups|control group]] namespaces<br />
* Create a new UTS namespace and set {{ic|dhcpcd}} as the hostname<br />
<br />
# /usr/bin/bwrap --bind / / --dev /dev --unshare-ipc --unshare-cgroup --unshare-uts --hostname dhcpcd /usr/bin/dhcpcd -q -b<br />
<br />
===Unbound===<br />
Create a more granular and complex [[Unbound]] sandbox: <br />
* Bind as read-only the system {{ic|/usr}} directory to {{ic|/usr}} in the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Bind as read-only the system {{ic|/etc}} directory to {{ic|/etc}} in the sandbox<br />
* Create empty {{ic|/var}} and {{ic|/run}} directories within the sandbox<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create new IPC and [[wikipedia:Process_identifier|PID]] and control group namespaces<br />
* Create a new UTS namespace and set {{ic|unbound}} as the hostname<br />
<br />
# /usr/bin/bwrap --ro-bind /usr /usr --symlink usr/lib /lib64 --ro-bind /etc /etc --dir /var --dir /run --dev /dev --unshare-ipc --unshare-pid --unshare-cgroup --unshare-uts --hostname unbound /usr/bin/unbound -d<br />
<br />
{{Tip|See [[systemd#Editing provided units]] to enable the bubblewrapping of systemd unit files including {{ic|unbound.service}}}}<br />
<br />
===Desktop===<br />
Leverage bubblewrap within [[Desktop entries|desktop entries]]:<br />
* Bind as read-write the entire host {{ic|/}} directory to {{ic|/}} in the sandbox<br />
* Re-bind as read-only the {{ic|/var}} and {{ic|/etc}} directories in the sandbox<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create a tmpfs filesystem over the sandboxed {{ic|/run}} directory<br />
* Disable network access by creating new network namespace<br />
<br />
[Desktop Entry]<br />
Name=nano Editor<br />
Exec=bwrap --bind / / --dev /dev --tmpfs /run --unshare-net st -e nano -o . %f<br />
Type=Application<br />
MimeType=text/plain;<br />
{{Note|{{Ic|--dev /dev}} is required to write to {{Ic|/dev/pty}}}}<br />
<br />
* Example MuPDF desktop entry incorporating a {{Ic|mupdf.sh}} shell wrapper:<br />
<br />
[Desktop Entry]<br />
Name=MuPDF<br />
Exec=mupdf.sh %f<br />
Icon=application-pdf.svg<br />
Type=Application<br />
MimeType=application/pdf;application/x-pdf;<br />
<br />
{{Note|Ensure that {{Ic|mupdf.sh}} is located within your executable PATH e.g. {{Ic|1=PATH=$PATH:$HOME/bwrap}}}}<br />
<br />
===MuPDF===<br />
The power and flexibility of ''bwrap'' is best revealed when used to create an environment within a shell wrapper:<br />
<br />
* Bind as read-only the host {{ic|/usr/bin}} directory to {{ic|/usr/bin}} in the sandbox <br />
* Bind as read-only the host {{ic|/usr/lib}} directory to {{ic|/usr/lib}} in the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Create a [[tmpfs]] filesystem overlaying {{ic|/usr/lib/gcc}} in the sandbox<br />
** This effectively [[wikipedia:Blacklist_(computing)|blacklists]] the contents of {{ic|/usr/lib/gcc}} from appearing in the sandbox<br />
* Create a new tmpfs filesystem as the {{ic|$HOME}} directory in the sandbox<br />
* Bind as read-only an {{Ic|.Xauthority}} file and ''Documents'' directory into the sandbox<br />
** This effectively whitelists the {{Ic|.Xauthority}} file and ''Documents'' directory with recursion<br />
* Create a new tmpfs filesystem as the {{ic|/tmp}} directory in the sandbox<br />
* Whitelist the [[wikipedia:X_Window_System|X11]] socket by binding it into the sandbox as read-only<br />
* Clone and create private containers for all namespaces supported by the running kernel<br />
** If the kernel does not support non-privileged user namespaces, skip its creation and continue<br />
* Do not place network components into a private namespace<br />
** This allows for network access to follow URI hyperlinks<br />
<br />
#!/bin/sh<br />
#~/bwrap/mupdf.sh<br />
(exec bwrap \<br />
--ro-bind /usr/bin /usr/bin \<br />
--ro-bind /usr/lib /usr/lib \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/gcc \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Documents $HOME/Documents \<br />
--tmpfs /tmp \<br />
--ro-bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 \<br />
--unshare-all \<br />
--share-net \<br />
/usr/bin/mupdf "$@")<br />
<br />
{{Tip|Execute a shell wrapper substituting the existing executable with ''/usr/bin/sh'' to debug and verify the contents and filesystem structure of the sandbox.}}<br />
<br />
$ bwrap \<br />
--ro-bind /usr/bin /usr/bin \<br />
--ro-bind /usr/lib /usr/lib \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/gcc \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Desktop $HOME/Desktop \<br />
--tmpfs /tmp \<br />
--ro-bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 \<br />
--unshare-all \<br />
--share-net \<br />
/usr/bin/sh<br />
bash-4.4$ ls -AF<br />
.Xauthority Documents/<br />
<br />
Perhaps the most important rule to consider when building a bubblewrapped filesystem is that ''commands are executed in the order they appear''. From the [http://mupdf.com/ MuPDF] example above:<br />
<br />
* A tmpfs system is created followed by the bind mounting of an {{Ic|.Xauthority}} file and a ''Documents'' directory:<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Documents $HOME/Documents \<br />
<br />
bash-4.4$ ls -a<br />
. .. .Xauthority Desktop<br />
<br />
* A tmpfs filesystem is created after the bind mounting of {{Ic|.Xauthority}} and overlays it so that only the ''Documents'' directory is visible within the sandbox:<br />
<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/Desktop $HOME/Desktop \<br />
<br />
bash-4.4$ ls -a<br />
. .. Desktop<br />
<br />
===p7zip===<br />
Applications which have not yet been patched against [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9296 known vulnerabilities] constitute prime candidates for bubblewrapping:<br />
<br />
* Bind as read-only the host {{ic|/usr/bin/7za}} executable path to the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Blacklist the sandboxed contents of {{ic|/usr/lib/modules}} and {{ic|/usr/lib/systemd}} with tmpfs overlays<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Bind as read-write the host {{ic|/sandbox}} directory to the {{ic|/sandbox}} directory in the sandbox<br />
** ''7za'' will only run in the host {{ic|/sandbox}} directory and/or its subdirectories when called from the shell wrapper<br />
* Create new cgroup/IPC/network/PID/UTS namespaces for the application and its processes<br />
** If the kernel does not support non-privileged user namespaces, skip its creation and continue<br />
** Creation of a new network namespace prevents the sandbox from obtaining network access <br />
* Add a custom or an arbitrary [[Network_configuration#Set_the_hostname|hostname]] to the sandbox such as {{ic|p7zip}}<br />
* Unset the {{ic|XAUTHORITY}} [[Environment_variables|environment variable]] to hide the location of the X11 connection cookie<br />
** ''7za'' does not need to connect to an X11 display server to function properly<br />
* Start a new terminal session to prevent keyboard input from escaping the sandbox <br />
<br />
#!/bin/sh<br />
#~/bwrap/pz7ip.sh<br />
(exec bwrap \<br />
--ro-bind /usr/bin/7za /usr/bin/7za \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/modules \<br />
--tmpfs /usr/lib/systemd \<br />
--dev /dev \<br />
--bind /sandbox /sandbox \<br />
--unshare-all \<br />
--hostname p7zip \<br />
--unsetenv XAUTHORITY \<br />
--new-session \<br />
/usr/bin/7za "$@")<br />
<br />
{{Note|''/usr/bin/sh'' and ''/usr/bin/ls'' must reside in the executable path in order to traverse and verify the sandbox filesystem.}}<br />
<br />
bwrap \<br />
--ro-bind /usr/bin/7za /usr/bin/7za \<br />
'''--ro-bind /usr/bin/ls /usr/bin/ls \'''<br />
'''--ro-bind /usr/bin/sh /usr/bin/sh \'''<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/modules \<br />
--tmpfs /usr/lib/systemd \<br />
--dev /dev \<br />
--bind /sandbox /sandbox \<br />
--unshare-all \<br />
--hostname p7zip \<br />
--unsetenv XAUTHORITY \<br />
--new-session \<br />
/usr/bin/sh<br />
bash: no job control in this shell<br />
bash-4.4$ ls -AF <br />
dev/ lib64@ usr/<br />
bash-4.4$ ls -l /usr/lib/modules <br />
total 0<br />
bash-4.4$ ls -l /usr/lib/systemd<br />
total 0<br />
bash-4.4$ ls -AF /dev<br />
console full null ptmx@ pts/ random shm/ stderr@ stdin@ stdout@ tty urandom zero<br />
bash-4.4$ ls -A /usr/bin<br />
7za ls sh<br />
<br />
===Filesystem isolation===<br />
<br />
{{Warning|It is the bubblewrap user’s responsibility to update the filesystem trees regularly.}}<br />
<br />
To further hide the contents of the file system (such as those in {{ic|/var}}, {{ic|/usr/bin}} and {{ic|/usr/lib}}) and to sandbox even the installation of software, pacman can be made to install Arch packages into isolated filesystem trees.<br />
<br />
In order to use pacman for installing software into the filesystem trees, you will need to install {{Pkg|fakeroot}} and {{Pkg|fakechroot}}.<br />
<br />
Suppose you want to install the {{ic|xterm}} package with pacman into an isolated filesystem tree. You should prepare your tree like this:<br />
<br />
$ MYPACKAGE=xterm<br />
$ mkdir -p ~/sandboxes/${MYPACKAGE}/files/var/lib/pacman<br />
$ mkdir -p ~/sandboxes/${MYPACKAGE}/files/etc<br />
$ cp /etc/pacman.conf ~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf<br />
<br />
You may want to edit {{ic|~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf}} and adjust the pacman configuration used:<br />
<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
* You may need to remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
<br />
Then install the {{ic|base}} group along with the needed fakeroot into the isolated filesystem tree:<br />
<br />
$ fakechroot fakeroot pacman -Syu \<br />
--root ~/sandboxes/${MYPACKAGE}/files \<br />
--dbpath ~/sandboxes/${MYPACKAGE}/files/var/lib/pacman \<br />
--config ~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf \<br />
base fakeroot<br />
<br />
Since you will be repeatedly calling bubblewrap with the same options, make an alias:<br />
<br />
$ alias bw-install='bwrap \<br />
--bind ~/sandboxes/${MYPACKAGE}/files/ / \<br />
--ro-bind /etc/resolv.conf /etc/resolv.conf \<br />
--tmpfs /tmp \<br />
--proc /proc \<br />
--dev /dev \<br />
--chdir / '<br />
<br />
You will need to set up the [[Locale|locales]]:<br />
<br />
$ nano -w ~/sandboxes/${MYPACKAGE}/files/etc/locale.gen<br />
$ bw-install locale-gen<br />
<br />
Then set up pacman’s keyring:<br />
<br />
$ bw-install fakeroot pacman-key --init<br />
$ bw-install fakeroot pacman-key --populate archlinux<br />
<br />
Now you can install the desired {{ic|xterm}} package.<br />
<br />
$ bw-install fakeroot pacman -S ${MYPACKAGE}<br />
<br />
If the pacman command fails here, try running the command for populating the keyring again.<br />
<br />
Congratulations. You now have an isolated filesystem tree containing {{ic|xterm}}. You can use {{ic|bw-install}} again to upgrade your filesystem tree.<br />
<br />
You can now run your software with bubblewrap. {{ic|''command''}} should be {{ic|xterm}} in this case.<br />
<br />
$ bwrap \<br />
--ro-bind ~/sandboxes/${MYPACKAGE}/files/ / \<br />
--ro-bind /etc/resolv.conf /etc/resolv.conf \<br />
--tmpfs /tmp \<br />
--proc /proc \<br />
--dev /dev \<br />
--chdir / \<br />
''command''<br />
<br />
Note that some files can be shared between packages. You can hardlink to all files of an existing parent filesystem tree to reuse them in a new tree:<br />
<br />
$ cp -al ~/sandboxes/${MYPARENTPACKAGE} ~/sandboxes/${MYPACKAGE}<br />
<br />
Then proceed with the installation as usual by calling pacman from {{ic|bw-install fakechroot fakeroot pacman …}}.<br />
<br />
==Troubleshooting==<br />
===Using X11===<br />
Bind mounting the host X11 socket to an alternative X11 socket may not work:<br />
--bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X8 --setenv DISPLAY :8<br />
A workaround is to bind mount the host X11 socket to the same socket within the sandbox:<br />
--bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 --setenv DISPLAY :0<br />
<br />
===Sandboxing X11===<br />
<br />
While bwrap provides some very nice isolation for sandboxed application, there is an easy escape as long as access to the X11 socket is available.<br />
X11 does not include isolation between applications and is completely insecure. The only solution to this is to switch to a wayland compositor with no access to the Xserver from the sandbox.<br />
<br />
There are however some workarounds that use xpra or xephyr to run in a new X11 environment. This would work with bwrap as well.<br />
<br />
To test X11 isolation, run 'xinput test <id>' where <id> is your keyboard id shich you can find with 'xinput list'<br />
When run without additional X11 isolation, this will show that any application with X11 access can capture keyboard input of any other application, which is basically what a keylogger would do.<br />
<br />
<br />
===New Session===<br />
<br />
There is a security issue with TIOCSTI, (CVE-2017-522) which allows sandbox escape.<br />
To prevent this, bubblewrap has introduced the new option '--new-session' which calls setsid(). <br />
However this causes some behavioural issues that are hard to work with in some cases. <br />
For instance, it makes shell job control not work for the bwrap command.<br />
<br />
It is recommended to use this if possible, but if not the developers recommend that the issue is neutralized in some other way, for instance using SECCOMP, which is what flatpak does:<br />
https://github.com/flatpak/flatpak/commit/902fb713990a8f968ea4350c7c2a27ff46f1a6c4<br />
<br />
==See also==<br />
* [https://github.com/projectatomic/bubblewrap bubblewrap GitHub project page]<br />
* [https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt The Linux Kernel Archives: SECure COMPuting with filters]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Bubblewrap&diff=468301Bubblewrap2017-02-14T07:16:54Z<p>Pelzflorian: Filesystem trees</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Kernel]]<br />
[[Category:Security]]<br />
[[ja:Bubblewrap]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|Flatpak}}<br />
{{Related articles end}}<br />
[https://github.com/projectatomic/bubblewrap bubblewrap] is a lightweight [[wikipedia:Setuid|setuid]] sandbox application developed from [[wikipedia:Flatpak|Flatpak]] with a small installation footprint and minimal resource requirements. While the application package is named bubblewrap, the actual executable binary and manpage reference is ''bwrap''. bubblewrap is expected to [https://blog.torproject.org/blog/q-and-yawning-angel anchor the sandbox mechanism] of the [https://www.torproject.org/projects/torbrowser.html Tor Browser] (Linux) in the future. Notable features include support for cgroup/IPC/mount/network/PID/user/UTS [[wikipedia:Linux_namespaces|namespaces]] and [[wikipedia:Seccomp|seccomp]] filtering. Note that bubblewrap drops all [[Capabilities|capabilities]] within a sandbox and that child tasks cannot gain greater privileges than its parent. Notable feature exclusions include the lack of explicit support for blacklisting/whitelisting file paths. <br />
<br />
==Installation==<br />
[[Install]] {{Pkg|bubblewrap}} or {{AUR|bubblewrap-git}}.<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel per [https://bugs.archlinux.org/task/36969 FS#36969]. This prevents the kernel from exposing user namespaces as a means to accomodate separate user information for separate virtualized services. An example would be running ''syslog'' in a namespace with a UID and GID different than that of the host system. The {{Pkg|linux-grsec}} package sets {{ic|1=CONFIG_USER_NS=y}} but restricts it's use to privileged users for security reasons. It is a viable alternative to the stock kernel if the ability to create user namepaces is desired.}}<br />
<br />
==Configuration==<br />
bubblewrap can be called directly from the command-line and/or within [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh shell scripts] as part of a [https://github.com/projectatomic/bubblewrap/blob/master/demos/flatpak-run.sh complex wrapper]. Unlike applications such as [[Firejail]] which automatically set {{Ic|/var}} and {{Ic|/etc}} to read-only within the sandbox, bubblewrap makes no such operating assumptions. It is up to the user to determine which configuration options to pass in accordance to the application being sandboxed. bubblewrap does not automatically create user namespaces when running with setuid privileges and can accomodate typical environment variables including {{Ic|$HOME}} and {{Ic|$USER}}.<br />
<br />
==Usage examples==<br />
<br />
===Bash===<br />
Create a simple [[Bash]] sandbox: <br />
* Determine available kernel namespaces<br />
$ ls /proc/self/ns <br />
cgroup ipc mnt net pid user uts<br />
{{Note|The presence of {{Ic|user}} indicates that the kernel has exposed support for user namespaces with {{ic|1=CONFIG_USER_NS=y}}}}<br />
* Bind as read-only the entire host {{ic|/}} directory to {{ic|/}} in the sandbox <br />
* Create a new user namespace and set the [[wikipedia:User_identifier|user ID]] to {{ic|256}} and the [[wikipedia:Group_identifier|group ID]] to {{Ic|512}}<br />
$ bwrap --ro-bind / / --unshare-user --uid 256 --gid 512 bash<br />
bash-4.4$ id<br />
uid=256 gid=512 groups=512,65534(nobody)<br />
bash-4.4$ ls -l /usr/bin/bash<br />
-rwxr-xr-x 1 nobody nobody 811752 2017-01-01 04:20 /usr/bin/bash<br />
<br />
===dhcpcd===<br />
Create a simple [[dhcpcd]] sandbox: <br />
* Determine available kernel namespaces<br />
$ ls /proc/self/ns <br />
cgroup ipc mnt net pid uts<br />
{{Note|The absence of {{Ic|user}} indicates that the kernel has been built with {{ic|1=CONFIG_USER_NS=n}} or is user namespace restricted.}}<br />
<br />
* Bind as read-write the entire host {{ic|/}} directory to {{ic|/}} in the sandbox <br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create new [[wikipedia:Inter-process_communication|IPC]] and [[Cgroups|control group]] namespaces<br />
* Create a new UTS namespace and set {{ic|dhcpcd}} as the hostname<br />
<br />
# /usr/bin/bwrap --bind / / --dev /dev --unshare-ipc --unshare-cgroup --unshare-uts --hostname dhcpcd /usr/bin/dhcpcd -q -b<br />
<br />
===Unbound===<br />
Create a more granular and complex [[Unbound]] sandbox: <br />
* Bind as read-only the system {{ic|/usr}} directory to {{ic|/usr}} in the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Bind as read-only the system {{ic|/etc}} directory to {{ic|/etc}} in the sandbox<br />
* Create empty {{ic|/var}} and {{ic|/run}} directories within the sandbox<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create new IPC and [[wikipedia:Process_identifier|PID]] and control group namespaces<br />
* Create a new UTS namespace and set {{ic|unbound}} as the hostname<br />
<br />
# /usr/bin/bwrap --ro-bind /usr /usr --symlink usr/lib /lib64 --ro-bind /etc /etc --dir /var --dir /run --dev /dev --unshare-ipc --unshare-pid --unshare-cgroup --unshare-uts --hostname unbound /usr/bin/unbound -d<br />
<br />
{{Tip|See [[systemd#Editing provided units]] to enable the bubblewrapping of systemd unit files including {{ic|unbound.service}}}}<br />
<br />
===Desktop===<br />
Leverage bubblewrap within [[Desktop entries|desktop entries]]:<br />
* Bind as read-write the entire host {{ic|/}} directory to {{ic|/}} in the sandbox<br />
* Re-bind as read-only the {{ic|/var}} and {{ic|/etc}} directories in the sandbox<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Create a tmpfs filesystem over the sandboxed {{ic|/run}} directory<br />
* Disable network access by creating new network namespace<br />
<br />
[Desktop Entry]<br />
Name=nano Editor<br />
Exec=bwrap --bind / / --dev /dev --tmpfs /run --unshare-net st -e nano -o . %f<br />
Type=Application<br />
MimeType=text/plain;<br />
{{Note|{{Ic|--dev /dev}} is required to write to {{Ic|/dev/pty}}}}<br />
<br />
* Example MuPDF desktop entry incorporating a {{Ic|mupdf.sh}} shell wrapper:<br />
<br />
[Desktop Entry]<br />
Name=MuPDF<br />
Exec=mupdf.sh %f<br />
Icon=application-pdf.svg<br />
Type=Application<br />
MimeType=application/pdf;application/x-pdf;<br />
<br />
{{Note|Ensure that {{Ic|mupdf.sh}} is located within your executable PATH e.g. {{Ic|1=PATH=$PATH:$HOME/bwrap}}}}<br />
<br />
===MuPDF===<br />
The power and flexibility of ''bwrap'' is best revealed when used to create an environment within a shell wrapper:<br />
<br />
* Bind as read-only the host {{ic|/usr/bin}} directory to {{ic|/usr/bin}} in the sandbox <br />
* Bind as read-only the host {{ic|/usr/lib}} directory to {{ic|/usr/lib}} in the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Create a [[tmpfs]] filesystem overlaying {{ic|/usr/lib/gcc}} in the sandbox<br />
** This effectively [[wikipedia:Blacklist_(computing)|blacklists]] the contents of {{ic|/usr/lib/gcc}} from appearing in the sandbox<br />
* Create a new tmpfs filesystem as the {{ic|$HOME}} directory in the sandbox<br />
* Bind as read-only an {{Ic|.Xauthority}} file and ''Documents'' directory into the sandbox<br />
** This effectively whitelists the {{Ic|.Xauthority}} file and ''Documents'' directory with recursion<br />
* Create a new tmpfs filesystem as the {{ic|/tmp}} directory in the sandbox<br />
* Whitelist the [[wikipedia:X_Window_System|X11]] socket by binding it into the sandbox as read-only<br />
* Clone and create private containers for all namespaces supported by the running kernel<br />
** If the kernel does not support non-privileged user namespaces, skip its creation and continue<br />
* Do not place network components into a private namespace<br />
** This allows for network access to follow URI hyperlinks<br />
<br />
#!/bin/sh<br />
#~/bwrap/mupdf.sh<br />
(exec bwrap \<br />
--ro-bind /usr/bin /usr/bin \<br />
--ro-bind /usr/lib /usr/lib \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/gcc \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Documents $HOME/Documents \<br />
--tmpfs /tmp \<br />
--ro-bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 \<br />
--unshare-all \<br />
--share-net \<br />
/usr/bin/mupdf "$@")<br />
<br />
{{Tip|Execute a shell wrapper substituting the existing executable with ''/usr/bin/sh'' to debug and verify the contents and filesystem structure of the sandbox.}}<br />
<br />
$ bwrap \<br />
--ro-bind /usr/bin /usr/bin \<br />
--ro-bind /usr/lib /usr/lib \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/gcc \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Desktop $HOME/Desktop \<br />
--tmpfs /tmp \<br />
--ro-bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 \<br />
--unshare-all \<br />
--share-net \<br />
/usr/bin/sh<br />
bash-4.4$ ls -AF<br />
.Xauthority Documents/<br />
<br />
Perhaps the most important rule to consider when building a bubblewrapped filesystem is that ''commands are executed in the order they appear''. From the [http://mupdf.com/ MuPDF] example above:<br />
<br />
* A tmpfs system is created followed by the bind mounting of an {{Ic|.Xauthority}} file and a ''Documents'' directory:<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--ro-bind $HOME/Documents $HOME/Documents \<br />
<br />
bash-4.4$ ls -a<br />
. .. .Xauthority Desktop<br />
<br />
* A tmpfs filesystem is created after the bind mounting of {{Ic|.Xauthority}} and overlays it so that only the ''Documents'' directory is visible within the sandbox:<br />
<br />
--ro-bind $HOME/.Xauthority $HOME/.Xauthority \<br />
--tmpfs $HOME \<br />
--ro-bind $HOME/Desktop $HOME/Desktop \<br />
<br />
bash-4.4$ ls -a<br />
. .. Desktop<br />
<br />
===p7zip===<br />
Applications which have not yet been patched against [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9296 known vulnerabilities] constitute prime candidates for bubblewrapping:<br />
<br />
* Bind as read-only the host {{ic|/usr/bin/7za}} executable path to the sandbox <br />
* Create a symbolic link from the system {{ic|/usr/lib}} directory to {{ic|/lib64}} in the sandbox <br />
* Blacklist the sandboxed contents of {{ic|/usr/lib/modules}} and {{ic|/usr/lib/systemd}} with tmpfs overlays<br />
* Mount a new devtmpfs filesystem to {{ic|/dev}} in the sandbox<br />
* Bind as read-write the host {{ic|/sandbox}} directory to the {{ic|/sandbox}} directory in the sandbox<br />
** ''7za'' will only run in the host {{ic|/sandbox}} directory and/or its subdirectories when called from the shell wrapper<br />
* Create new cgroup/IPC/network/PID/UTS namespaces for the application and its processes<br />
** If the kernel does not support non-privileged user namespaces, skip its creation and continue<br />
** Creation of a new network namespace prevents the sandbox from obtaining network access <br />
* Add a custom or an arbitrary [[Network_configuration#Set_the_hostname|hostname]] to the sandbox such as {{ic|p7zip}}<br />
* Unset the {{ic|XAUTHORITY}} [[Environment_variables|environment variable]] to hide the location of the X11 connection cookie<br />
** ''7za'' does not need to connect to an X11 display server to function properly<br />
* Start a new terminal session to prevent keyboard input from escaping the sandbox <br />
<br />
#!/bin/sh<br />
#~/bwrap/pz7ip.sh<br />
(exec bwrap \<br />
--ro-bind /usr/bin/7za /usr/bin/7za \<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/modules \<br />
--tmpfs /usr/lib/systemd \<br />
--dev /dev \<br />
--bind /sandbox /sandbox \<br />
--unshare-all \<br />
--hostname p7zip \<br />
--unsetenv XAUTHORITY \<br />
--new-session \<br />
/usr/bin/7za "$@")<br />
<br />
{{Note|''/usr/bin/sh'' and ''/usr/bin/ls'' must reside in the executable path in order to traverse and verify the sandbox filesystem.}}<br />
<br />
bwrap \<br />
--ro-bind /usr/bin/7za /usr/bin/7za \<br />
'''--ro-bind /usr/bin/ls /usr/bin/ls \'''<br />
'''--ro-bind /usr/bin/sh /usr/bin/sh \'''<br />
--symlink usr/lib /lib64 \<br />
--tmpfs /usr/lib/modules \<br />
--tmpfs /usr/lib/systemd \<br />
--dev /dev \<br />
--bind /sandbox /sandbox \<br />
--unshare-all \<br />
--hostname p7zip \<br />
--unsetenv XAUTHORITY \<br />
--new-session \<br />
/usr/bin/sh<br />
bash: no job control in this shell<br />
bash-4.4$ ls -AF <br />
dev/ lib64@ usr/<br />
bash-4.4$ ls -l /usr/lib/modules <br />
total 0<br />
bash-4.4$ ls -l /usr/lib/systemd<br />
total 0<br />
bash-4.4$ ls -AF /dev<br />
console full null ptmx@ pts/ random shm/ stderr@ stdin@ stdout@ tty urandom zero<br />
bash-4.4$ ls -A /usr/bin<br />
7za ls sh<br />
<br />
===Filesystem isolation===<br />
<br />
{{Warning|It is the bubblewrap user’s responsibility to update the filesystem trees regularly.}}<br />
<br />
To further hide the contents of the file system (such as those in {{ic|/var}}, {{ic|/usr/bin}} and {{ic|/usr/lib}}) and to sandbox even the installation of software, pacman can be made to install Arch packages into isolated filesystem trees.<br />
<br />
In order to use pacman for installing software into the filesystem trees, you will need to install {{Pkg|fakeroot}} and {{Pkg|fakechroot}}.<br />
<br />
Suppose you want to install the {{ic|xterm}} package with pacman into an isolated filesystem tree. You should prepare your tree like this:<br />
<br />
$ MYPACKAGE=xterm<br />
$ mkdir -p ~/sandboxes/${MYPACKAGE}/files/var/lib/pacman<br />
$ mkdir -p ~/sandboxes/${MYPACKAGE}/files/etc<br />
$ cp /etc/pacman.conf ~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf<br />
<br />
You may want to edit {{ic|~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf}} and adjust the pacman configuration used:<br />
<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
* You may need to remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
<br />
Then install the {{ic|base}} group along with the needed fakeroot into the isolated filesystem tree:<br />
<br />
$ fakechroot fakeroot pacman -Syu \<br />
--root ~/sandboxes/${MYPACKAGE}/files \<br />
--dbpath ~/sandboxes/${MYPACKAGE}/files/var/lib/pacman \<br />
--config ~/sandboxes/${MYPACKAGE}/files/etc/pacman.conf \<br />
base fakeroot<br />
<br />
Since you will be repeatedly calling bubblewrap with the same options, make an alias:<br />
<br />
$ alias bw-install='bwrap \<br />
--bind ~/sandboxes/${MYPACKAGE}/files/ / \<br />
--ro-bind /etc/resolv.conf /etc/resolv.conf \<br />
--tmpfs /tmp \<br />
--proc /proc \<br />
--dev /dev \<br />
--chdir / '<br />
<br />
You will need to set up the [[Locale|locales]]:<br />
<br />
$ nano -w ~/sandboxes/${MYPACKAGE}/files/etc/locale.gen<br />
$ bw-install locale-gen<br />
<br />
Then set up pacman’s keyring:<br />
<br />
$ bw-install fakeroot pacman-key --init<br />
$ bw-install fakeroot pacman-key --populate archlinux<br />
<br />
Now you can install the desired {{ic|xterm}} package.<br />
<br />
$ bw-install fakeroot pacman -S ${MYPACKAGE}<br />
<br />
If the pacman command fails here, try running the command for populating the keyring again.<br />
<br />
Congratulations. You now have an isolated filesystem tree containing {{ic|xterm}}. You can use {{ic|bw-install}} again to upgrade your filesystem tree.<br />
<br />
You can now run your software with bubblewrap. {{ic|''command''}} should be {{ic|xterm}} in this case.<br />
<br />
$ bwrap \<br />
--ro-bind ~/sandboxes/${MYPACKAGE}/files/ / \<br />
--ro-bind /etc/resolv.conf /etc/resolv.conf \<br />
--tmpfs /tmp \<br />
--proc /proc \<br />
--dev /dev \<br />
--chdir / \<br />
''command''<br />
<br />
Note that some files can be shared between packages. You can hardlink to all files of an existing parent filesystem tree to reuse them in a new tree:<br />
<br />
$ cp -al ~/sandboxes/${MYPARENTPACKAGE} ~/sandboxes/${MYPACKAGE}<br />
<br />
Then proceed with the installation as usual by calling pacman from {{ic|bw-install fakechroot fakeroot pacman …}}.<br />
<br />
==Troubleshooting==<br />
===Using X11===<br />
Bind mounting the host X11 socket to an alternative X11 socket may not work:<br />
--bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X8 --setenv DISPLAY :8<br />
A workaround is to bind mount the host X11 socket to the same socket within the sandbox:<br />
--bind /tmp/.X11-unix/X0 /tmp/.X11-unix/X0 --setenv DISPLAY :0<br />
<br />
===Sandboxing X11===<br />
<br />
While bwrap provides some very nice isolation for sandboxed application, there is an easy escape as long as access to the X11 socket is available.<br />
X11 does not include isolation between applications and is completely insecure. The only solution to this is to switch to a wayland compositor with no access to the Xserver from the sandbox.<br />
<br />
There are however some workarounds that use xpra or xephyr to run in a new X11 environment. This would work with bwrap as well.<br />
<br />
To test X11 isolation, run 'xinput test <id>' where <id> is your keyboard id shich you can find with 'xinput list'<br />
When run without additional X11 isolation, this will show that any application with X11 access can capture keyboard input of any other application, which is basically what a keylogger would do.<br />
<br />
<br />
===New Session===<br />
<br />
There is a security issue with TIOCSTI, (CVE-2017-522) which allows sandbox escape.<br />
To prevent this, bubblewrap has introduced the new option '--new-session' which calls setsid(). <br />
However this causes some behavioural issues that are hard to work with in some cases. <br />
For instance, it makes shell job control not work for the bwrap command.<br />
<br />
It is recommended to use this if possible, but if not the developers recommend that the issue is neutralized in some other way, for instance using SECCOMP, which is what flatpak does:<br />
https://github.com/flatpak/flatpak/commit/902fb713990a8f968ea4350c7c2a27ff46f1a6c4<br />
<br />
==See also==<br />
* [https://github.com/projectatomic/bubblewrap bubblewrap GitHub project page]<br />
* [https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt The Linux Kernel Archives: SECure COMPuting with filters]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Guix&diff=460153Guix2016-12-26T18:14:37Z<p>Pelzflorian: Modify unit file with `systemctl edit` (suggestion in AUR comment by AUR guix maintainer lantw44)</p>
<hr />
<div>[[Category:System administration]]<br />
{{Warning|Guix is '''not''' the [[pacman|official package manager of Arch]]. It is also still under heavy development. Some packages may currently fail to build on Arch.}}<br />
'''GNU Guix''' is a package manager that offers transactional, reproducible, per-user package management.<br />
While Guix can be used stand-alone and provide a full GNU distribution and a kernel by itself, you can install the Guix package manager on top of Arch to make Guix available to users while using a more traditional and mature Unix-like system as a base.<br />
<br />
See the [https://www.gnu.org/software/guix/manual Guix manual] for information on what per-user packaging commands Guix makes available to users.<br />
<br />
== Installation ==<br />
<br />
{{Expansion|The Guix reference manual says {{ic|nscd.service}} should be enabled but it is not clear if {{ic|nscd}} works properly on Arch or if it is even required.}}<br />
{{Note|The build check currently fails if {{ic|/bin/sh}} is not a link to bash, which is not a problem on a default Arch installation.}}<br />
<br />
GNU Guix is available in the AUR as {{AUR|guix}}. As described in the {{ic|PKGBUILD}}, the PGP key by the Guix distributor will need to be added first.<br />
<br />
== Running ==<br />
<br />
Guix makes builds more reproducible by running the build process using an unprivileged build user account. Therefore if you want to be able to build {{ic|''n''}} packages simultaneously (e.g. for serving multiple users at the same time) you should create {{ic|''n''}} build user accounts. as Guix should be able to build simultaneously. The following command does this the way described in [https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup Guix manual]:<br />
<br />
# groupadd --system guixbuild<br />
# for i in `seq -w 1 ''n''`;<br />
do<br />
useradd -g guixbuild -G guixbuild \<br />
-d /var/empty -s `which nologin` \<br />
-c "Guix build user $i" --system \<br />
guixbuilder$i;<br />
done<br />
<br />
[[Systemd#Using units|Start and enable]] {{ic|guix-daemon.service}}.<br />
<br />
You may want to authorize Guix to download and use binary packages (‘substitutes’) from [http://hydra.gnu.org Hydra]:<br />
<br />
# guix archive --authorize < /usr/share/guix/hydra.gnu.org.pub<br />
<br />
=== Building packages outside of {{ic|/tmp}} ===<br />
<br />
The unit file may need to be extended to use a different {{ic|TMPDIR}} for building if {{ic|/tmp}} does not provide enough space (see the [https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup Guix manual] for details). To use {{ic|''/tmpdir''}} for building instead of {{ic|/tmp}}, run<br />
<br />
# systemctl edit guix-daemon.service<br />
<br />
to add the following lines:<br />
<br />
{{bc|1=<br />
[Service]<br />
Environment=TMPDIR=''/tmpdir''<br />
}}<br />
<br />
== Uninstalling Guix ==<br />
<br />
Disable {{ic|guix-daemon.service}} and then remove Guix using [[pacman]]. Now remove all the Guix build users and their group:<br />
<br />
# for i in `seq -w 1 ''n''`; do userdel guixbuilder$i; done<br />
# groupdel guixbuild<br />
<br />
Then remove the Guix store {{ic|/gnu}} as well as {{ic|/var/guix}} and {{ic|/var/log/guix}}. If you edited {{ic|guix-daemon.service}}, you may want to remove {{ic|/etc/systemd/system/guix-daemon.service.d}} as well.</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Guix&diff=460151Guix2016-12-26T17:38:16Z<p>Pelzflorian: Also uninstall /var/log/guix (suggestion in AUR comment by AUR guix maintainer lantw44)</p>
<hr />
<div>[[Category:System administration]]<br />
{{Warning|Guix is '''not''' the [[pacman|official package manager of Arch]]. It is also still under heavy development. Some packages may currently fail to build on Arch.}}<br />
'''GNU Guix''' is a package manager that offers transactional, reproducible, per-user package management.<br />
While Guix can be used stand-alone and provide a full GNU distribution and a kernel by itself, you can install the Guix package manager on top of Arch to make Guix available to users while using a more traditional and mature Unix-like system as a base.<br />
<br />
See the [https://www.gnu.org/software/guix/manual Guix manual] for information on what per-user packaging commands Guix makes available to users.<br />
<br />
== Installation ==<br />
<br />
{{Expansion|The Guix reference manual says {{ic|nscd.service}} should be enabled but it is not clear if {{ic|nscd}} works properly on Arch or if it is even required.}}<br />
{{Note|The build check currently fails if {{ic|/bin/sh}} is not a link to bash, which is not a problem on a default Arch installation.}}<br />
<br />
GNU Guix is available in the AUR as {{AUR|guix}}. As described in the {{ic|PKGBUILD}}, the PGP key by the Guix distributor will need to be added first.<br />
<br />
== Running ==<br />
<br />
Guix makes builds more reproducible by running the build process using an unprivileged build user account. Therefore if you want to be able to build {{ic|''n''}} packages simultaneously (e.g. for serving multiple users at the same time) you should create {{ic|''n''}} build user accounts. as Guix should be able to build simultaneously. The following command does this the way described in [https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup Guix manual]:<br />
<br />
# groupadd --system guixbuild<br />
# for i in `seq -w 1 ''n''`;<br />
do<br />
useradd -g guixbuild -G guixbuild \<br />
-d /var/empty -s `which nologin` \<br />
-c "Guix build user $i" --system \<br />
guixbuilder$i;<br />
done<br />
<br />
[[Systemd#Using units|Start and enable]] {{ic|guix-daemon.service}}.<br />
<br />
You may want to authorize Guix to download and use binary packages (‘substitutes’) from [http://hydra.gnu.org Hydra]:<br />
<br />
# guix archive --authorize < /usr/share/guix/hydra.gnu.org.pub<br />
<br />
=== Building packages outside of {{ic|/tmp}} ===<br />
<br />
The unit file may need to be modified to use a different {{ic|TMPDIR}} for building if {{ic|/tmp}} does not provide enough space (see the [https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup Guix manual] for details). To use {{ic|''/tmpdir''}} for building instead of {{ic|/tmp}}, copy {{ic|/usr/lib/systemd/system/guix-daemon.service}} to {{ic|/etc/systemd/system/guix-daemon-custom.service}}, add a line<br />
<br />
{{hc|/etc/systemd/system/guix-daemon-custom.service|2=<br />
[Service]<br />
...<br />
Environment=TMPDIR=/tmpdir<br />
...<br />
}}<br />
<br />
and enable {{ic|guix-daemon-custom.service}} ''instead'' of {{ic|guix-daemon.service}}.<br />
<br />
== Uninstalling Guix ==<br />
<br />
Disable {{ic|guix-daemon.service}} (or {{ic|guix-daemon-custom.service}}) and then remove Guix using [[pacman]]. Now remove all the Guix build users and their group:<br />
<br />
# for i in `seq -w 1 ''n''`; do userdel guixbuilder$i; done<br />
# groupdel guixbuild<br />
<br />
Then remove the Guix store {{ic|/gnu}}, {{ic|/var/guix}} and {{ic|/var/log/guix}}. If you created a custom {{ic|guix-daemon-custom.service}}, you may want to remove it as well.</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Guix&diff=460150Guix2016-12-26T16:38:37Z<p>Pelzflorian: Fix: Arch is Unix-like, not a Unix system.</p>
<hr />
<div>[[Category:System administration]]<br />
{{Warning|Guix is '''not''' the [[pacman|official package manager of Arch]]. It is also still under heavy development. Some packages may currently fail to build on Arch.}}<br />
'''GNU Guix''' is a package manager that offers transactional, reproducible, per-user package management.<br />
While Guix can be used stand-alone and provide a full GNU distribution and a kernel by itself, you can install the Guix package manager on top of Arch to make Guix available to users while using a more traditional and mature Unix-like system as a base.<br />
<br />
See the [https://www.gnu.org/software/guix/manual Guix manual] for information on what per-user packaging commands Guix makes available to users.<br />
<br />
== Installation ==<br />
<br />
{{Expansion|The Guix reference manual says {{ic|nscd.service}} should be enabled but it is not clear if {{ic|nscd}} works properly on Arch or if it is even required.}}<br />
{{Note|The build check currently fails if {{ic|/bin/sh}} is not a link to bash, which is not a problem on a default Arch installation.}}<br />
<br />
GNU Guix is available in the AUR as {{AUR|guix}}. As described in the {{ic|PKGBUILD}}, the PGP key by the Guix distributor will need to be added first.<br />
<br />
== Running ==<br />
<br />
Guix makes builds more reproducible by running the build process using an unprivileged build user account. Therefore if you want to be able to build {{ic|''n''}} packages simultaneously (e.g. for serving multiple users at the same time) you should create {{ic|''n''}} build user accounts. as Guix should be able to build simultaneously. The following command does this the way described in [https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup Guix manual]:<br />
<br />
# groupadd --system guixbuild<br />
# for i in `seq -w 1 ''n''`;<br />
do<br />
useradd -g guixbuild -G guixbuild \<br />
-d /var/empty -s `which nologin` \<br />
-c "Guix build user $i" --system \<br />
guixbuilder$i;<br />
done<br />
<br />
[[Systemd#Using units|Start and enable]] {{ic|guix-daemon.service}}.<br />
<br />
You may want to authorize Guix to download and use binary packages (‘substitutes’) from [http://hydra.gnu.org Hydra]:<br />
<br />
# guix archive --authorize < /usr/share/guix/hydra.gnu.org.pub<br />
<br />
=== Building packages outside of {{ic|/tmp}} ===<br />
<br />
The unit file may need to be modified to use a different {{ic|TMPDIR}} for building if {{ic|/tmp}} does not provide enough space (see the [https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup Guix manual] for details). To use {{ic|''/tmpdir''}} for building instead of {{ic|/tmp}}, copy {{ic|/usr/lib/systemd/system/guix-daemon.service}} to {{ic|/etc/systemd/system/guix-daemon-custom.service}}, add a line<br />
<br />
{{hc|/etc/systemd/system/guix-daemon-custom.service|2=<br />
[Service]<br />
...<br />
Environment=TMPDIR=/tmpdir<br />
...<br />
}}<br />
<br />
and enable {{ic|guix-daemon-custom.service}} ''instead'' of {{ic|guix-daemon.service}}.<br />
<br />
== Uninstalling Guix ==<br />
<br />
Disable {{ic|guix-daemon.service}} (or {{ic|guix-daemon-custom.service}}) and then remove Guix using [[pacman]]. Now remove all the Guix build users and their group:<br />
<br />
# for i in `seq -w 1 ''n''`; do userdel guixbuilder$i; done<br />
# groupdel guixbuild<br />
<br />
Then remove the Guix store {{ic|/gnu}} and {{ic|/var/guix}}. If you created a custom {{ic|guix-daemon-custom.service}}, you may want to remove it as well.</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Guix&diff=460139Guix2016-12-26T10:52:14Z<p>Pelzflorian: Create article with install instructions.</p>
<hr />
<div>[[Category:System administration]]<br />
{{Warning|Guix is '''not''' the [[pacman|official package manager of Arch]]. It is also still under heavy development. Some packages may currently fail to build on Arch.}}<br />
'''GNU Guix''' is a package manager that offers transactional, reproducible, per-user package management.<br />
While Guix can be used stand-alone and provide a full GNU distribution and a kernel by itself, you can install the Guix package manager on top of Arch to make Guix available to users while using a more traditional and mature Unix system as a base.<br />
<br />
See the [https://www.gnu.org/software/guix/manual Guix manual] for information on what per-user packaging commands Guix makes available to users.<br />
<br />
== Installation ==<br />
<br />
{{Expansion|The Guix reference manual says {{ic|nscd.service}} should be enabled but it is not clear if {{ic|nscd}} works properly on Arch or if it is even required.}}<br />
{{Note|The build check currently fails if {{ic|/bin/sh}} is not a link to bash, which is not a problem on a default Arch installation.}}<br />
<br />
GNU Guix is available in the AUR as {{AUR|guix}}. As described in the {{ic|PKGBUILD}}, the PGP key by the Guix distributor will need to be added first.<br />
<br />
== Running ==<br />
<br />
Guix makes builds more reproducible by running the build process using an unprivileged build user account. Therefore if you want to be able to build {{ic|''n''}} packages simultaneously (e.g. for serving multiple users at the same time) you should create {{ic|''n''}} build user accounts. as Guix should be able to build simultaneously. The following command does this the way described in [https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup Guix manual]:<br />
<br />
# groupadd --system guixbuild<br />
# for i in `seq -w 1 ''n''`;<br />
do<br />
useradd -g guixbuild -G guixbuild \<br />
-d /var/empty -s `which nologin` \<br />
-c "Guix build user $i" --system \<br />
guixbuilder$i;<br />
done<br />
<br />
[[Systemd#Using units|Start and enable]] {{ic|guix-daemon.service}}.<br />
<br />
You may want to authorize Guix to download and use binary packages (‘substitutes’) from [http://hydra.gnu.org Hydra]:<br />
<br />
# guix archive --authorize < /usr/share/guix/hydra.gnu.org.pub<br />
<br />
=== Building packages outside of {{ic|/tmp}} ===<br />
<br />
The unit file may need to be modified to use a different {{ic|TMPDIR}} for building if {{ic|/tmp}} does not provide enough space (see the [https://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup Guix manual] for details). To use {{ic|''/tmpdir''}} for building instead of {{ic|/tmp}}, copy {{ic|/usr/lib/systemd/system/guix-daemon.service}} to {{ic|/etc/systemd/system/guix-daemon-custom.service}}, add a line<br />
<br />
{{hc|/etc/systemd/system/guix-daemon-custom.service|2=<br />
[Service]<br />
...<br />
Environment=TMPDIR=/tmpdir<br />
...<br />
}}<br />
<br />
and enable {{ic|guix-daemon-custom.service}} ''instead'' of {{ic|guix-daemon.service}}.<br />
<br />
== Uninstalling Guix ==<br />
<br />
Disable {{ic|guix-daemon.service}} (or {{ic|guix-daemon-custom.service}}) and then remove Guix using [[pacman]]. Now remove all the Guix build users and their group:<br />
<br />
# for i in `seq -w 1 ''n''`; do userdel guixbuilder$i; done<br />
# groupdel guixbuild<br />
<br />
Then remove the Guix store {{ic|/gnu}} and {{ic|/var/guix}}. If you created a custom {{ic|guix-daemon-custom.service}}, you may want to remove it as well.</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Vino&diff=444471Vino2016-08-03T16:32:36Z<p>Pelzflorian: /* Running on a headless server */ Use proper apostrophe character.</p>
<hr />
<div>[[Category:Remote desktop]]<br />
[[Category:GNOME]]<br />
[[ja:Vino]]<br />
'''Vino''' is a VNC (Virtual Network Computing) server allowing remote connection to your actual desktop. It is a default component of the [[GNOME]] [[Desktop environment]].<br />
<br />
== Installation ==<br />
<br />
=== GNOME ===<br />
[[Install]] the package {{Pkg|vino}}, which is available in the [[official repositories]].<br />
<br />
You need to restart GNOME so that {{ic|vino-server}} is started automatically when enabling the remote desktop feature. The remote desktop feature can usually be enabled in Settings > Sharing, however this only seems to be functional when [[NetworkManager]] is installed and functional.<br />
<br />
=== Alternative Desktop Environments ===<br />
As of version 3.9.2, Vino no longer includes a standalone preferences dialog (see [https://bugzilla.gnome.org/show_bug.cgi?id=700070 bug 700070]), thus making configuration difficult without the GNOME Control Center.<br />
<br />
The easiest solution is to install the package {{AUR|vino38}}, which provides the latest version with the preferences dialog, accessible via the {{ic|vino-preferences}} command.<br />
<br />
== Configuration ==<br />
<br />
You can configure vino via gnome-control-center.<br />
<br />
Now you can connect remotely to your desktop via a VNC viewer like TightVNC or Remmina. Remember to forward port 5900 if you are behind a NAT device and to allow the connection through iptables.<br />
<br />
If you are having problems regarding security and encryption you could try:<br />
<br />
$ gsettings set org.gnome.Vino require-encryption false<br />
<br />
If you use a standalone [[window manager]] like [[Openbox]] and it does not work, you can start {{ic|vino-server}} manually or add the command to the window manager's autostart script<br />
<br />
# /usr/lib/vino/vino-server &<br />
<br />
== Running on a headless server ==<br />
<br />
Vino can be used to manage a headless server with a graphical desktop via VNC. For this, a graphics driver like {{Pkg|xf86-video-dummy}} must be installed and [[Xorg#Configuration|configured]]. [http://xpra.org/xorg.conf xpra’s sample xorg.conf] for the Xdummy driver can be used as a base. Then, the server can be configured to [[start X at boot]] for the user account that should be usable remotely. Vino must be made to [[Desktop_entries#Autostart|autostart with the desktop environment]] by creating a desktop entry in the user’s home directory such as this one:<br />
<br />
{{hc|~/.config/autostart/vino-server.desktop|2=<br />
[Desktop Entry]<br />
Type=Application<br />
Name=Vino VNC server<br />
Exec=/usr/lib/vino/vino-server<br />
NoDisplay=true<br />
}}<br />
<br />
Next, make Vino accept VNC connections without asking for confirmation by running the following command as the graphical desktop user:<br />
<br />
$ dbus-launch gsettings set org.gnome.Vino prompt-enabled false<br />
<br />
You may wish to revoke suspend and hibernate permissions using [[Polkit]].<br />
<br />
For the [[GNOME]] desktop environment, the following are some further options you may want for GNOME:<br />
<br />
$ dbus-launch gsettings set org.gnome.desktop.lockdown disable-user-switching true<br />
$ dbus-launch gsettings set org.gnome.desktop.lockdown disable-log-out true<br />
$ dbus-launch gsettings set org.gnome.desktop.interface enable-animations false<br />
<br />
Remember to configure your [[firewall]] to not block the {{ic|rfb}} port used for VNC. For secure authentication – which should be used when giving access to privileged users on the open internet –, you should tunnel the VNC protocol through e.g. [[SSH]] or {{Pkg|stunnel}} instead of unblocking the {{ic|rfb}} port. When using stunnel, you should require a [[Security#Passwords|password]]:<br />
<br />
$ dbus-launch gsettings set org.gnome.Vino authentication-methods "['vnc']"<br />
$ dbus-launch gsettings set org.gnome.Vino vnc-password $(echo "mypassword"|base64)<br />
<br />
You can now log in to your server with a VNC client such as {{Pkg|vinagre}}.<br />
<br />
The above setup can also be used with multiple remote users logging in automatically, e.g. by using multiple copies of {{AUR|xlogin-git}}’s service files in {{ic|/etc/systemd/system/}}, each modified to log in a different user on a different X11 display and virtual terminal. With Vino, each user’s VNC server can be configured to listen on a different port as well:<br />
<br />
$ dbus-launch gsettings set org.gnome.Vino alternative-port 5910<br />
$ dbus-launch gsettings set org.gnome.Vino use-alternative-port true</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:Multiboot_USB_drive&diff=441800Talk:Multiboot USB drive2016-07-17T05:52:06Z<p>Pelzflorian: /* Scope and title */ please keep menuentries</p>
<hr />
<div>== Redirect to avoid duplication? ==<br />
<br />
Everything seems to be already covered on [[GRUB]] page: [[GRUB#Installation]], [[GRUB#Generating main configuration file]], [[GRUB#Booting ISO9660 image file directly via GRUB]]... (it is obvious that GRUB can be installed on USB drive)<br />
<br />
Maybe we can just redirect to [[GRUB#Booting ISO9660 image file directly via GRUB]] to avoid duplication?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:42, 10 September 2014 (UTC)<br />
<br />
:What about compacting the article instead by keeping the general idea and the steps in the procedure while replacing the duplicated parts with links, and then merging the result into [[USB_flash_installation_media#Using_a_multiboot_USB_drive]], which is this article's only backlink? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:49, 11 September 2014 (UTC)<br />
<br />
::Moving [[GRUB#Booting ISO9660 image file directly via GRUB]] could also be considered, but "Multiboot USB drive" is too generic title for this. It all depends if similar setups (even without booting ISO images) are possible with other boot loaders, e.g. [[syslinux]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:56, 11 September 2014 (UTC)<br />
<br />
:::Do you mean "moving" it to a separate article or into [[USB_flash_installation_media#Using_a_multiboot_USB_drive]]? In either case, as you point out splitting [[GRUB#Booting ISO9660 image file directly via GRUB]] would require more research about other boot loaders to justify having it in a separate article from [[GRUB]], I'm not sure how long would that take to be implemented...<br />
:::If our immediate goal is only removing the duplicated content, my solution seems more readily feasible.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:06, 12 September 2014 (UTC)<br />
<br />
::::As there was another method to be added (Syslinux + memdisk), I have merged the [[GRUB#Booting ISO9660 image file directly via GRUB]] section here. Aside from the obvious style issues, there is also [[USB_flash_installation_media#Loading_the_installation_media_from_RAM]] (see also the [https://bbs.archlinux.org/viewtopic.php?id=135266 preceding forum thread]), which is surprisingly presented as Windows-only method. If it was a Linux method, I would have already merged it here, but now I'm not so sure. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:49, 13 September 2014 (UTC)<br />
<br />
:::::Well done with the merge. About [[USB_flash_installation_media#Loading_the_installation_media_from_RAM]] I'm not sure either, if you want you can consider flagging it with Template:Merge to attract more opinions here. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:23, 14 September 2014 (UTC)<br />
<br />
::::::OK, marked as suggested, closing. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:50, 14 September 2014 (UTC)<br />
<br />
:::::::Re-opening, this discussion is still needed as a reference for [[#Scope and title]], but let's continue discussing there. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:06, 21 September 2014 (UTC)<br />
<br />
:To clarify what this article was meant to be: My intention was to make an article specifically about how to boot multiple ISO files from one usb drive. I agree that the title is too generic as is. Whilst a lot of the content here might seem simple and already found elsewhere, configuring the various boot menuentries is difficult, and not documented on any other page. The boot menuentries are poorly documented on the homepages of clonezilla, ubuntu, and so on. Therefore maintaining a list of these entries on the wiki seems to be a good idea. I have now added 3 entries beyond the one for the archiso. This list does not really fit on any of the existing pages. It is entirely possible to achieve a similar result using syslinux, which could be added later. <br />
: -- [[User:Teateawhy|Teateawhy]] ([[User talk:Teateawhy|talk]]) 15:52, 12 September 2014 (UTC)<br />
<br />
::Ahem... What about [[GRUB#Booting_ISO9660_image_file_directly_via_GRUB]] as we linked from our posts above? :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:57, 13 September 2014 (UTC)<br />
<br />
== Scope and title ==<br />
<br />
If I may, I have some comments about this article.<br />
<br />
First, the "introduction" (the first section of the article right after the title):<br />
<br />
<center>''A multiboot USB flash drive allows booting multiple ISO files from a single device''</center><br />
<br />
A multiboot (USB flash) drive can manage the booting options in different ways. I mean, it is not limited just to booting "ISO images as-is". This is ''one'' valid method, with pros and cons.<br />
<br />
Considering the name of the article (and the current relations / links to/from it), I would tend to think that limiting this article to this "full ISO images approach only" would be at least inaccurate. It should at least mention that there are other approaches available, with other pros and cons.<br />
<br />
Alternatively, the name (title) of the wiki article should be modified so to reflect the specific approach being described. The disadvantage of such alternative is that it might leave the impression that this is "the" ("best", "only") way to have a multiboot (USB flash) drive.<br />
<br />
I understand the initial intention of [[User:Teateawhy|Teateawhy]] about the scope of the article. By reading the links to/from this article and the current title, IMHO some adjustments are needed, hence my above comments.<br />
<br />
Now, regarding parts of the current content...<br />
* At this date (2014Sep), MEMDISK works on BIOS only, not UEFI (UEFI not being supported by these bootloaders using this "ISO mapping" approach is mentioned under [[Multiboot_USB_drive#Using_GRUB_and_loopback_devices]] but not under [[Multiboot_USB_drive#Using_Syslinux_and_memdisk]].<br />
* The MEMDISK method is not limited to Syslinux. Bootloaders that are capable of loading a Linux kernel (on BIOS hardware) should be able to load MEMDISK too.<br />
* There are other bootloaders also capable of mapping (ISO) images (e.g. grub4dos).<br />
* Syslinux is mentioned in conjunction with MEMDISK, but someone could claim that using Syslinux by itself on a multiboot USB flash drive might be better than mapping entire ISO images (depending on pros and cons or each method). Additionally, Syslinux (and others) can support UEFI.<br />
<br />
Of course, adding all this info in detail to this (one) article might make the scope of it "too wide" to be actually useful/clear.<br />
<br />
So, it is fine to provide information about making a multiboot USB flash drive by "simply throwing ISO images" on the drive, but I also think that the title of the article and the links to/from it should be "more accurate", specially reflecting that other possibilities exist (instead of mapping whole ISO images) and mentioning pros and cons (more RAM needed, time to load the mapped image, consecutive blocks, used space in the USB drive...). [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 21:40, 14 September 2014 (UTC)<br />
<br />
:Hi, thank you for your observations. This article has clearly large margins for improvement, including changing the title itself and the sections that link to it from other articles. I agree with all of your points, your contribution would be very welcome; if you have a better title to propose, please let us know here. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:00, 15 September 2014 (UTC)<br />
<br />
::About suggesting an alternative title... <br />
<br />
::The procedures described here are mostly valid for different storage media. Indeed, a typical use-case is on a USB flash drive, but you could do the same on non-flash drives, and on non-USB drives, whether removable or not.<br />
<br />
::Additionally, the content describes different variations of only one particular approach: mapping images. Although the method is typically used with ISO images, you could do the same with other types (e.g. HDD and superfloppy) of bootable images.<br />
<br />
::It seems that two words, "multiboot" and "image(s)", are essential to the article. I also think that, either together or by themselves, they give enough information so to attract potential interested readers. IMHO, words such as "USB", "flash" and "drive" are not really needed for the title, and they can be (and in fact are) mentioned in the content as typical use-cases of this multiboot method.<br />
<br />
::So, perhaps something about "Multiboot images" (or "Multibooting images") could be appropriate? Optionally add the "ISO" term too; although, these methods are not exclusively used with ISO images.<br />
<br />
::Once the scope and the title are refined, it would be helpful for users to have a hint about the existence of other methods (instead of mapping images), mentioning some of the generic pros and cons. Then (a) future new article(s) about such other multiboot methods could be linked to/from this (renamed) page. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 14:14, 16 September 2014 (UTC)<br />
<br />
:::Good reasoning. What about "Multibooting disk images" as an improvement? Just "images" sounds too ambiguous to me, and "disk images" seems to be the correct term according to [[Wikipedia:Disk image]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:46, 17 September 2014 (UTC)<br />
<br />
::::"Multiboot disk images" sounds reasonable. Just for the record, although many users don't care / remember / know, in this context the generic term "dis'''k'''" includes the "disc" optical media (ISO images). Now, "only" the content needs some improvements :). [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 13:12, 17 September 2014 (UTC)<br />
<br />
:::::Um... sorry but coming back here after a few days, I think I'm less convinced by the (current and intended) scope of this article, which is/would become too heterogeneous. I'd consider merging the GRUB section back to [[GRUB]] instead (or maybe even better in a GRUB/Subpage), and then, if you wanted (@Ady), you could rename this article as "MEMDISK" and expand it on how to load and use MEMDISK with some bootloaders; this would probably also make it easier to merge [[USB_flash_installation_media#Loading_the_installation_media_from_RAM]] here, and we could easily add a link to the new GRUB subpage in [[USB_flash_installation_media#Using_a_multiboot_USB_drive]]. I'm also re-opening [[#Redirect to avoid duplication?]] because it's related. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:05, 21 September 2014 (UTC)<br />
<br />
::::::Whichever the case, ATM the suggested title ("Multiboot disk images") seems (to me) more accurate than the current title ("Multiboot USB drive") according to the current content. "Multiboot disk images" also matches what seems to be the scope that [[User:Teateawhy]] intended for this page.<br />
<br />
::::::WRT merging / moving (part of) the content into other pages, I might have a slightly different view on the matter (or perhaps it is not so different?). [[GRUB]] is capable of dealing with many different scenarios. For the content / scope of a wiki article, I would tend to focus on what a user wants / needs / thinks, instead of concentrating on "every single thing that GRUB can do".<br />
<br />
::::::One user might be thinking about a very simple and generic task ("boot my newly installed OS, which I attempt to test with the very-basic features and nothing fancy").<br />
<br />
::::::Another user might want to have LVM, encryption, RAID, with several OSes... And yet another user wants a portable device with several "rescue" tools, or several OSes so to show to friends on their own hardware.<br />
<br />
::::::Writing every single scenario related to bootloaders (or to GRUB) under one single article would make it more complex for users to focus on their respective interests / tasks. IMHO, having different articles focusing on the task (i.e. what each user is thinking about) rather than focusing on a certain name/tool or certain software such as "everything GRUB", is more useful for users.<br />
<br />
::::::You can always have links from [[GRUB]] and from other alternative bootloaders' wiki pages to the "task-oriented" articles. Of course, the in-common information regarding GRUB shall not be repeated, but just mention the relevant info / steps so to achieve the goal/task. So the question becomes, how much "in-common" information (or details / steps) can and should be moved back to [[GRUB]]? Would/should this page be just a list of entries for different OSes, leaving the "HowTos" for each bootloader's wiki pages? Then you can decide how to name this page. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 16:45, 21 September 2014 (UTC)<br />
<br />
::::'Multiboot' is misleading. This page presents very useful information about how to boot from a disk image file. 'Booting from a disk image file' would be an appropriate findable title, as would 'Booting from disk image files.' I'm not sure which style the arch wiki prefers.<br />
[[User:DonJaime|DonJaime]] ([[User talk:DonJaime|talk]]) 13:32, 7 August 2015 (UTC)<br />
<br />
: I really don't see the point in keeping all this information on other distributions. Those have wikis of their own; and that's where this information belongs. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:33, 16 July 2016 (UTC)<br />
<br />
::It saves a lot of time to have all this information in one place. Yes, most menuentries are not related to Arch and could be moved to some cross-distribution wiki on the Web to which the Arch wiki could provide a link. But unless that happens, please keep the information. [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 05:52, 17 July 2016 (UTC)<br />
<br />
== Tails ==<br />
<br />
Can anyone add [https://tails.boum.org/ Tails]? [http://www.preining.info/blog/2015/05/usb-stick-update-tails-debian-gparted-sysrescd/ This] might be useful. [[User:Fturco|Fturco]] ([[User talk:Fturco|talk]]) 19:43, 2 July 2015 (UTC)<br />
<br />
== Update Clonezilla Configuration ==<br />
<br />
The Clonezilla Live configuration provided by current wiki page doesn't work on my hardware, so I tried to modify it in order to boot properly.<br />
I founded that this entry works (while wiki one doesn't):<br />
{{bc|1=<br />
menuentry 'Clonezilla Live 64bit' {<br />
set isofile="/boot/iso/clonezilla-live-2.4.2-32-amd64.iso"<br />
loopback loop $isofile<br />
linux (loop)/live/vmlinuz findiso=$isofile boot=live union=overlay username=user config components noswap edd=on nodmraid ip= net.ifnames=0<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
{{unsigned|14:58, 31 August 2015|Lobisquit}}<br />
<br />
== Update Ubuntu Configuration ==<br />
<br />
The Ubuntu configuration provided by current wiki page doesn't work on Ubuntu 2014.04 LTS (i386). Apperantly vmlinuz.efi file is now vmlinuz.<br />
<br />
{{bc|1=<br />
menuentry '[loopback]ubuntu-14.04.1-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04.1-desktop-amd64.iso'<br />
loopback loop $isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile locale=en_US.UTF-8<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}<br />
}}<br />
<br />
-- 09:28, 27 November 2015 Zuko95<br />
<br />
== Xubuntu and Lubuntu ==<br />
<br />
Could someone please add the menuentry for Xubuntu and Lubuntu 16.04 32 bit? I tried copying the Ubuntu entry, adding vmalloc=1300M and replacing vmlinuz.efi to vmlinuz but it doesn't work. After some disk activity, the PC simply shuts down.<br />
<br />
{{unsigned|08:26, 19 May 2016|Entodoays}}<br />
<br />
== Arch dual iso ==<br />
I tried booting the archlinux-2016.05.01-dual.iso using the menuentry in this wiki page but got a kernel panic and a message to specify init=.<br />
<br />
My menuentry:<br />
<br />
{{bc|1=menuentry '[loopback]archlinux-2016.05.01-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2016.05.01-dual.iso'<br />
loopback loop $isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz img_dev=$imgdevpath img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
}}<br />
<br />
{{unsigned|08:37, 29 June 2016|Entodoays}}</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439656Flatpak2016-07-03T13:23:31Z<p>Pelzflorian: /* Creating apps with pacman */</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
=== Adding Flatpak .desktop files to your menu ===<br />
Some window managers and launchers do not scan the Flatpak directory by default. If you can edit the list of directories scanned, add this to it:<br />
<br />
~/.local/share/flatpak/exports/applications<br />
<br />
This is known to be necessary in Awesome.<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
{{Note|You may want to use an untrusted, unprivileged user account for bundling untrusted software because the software is not sandboxed during app and runtime creation.}}<br />
<br />
{{Note|When distributing bundles to others, you may be legally obliged to provide the source code of some of the bundled software upon request. You may want to use [[Arch Build System|ABS]] to build these packages from source.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
In addition to {{Pkg|flatpak}}, you need to have installed {{Pkg|fakeroot}} and for pacman hooks support also {{Pkg|fakechroot}}.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir ''myflatpakbuilddir''<br />
$ cd ''myflatpakbuilddir''<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p ''myruntime''/files/var/lib/pacman<br />
$ touch ''myruntime''/files/.ref<br />
$ ln -s /usr/usr/share ''myruntime''/files/share<br />
$ ln -s /usr/usr/include ''myruntime''/files/include<br />
$ ln -s /usr/usr/local ''myruntime''/files/local<br />
<br />
Make your host OS fonts available to the Arch runtime:<br />
<br />
$ mkdir -p ''myruntime''/files/usr/share/fonts<br />
$ ln -s /run/host/fonts ''myruntime''/files/usr/share/fonts/flatpakhostfonts<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Copy {{ic|/etc/pacman.conf}} to your build directory and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root ''myruntime''/files --dbpath ''myruntime''/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf ''myruntime''/files/etc/pacman.conf<br />
<br />
Set up the [[Locale|locales]] to be used by editing {{ic|''myruntime''/files/etc/locale.gen}}. Then regenerate the runtime’s locales.<br />
<br />
$ fakechroot chroot ''myruntime''/files locale-gen<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r ''myruntime'' mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot --needed<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|''myruntime''/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=''myruntime''<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
<br />
Now finish the dummy app. You can fine-tune the app’s access permissions when sandboxed by giving additional options when finishing the build. For possible options see the [[Flatpak#See_also|Flatpak documentation]] and the [https://git.gnome.org/browse/gnome-apps-nightly/tree GNOME manifest files]. Alternatively, adapt {{ic|geditapp/metadata}} to your needs after finishing the build but before exporting. When the metadata file is complete, export the app to the repository.<br />
<br />
$ flatpak build-finish geditapp --socket=x11 ''[possibly other options]'' --command=gedit<br />
$ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439596Flatpak2016-07-03T06:20:27Z<p>Pelzflorian: /* Creating apps with pacman */ When to edit app metadata.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
=== Adding Flatpak .desktop files to your menu ===<br />
Some window managers and launchers do not scan the Flatpak directory by default. If you can edit the list of directories scanned, add this to it:<br />
<br />
~/.local/share/flatpak/exports/applications<br />
<br />
This is known to be necessary in Awesome.<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
{{Note|You may want to use an untrusted, unprivileged user account for bundling untrusted software because the software is not sandboxed during app and runtime creation.}}<br />
<br />
{{Note|When distributing bundles to others, you may be legally obliged to provide the source code of some of the bundled software upon request. You may want to use [[Arch Build System|ABS]] to build these packages from source.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
In addition to {{Pkg|flatpak}}, you need to have installed {{Pkg|fakeroot}} and for pacman hooks support also {{Pkg|fakechroot}}.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir ''myflatpakbuilddir''<br />
$ cd ''myflatpakbuilddir''<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p ''myruntime''/files/var/lib/pacman<br />
$ touch ''myruntime''/files/.ref<br />
$ ln -s /usr/usr/share ''myruntime''/files/share<br />
$ ln -s /usr/usr/include ''myruntime''/files/include<br />
$ ln -s /usr/usr/local ''myruntime''/files/local<br />
<br />
Make your host OS fonts available to the Arch runtime:<br />
<br />
$ mkdir -p ''myruntime''/files/usr/share/fonts<br />
$ ln -s /run/host/fonts ''myruntime''/files/usr/share/fonts/flatpakhostfonts<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Copy {{ic|/etc/pacman.conf}} to your build directory and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root ''myruntime''/files --dbpath ''myruntime''/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf ''myruntime''/files/etc/pacman.conf<br />
<br />
Set up the [[Locale|locales]] to be used by editing {{ic|''myruntime''/files/etc/locale.gen}}. Then regenerate the runtime’s locales.<br />
<br />
$ fakechroot chroot ''myruntime''/files locale-gen<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r ''myruntime'' mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot --needed<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|''myruntime''/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=''myruntime''<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
$ flatpak build-finish geditapp --socket=x11 --command=gedit<br />
<br />
If you wish to fine-tune the app’s access permissions when sandboxed, adapt {{ic|geditapp/metadata}} to your needs as described on Flatpak’s [https://github.com/flatpak/flatpak/wiki/Metadata GitHub wiki] before exporting. When the metadata file is complete, export the app to the repository.<br />
<br />
$ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439584Flatpak2016-07-02T17:40:19Z<p>Pelzflorian: /* Creating a custom base runtime */ Fix locales.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
=== Adding Flatpak .desktop files to your menu ===<br />
Some window managers and launchers do not scan the Flatpak directory by default. If you can edit the list of directories scanned, add this to it:<br />
<br />
~/.local/share/flatpak/exports/applications<br />
<br />
This is known to be necessary in Awesome.<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
{{Note|You may want to use an untrusted, unprivileged user account for bundling untrusted software because the software is not sandboxed during app and runtime creation.}}<br />
<br />
{{Note|When distributing bundles to others, you may be legally obliged to provide the source code of some of the bundled software upon request. You may want to use [[Arch Build System|ABS]] to build these packages from source.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
In addition to {{Pkg|flatpak}}, you need to have installed {{Pkg|fakeroot}} and for pacman hooks support also {{Pkg|fakechroot}}.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir myflatpakbuilddir<br />
$ cd myflatpakbuilddir<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p myruntime/files/var/lib/pacman<br />
$ touch myruntime/files/.ref<br />
$ ln -s /usr/usr/share myruntime/files/share<br />
$ ln -s /usr/usr/include myruntime/files/include<br />
$ ln -s /usr/usr/local myruntime/files/local<br />
<br />
Make your host OS fonts available to the Arch runtime:<br />
<br />
$ mkdir -p myruntime/files/usr/share/fonts<br />
$ ln -s /run/host/fonts myruntime/files/usr/share/fonts/flatpakhostfonts<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Run {{ic|cp /etc/pacman.conf pacman.conf}} and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root myruntime/files --dbpath myruntime/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf myruntime/files/etc/pacman.conf<br />
<br />
Set up the [[Locale|locales]] to be used by editing {{ic|myruntime/files/etc/locale.gen}}. Then regenerate the runtime’s locales.<br />
<br />
$ fakechroot chroot myruntime/files locale-gen<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r myruntime mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot --needed<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|myruntime/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=myruntime<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
$ flatpak build-finish geditapp --socket=x11 --command=gedit<br />
$ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439583Flatpak2016-07-02T17:34:28Z<p>Pelzflorian: /* Creating a custom base runtime */ Fix fonts.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
=== Adding Flatpak .desktop files to your menu ===<br />
Some window managers and launchers do not scan the Flatpak directory by default. If you can edit the list of directories scanned, add this to it:<br />
<br />
~/.local/share/flatpak/exports/applications<br />
<br />
This is known to be necessary in Awesome.<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
{{Note|You may want to use an untrusted, unprivileged user account for bundling untrusted software because the software is not sandboxed during app and runtime creation.}}<br />
<br />
{{Note|When distributing bundles to others, you may be legally obliged to provide the source code of some of the bundled software upon request. You may want to use [[Arch Build System|ABS]] to build these packages from source.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
In addition to {{Pkg|flatpak}}, you need to have installed {{Pkg|fakeroot}} and for pacman hooks support also {{Pkg|fakechroot}}.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir myflatpakbuilddir<br />
$ cd myflatpakbuilddir<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p myruntime/files/var/lib/pacman<br />
$ touch myruntime/files/.ref<br />
$ ln -s /usr/usr/share myruntime/files/share<br />
$ ln -s /usr/usr/include myruntime/files/include<br />
$ ln -s /usr/usr/local myruntime/files/local<br />
<br />
Make your host OS fonts available to the Arch runtime:<br />
<br />
$ mkdir -p myruntime/files/usr/share/fonts<br />
$ ln -s /run/host/fonts myruntime/files/usr/share/fonts/flatpakhostfonts<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Run {{ic|cp /etc/pacman.conf pacman.conf}} and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root myruntime/files --dbpath myruntime/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf myruntime/files/etc/pacman.conf<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r myruntime mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot --needed<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|myruntime/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=myruntime<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
$ flatpak build-finish geditapp --socket=x11 --command=gedit<br />
$ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439377Flatpak2016-06-29T19:30:06Z<p>Pelzflorian: Only install new --needed pkgs for the SDK.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
{{Note|You may want to use an untrusted, unprivileged user account for bundling untrusted software because the software is not sandboxed during app and runtime creation.}}<br />
<br />
{{Note|When distributing bundles to others, you may be legally obliged to provide the source code of some of the bundled software upon request. You may want to use [[Arch Build System|ABS]] to build these packages from source.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
In addition to {{Pkg|flatpak}}, you need to have installed {{Pkg|fakeroot}} and for pacman hooks support also {{Pkg|fakechroot}}.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir myflatpakbuilddir<br />
$ cd myflatpakbuilddir<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p myruntime/files/var/lib/pacman<br />
$ touch myruntime/files/.ref<br />
$ ln -s /usr/usr/share myruntime/files/share<br />
$ ln -s /usr/usr/include myruntime/files/include<br />
$ ln -s /usr/usr/local myruntime/files/local<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Run {{ic|cp /etc/pacman.conf pacman.conf}} and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root myruntime/files --dbpath myruntime/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf myruntime/files/etc/pacman.conf<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r myruntime mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot --needed<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|myruntime/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=myruntime<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
$ flatpak build-finish geditapp --socket=x11 --command=gedit<br />
$ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439309Flatpak2016-06-29T07:43:57Z<p>Pelzflorian: /* Creating a custom base runtime */ Some notes.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
{{Note|You may want to use an untrusted, unprivileged user account for bundling untrusted software because the software is not sandboxed during app and runtime creation.}}<br />
<br />
{{Note|When distributing bundles to others, you may be legally obliged to provide the source code of some of the bundled software upon request. You may want to use [[Arch Build System|ABS]] to build these packages from source.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
In addition to {{Pkg|flatpak}}, you need to have installed {{Pkg|fakeroot}} and for pacman hooks support also {{Pkg|fakechroot}}.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir myflatpakbuilddir<br />
$ cd myflatpakbuilddir<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p myruntime/files/var/lib/pacman<br />
$ touch myruntime/files/.ref<br />
$ ln -s /usr/usr/share myruntime/files/share<br />
$ ln -s /usr/usr/include myruntime/files/include<br />
$ ln -s /usr/usr/local myruntime/files/local<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Run {{ic|cp /etc/pacman.conf pacman.conf}} and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root myruntime/files --dbpath myruntime/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf myruntime/files/etc/pacman.conf<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r myruntime mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|myruntime/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=myruntime<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
$ flatpak build-finish geditapp --socket=x11 --command=gedit<br />
$ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439272Flatpak2016-06-28T20:31:39Z<p>Pelzflorian: /* Creating apps with pacman */ Fix newline.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir myflatpakbuilddir<br />
$ cd myflatpakbuilddir<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p myruntime/files/var/lib/pacman<br />
$ touch myruntime/files/.ref<br />
$ ln -s /usr/usr/share myruntime/files/share<br />
$ ln -s /usr/usr/include myruntime/files/include<br />
$ ln -s /usr/usr/local myruntime/files/local<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Run {{ic|cp /etc/pacman.conf pacman.conf}} and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root myruntime/files --dbpath myruntime/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf myruntime/files/etc/pacman.conf<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r myruntime mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|myruntime/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=myruntime<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
$ flatpak build-finish geditapp --socket=x11 --command=gedit<br />
$ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439271Flatpak2016-06-28T20:29:53Z<p>Pelzflorian: Use gedit example; use fakechroot for pacman hooks.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir myflatpakbuilddir<br />
$ cd myflatpakbuilddir<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p myruntime/files/var/lib/pacman<br />
$ touch myruntime/files/.ref<br />
$ ln -s /usr/usr/share myruntime/files/share<br />
$ ln -s /usr/usr/include myruntime/files/include<br />
$ ln -s /usr/usr/local myruntime/files/local<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Run {{ic|cp /etc/pacman.conf pacman.conf}} and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakechroot fakeroot pacman -Syu --root myruntime/files --dbpath myruntime/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf myruntime/files/etc/pacman.conf<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r myruntime mysdk<br />
$ fakechroot fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot fakechroot<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|myruntime/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=myruntime<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|gedit}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w geditruntime org.mydomain.geditruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build geditruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build geditruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build geditruntime fakeroot pacman-key --init<br />
$ flatpak build geditruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network geditruntime fakechroot fakeroot pacman --root /usr -S gedit<br />
<br />
You can test the installation before finishing the runtime (without proper sandboxing).<br />
<br />
$ flatpak build --socket=x11 geditruntime gedit<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build geditruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish geditruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.geditruntime/" geditruntime/metadata<br />
$ flatpak build-export -r geditrepo geditruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init geditapp org.gnome.gedit org.mydomain.BaseSdk org.mydomain.geditruntime<br />
$ flatpak build-finish geditapp --socket=x11 --command=gedit $ flatpak build-export geditrepo geditapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify geditrepo geditrepo<br />
$ flatpak install --user geditrepo org.mydomain.geditruntime<br />
$ flatpak install --user geditrepo org.gnome.gedit<br />
$ flatpak run org.gnome.gedit<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439180Flatpak2016-06-27T19:44:22Z<p>Pelzflorian: /* Creating apps with pacman */ PKGBUILD should be a link.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir myflatpakbuilddir<br />
$ cd myflatpakbuilddir<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p myruntime/files/var/lib/pacman<br />
$ touch myruntime/files/.ref<br />
$ ln -s /usr/usr/share myruntime/files/share<br />
$ ln -s /usr/usr/include myruntime/files/include<br />
$ ln -s /usr/usr/local myruntime/files/local<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Run {{ic|cp /etc/pacman.conf pacman.conf}} and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakeroot pacman -Syu --root myruntime/files --dbpath myruntime/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf myruntime/files/etc/pacman.conf<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r myruntime mysdk<br />
$ fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|myruntime/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=myruntime<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom [[PKGBUILD]] tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|xterm}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w xtermruntime org.mydomain.xtermruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build xtermruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build xtermruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build xtermruntime fakeroot pacman-key --init<br />
$ flatpak build xtermruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network xtermruntime fakeroot pacman --root /usr -S xterm<br />
<br />
You can test the installation before finishing the runtime.<br />
<br />
$ flatpak build --socket=x11 xtermruntime xterm<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build xtermruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish xtermruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.xtermruntime/" xtermruntime/metadata<br />
$ flatpak build-export -r xtermrepo xtermruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init xtermapp net.invisible_island.xterm org.mydomain.BaseSdk org.mydomain.xtermruntime<br />
$ flatpak build-finish xtermapp --socket=x11 --command=xterm<br />
$ flatpak build-export xtermrepo xtermapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify xtermrepo xtermrepo<br />
$ flatpak install --user xtermrepo net.invisible_island.xterm<br />
$ flatpak run net.invisible_island.xterm<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Flatpak&diff=439103Flatpak2016-06-26T16:12:39Z<p>Pelzflorian: Build runtimes and apps with pacman.</p>
<hr />
<div>[[Category:Development]]<br />
[[ja:Flatpak]]<br />
{{Expansion|Need info on building apps.}}<br />
<br />
From [[Wikipedia::flatpak|Wikipedia]]: "[http://flatpak.org Flatpak], named xdg-app until May 2016, is a system for application virtualization for Linux desktop computer environments."<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{pkg|flatpak}} or {{AUR|flatpak-git}} package.<br />
<br />
== Managing repositories ==<br />
<br />
=== Add a repository ===<br />
<br />
To add a remote flatpak repository do:<br />
<br />
$ flatpak remote-add ''name'' ''location''<br />
<br />
where ''name'' is the name for the new remote, and ''location'' is the path or URL for the repository.<br />
<br />
=== Delete a repository ===<br />
<br />
To delete a remote flatpak repository do:<br />
<br />
$ flatpak remote-delete ''name''<br />
<br />
where ''name'' is the name of the remote repository to be deleted.<br />
<br />
== Managing runtimes and applications ==<br />
<br />
=== List available runtimes and applications ===<br />
<br />
To list available runtimes and applications in a remote repository named ''remote'' do:<br />
<br />
$ flatpak remote-ls ''remote''<br />
<br />
=== Install a runtime or application ===<br />
<br />
To install a runtime or application do:<br />
<br />
$ flatpak install ''remote'' ''name''<br />
<br />
where ''remote'' is the name of the remote repository, and ''name'' is the name of the application or runtime to install.<br />
<br />
=== List installed runtimes and applications ===<br />
<br />
To list installed runtimes and applications do:<br />
<br />
$ flatpak ls<br />
<br />
=== Update a runtime or application ===<br />
<br />
To update a runtime or application named ''name'' do:<br />
<br />
$ flatpak update ''name''<br />
<br />
=== Uninstall a runtime or application ===<br />
<br />
To uninstall a runtime or application named ''name'' do:<br />
<br />
$ flatpak uninstall ''name''<br />
<br />
== Creating a custom base runtime ==<br />
<br />
{{Expansion|This can certainly be improved. It also has problems with D-Bus for GNOME apps.}}<br />
<br />
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default {{ic|org.freedesktop.BasePlatform}} and {{ic|org.freedesktop.BaseSdk}} runtimes.<br />
<br />
First, start by creating a directory for building the runtime and possibly applications.<br />
<br />
$ mkdir myflatpakbuilddir<br />
$ cd myflatpakbuilddir<br />
<br />
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the {{ic|/usr}} directory in the sandbox. Therefore you will need to create symbolic links so the default {{ic|/usr/share}} etc. from Arch can still be accessed at the usual path.<br />
<br />
$ mkdir -p myruntime/files/var/lib/pacman<br />
$ touch myruntime/files/.ref<br />
$ ln -s /usr/usr/share myruntime/files/share<br />
$ ln -s /usr/usr/include myruntime/files/include<br />
$ ln -s /usr/usr/local myruntime/files/local<br />
<br />
You need and may want to adapt your {{ic|pacman.conf}} before installing packages to the runtime. Run {{ic|cp /etc/pacman.conf pacman.conf}} and then make the following changes:<br />
<br />
* Remove the {{ic|CheckSpace}} option so pacman will not complain about errors finding the root filesystem for checking disk space.<br />
* Remove any undesired custom repositories and {{ic|IgnorePkg}}, {{ic|IgnoreGroup}}, {{ic|NoUpgrade}} and {{ic|NoExtract}} settings that are needed only for the host system.<br />
<br />
Now install the packages for the runtime.<br />
<br />
$ fakeroot pacman -Syu --root myruntime/files --dbpath myruntime/files/var/lib/pacman --config pacman.conf base<br />
$ mv pacman.conf myruntime/files/etc/pacman.conf<br />
<br />
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.<br />
<br />
$ cp -r myruntime mysdk<br />
$ fakeroot pacman -S --root mysdk/files --dbpath mysdk/files/var/lib/pacman --config mysdk/files/etc/pacman.conf base-devel fakeroot<br />
<br />
Insert metadata about runtime and SDK.<br />
<br />
{{hc|myruntime/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BasePlatform<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
{{hc|mysdk/metadata|2=<br />
[Runtime]<br />
name=org.mydomain.BaseSdk<br />
runtime=org.mydomain.BasePlatform/x86_64/2016-06-26<br />
sdk=org.mydomain.BaseSdk/x86_64/2016-06-26<br />
}}<br />
<br />
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.<br />
<br />
$ ostree init --mode archive-z2 --repo=.<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BasePlatform/x86_64/2016-06-26 --tree=dir=myruntime<br />
$ EDITOR="nano -w" ostree commit -b runtime/org.mydomain.BaseSdk/x86_64/2016-06-26 --tree=dir=mysdk<br />
$ ostree summary -u<br />
<br />
Install the runtime and SDK.<br />
<br />
$ flatpak remote-add --user --no-gpg-verify myarchos file://$(pwd)<br />
$ flatpak install --user myarchos org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak install --user myarchos org.mydomain.BaseSdk 2016-06-26<br />
<br />
=== Creating apps with pacman ===<br />
<br />
As an alternative to building applications [http://flatpak.org/developer.html the usual way], we can use pacman to create a containerized version of the regular Arch packages. Note that {{ic|/usr}} is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either<br />
<br />
* use pacman to create a runtime containing all dependencies<br />
* and compile the app ourselves [http://flatpak.org/developer.html as usual] or perhaps using pacman with a custom {{ic|PKGBUILD}} tailored to Flatpak which uses {{ic|1=--prefix=/app}} for the {{ic|configure}} script,<br />
<br />
or we can<br />
* use pacman to create a runtime containing the app installed with pacman<br />
* and create a dummy app to launch it.<br />
<br />
For doing the latter, first create a runtime using pacman such as this one for {{Pkg|xterm}}. The runtime is first initialized and prepared for use with pacman.<br />
<br />
$ flatpak build-init -w xtermruntime org.mydomain.xtermruntime org.mydomain.BaseSdk org.mydomain.BasePlatform 2016-06-26<br />
$ flatpak build xtermruntime sed -i "s/^#Server/Server/g" /etc/pacman.d/mirrorlist<br />
$ flatpak build xtermruntime ln -s /usr/var/lib /var/lib<br />
$ flatpak build xtermruntime fakeroot pacman-key --init<br />
$ flatpak build xtermruntime fakeroot pacman-key --populate archlinux<br />
<br />
Then the package is installed. The host’s network connection must be made available to pacman.<br />
<br />
$ flatpak build --share=network xtermruntime fakeroot pacman --root /usr -S xterm<br />
<br />
You can test the installation before finishing the runtime.<br />
<br />
$ flatpak build --socket=x11 xtermruntime xterm<br />
<br />
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.<br />
<br />
$ flatpak build xtermruntime rm -r /etc/pacman.d/gnupg<br />
$ flatpak build-finish xtermruntime<br />
$ sed -i "s/\[Application\]/\[Runtime\]/;s/runtime=org.mydomain.BasePlatform/runtime=org.mydomain.xtermruntime/" xtermruntime/metadata<br />
$ flatpak build-export -r xtermrepo xtermruntime<br />
<br />
Then create a dummy app.<br />
<br />
$ flatpak build-init xtermapp net.invisible_island.xterm org.mydomain.BaseSdk org.mydomain.xtermruntime<br />
$ flatpak build-finish xtermapp --socket=x11 --command=xterm<br />
$ flatpak build-export xtermrepo xtermapp<br />
<br />
Install it along with the runtime.<br />
<br />
$ flatpak --user remote-add --no-gpg-verify xtermrepo xtermrepo<br />
$ flatpak install --user xtermrepo net.invisible_island.xterm<br />
$ flatpak run net.invisible_island.xterm<br />
<br />
== See also ==<br />
<br />
* [http://flatpak.org Official website]<br />
* [https://github.com/flatpak/flatpak/wiki Official Github wiki]<br />
* [https://wiki.gnome.org/Projects/SandboxedApps Gnome SandboxedApps]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Internet_sharing&diff=438044Internet sharing2016-06-13T07:25:09Z<p>Pelzflorian: Mention sharing via NetworkManager</p>
<hr />
<div>[[Category:Network sharing]]<br />
[[cs:Internet sharing]]<br />
[[fr:Partage de connexion]]<br />
[[it:Internet sharing]]<br />
[[ja:インターネット共有]]<br />
[[ru:Internet sharing]]<br />
{{Related articles start}}<br />
{{Related|Android tethering}}<br />
{{Related|Software access point}}<br />
{{Related|Bridge with netctl}}<br />
{{Related|Ad-hoc networking}}<br />
{{Related|Sharing PPP Connection}}<br />
{{Related|Simple stateful firewall}}<br />
{{Related|Router}}<br />
{{Related|USB 3G Modem}}<br />
{{Related articles end}}<br />
This article explains how to share the internet connection from one machine to other(s).<br />
<br />
== Requirements ==<br />
<br />
* The machine acting as server should have an additional network device.<br />
* That network device should be connected to the machines that are going to receive internet access. They can be one or more machines. To be able to share internet to several machines a [[Wikipedia:Network switch|switch]] is required. If you are sharing to only one machine, a [[Wikipedia:Ethernet crossover cable|crossover cable]] is sufficient.<br />
<br />
{{Note|If one of the two computers has a gigabit ethernet card, a crossover cable is not necessary and a regular ethernet cable should be enough}}<br />
<br />
== Configuration ==<br />
<br />
This section assumes, that the network device connected to the client computer(s) is named '''''net0''''' and the network device connected to the internet as '''''internet0'''''.<br />
<br />
{{Tip|You can rename your devices to this scheme using [[Udev#Setting static device names]].}}<br />
<br />
All configuration is done on the server computer, except for the final step of [[#Assigning IP addresses to the client PC(s)]].<br />
<br />
=== Static IP address ===<br />
<br />
On the server computer, assign a static IPv4 address to the interface connected to the other machines. The first 3 bytes of this address cannot be exactly the same as those of another interface.<br />
# ip link set up dev net0<br />
# ip addr add 192.168.123.100/24 dev net0 # arbitrary address<br />
<br />
To have your static ip assigned at boot, you can use [[netctl]].<br />
<br />
=== Enable packet forwarding ===<br />
<br />
Check the current packet forwarding settings:<br />
# sysctl -a | grep forward<br />
<br />
You will note that options exist for controlling forwarding per default, per interface, as well as separate options for IPv4/IPv6 per interface.<br />
<br />
Enter this command to temporarily enable packet forwarding at runtime:<br />
# sysctl net.ipv4.ip_forward=1<br />
<br />
{{Tip|To enable packet forwarding selectively for a specific interface, use {{ic|1=sysctl net.ipv4.conf.''interface_name''.forwarding=1}} instead.}}<br />
<br />
{{Warning|If the system uses [[systemd-networkd]] to control the network interfaces, a per-interface setting for IPv4 is not possible, i.e. systemd logic propagates any configured forwarding into a global (for all interfaces) setting for IPv4. The advised work-around is to use a firewall to forbid forwarding again on selective interfaces. See the systemd.network(5) manual page for more information. <br />
The {{ic|1=IPForward=kernel}} semantics introduced in a previous systemd release 220/221 to honor kernel settings does not apply anymore.[https://github.com/poettering/systemd/commit/765afd5c4dbc71940d6dd6007ecc3eaa5a0b2aa1] [https://github.com/systemd/systemd/blob/a2088fd025deb90839c909829e27eece40f7fce4/NEWS]}}<br />
<br />
Edit {{ic|/etc/sysctl.d/30-ipforward.conf}} to make the previous change persistent after a reboot for all interfaces:<br />
{{hc|/etc/sysctl.d/30-ipforward.conf|<nowiki><br />
net.ipv4.ip_forward=1<br />
net.ipv6.conf.default.forwarding=1<br />
net.ipv6.conf.all.forwarding=1<br />
</nowiki>}}<br />
<br />
Afterwards it is advisable to double-check forwarding is enabled as required after a reboot.<br />
<br />
=== Enable NAT ===<br />
<br />
[[Install]] the package {{Pkg|iptables}} from the [[official repositories]]. Use iptables to enable NAT:<br />
<br />
# iptables -t nat -A POSTROUTING -o internet0 -j MASQUERADE<br />
# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i net0 -o internet0 -j ACCEPT<br />
<br />
{{Note|Of course, this also works with a mobile broadband connection (usually called ppp0 on routing PC).}}<br />
<br />
Read the [[iptables]] article for more information (especially saving the rule and applying it automatically on boot). There is also an excellent guide on iptables [[Simple stateful firewall]].<br />
<br />
=== Assigning IP addresses to the client PC(s) ===<br />
<br />
If you are planning to regularly have several machines using the internet shared by this machine, then is a good idea to install a [[Wikipedia:DHCP|DHCP server]], such as [[dhcpd]] or [[dnsmasq]]. Then configure a DHCP client (e.g. [[dhcpcd]]) on every client PC.<br />
<br />
{{Style|This is not an iptables guide. Expanding the chain with {{ic|iptables -I}} might skip other important rules; if you need to script an ON/OFF switch for this, use custom chain with a jump placed carefully in the INPUT chain.}}<br />
<br />
Incoming connections to UDP port 67 has to be allowed for DHCP server. It also necessary to allow incoming connections to UDP/TCP port 53 for DNS requests.<br />
# iptables -I INPUT -p udp --dport 67 -i net0 -j ACCEPT<br />
# iptables -I INPUT -p udp --dport 53 -s 192.168.123.0/24 -j ACCEPT<br />
# iptables -I INPUT -p tcp --dport 53 -s 192.168.123.0/24 -j ACCEPT<br />
<br />
If you are not planing to use this setup regularly, you can manually add an IP to each client instead.<br />
<br />
==== Manually adding an IP ====<br />
<br />
Instead of using DHCP, on each client PC, add an IP address and the default route:<br />
# ip addr add 192.168.123.201/24 dev eth0 # arbitrary address, first three blocks must match the address from above<br />
# ip link set up dev eth0<br />
# ip route add default via 192.168.123.100 dev eth0 # same address as in the beginning<br />
<br />
Configure a DNS server for each client, see [[resolv.conf]] for details.<br />
<br />
That's it. The client PC should now have Internet.<br />
<br />
== Troubleshooting ==<br />
<br />
If you are able to connect the two PCs but cannot send data (for example, if the client PC makes a DHCP request to the server PC, the server PC receives the request and offers an IP to the client, but the client does not accept it, timing out instead), check that you do not have other [[Iptables]] rules [https://bbs.archlinux.org/viewtopic.php?pid=1093208 interfering].<br />
<br />
== See also ==<br />
* [http://xyne.archlinux.ca/notes/network/dhcp_with_dns.html Xyne's guide and scripts for launching a subnet with DHCP and DNS]<br />
* [[NetworkManager]] can be configured for internet sharing if used.</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=NetworkManager&diff=438043NetworkManager2016-06-13T07:21:43Z<p>Pelzflorian: Internet sharing: Mind the firewalls.</p>
<hr />
<div>[[Category:Network configuration]]<br />
[[cs:NetworkManager]]<br />
[[de:Networkmanager]]<br />
[[es:NetworkManager]]<br />
[[fr:NetworkManager]]<br />
[[it:NetworkManager]]<br />
[[ja:NetworkManager]]<br />
[[pt:NetworkManager]]<br />
[[ru:NetworkManager]]<br />
[[tr:NetworkManager]]<br />
[[zh-CN:NetworkManager]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|:Category:Network configuration}}<br />
{{Related articles end}}<br />
[http://projects.gnome.org/NetworkManager/ NetworkManager] is a program for providing detection and configuration for systems to automatically connect to network. NetworkManager's functionality can be useful for both wireless and wired networks. For wireless networks, NetworkManager prefers known wireless networks and has the ability to switch to the most reliable network. NetworkManager-aware applications can switch from online and offline mode. NetworkManager also prefers wired connections over wireless ones, has support for modem connections and certain types of VPN. NetworkManager was originally developed by Red Hat and now is hosted by the [[GNOME]] project.<br />
<br />
{{Warning|By default, Wi-Fi passwords are stored in clear text. See section [[#Encrypted Wi-Fi passwords]]}}<br />
<br />
== Installation ==<br />
<br />
NetworkManager can be [[install]]ed with the package {{Pkg|networkmanager}}. The package does not include the tray applet ''nm-applet'' which is part of the {{Pkg|network-manager-applet}}. It has functionality for basic DHCP support. For full featured DHCP and if you require IPv6 support, {{Pkg|dhclient}} integrates it. <br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them. See [[#Configuration]] to enable the NetworkManager service.}}<br />
<br />
=== VPN support ===<br />
<br />
NetworkManager VPN support is based on a plug-in system. If you need VPN support via NetworkManager, you have to install one of the following packages:<br />
<br />
* {{Pkg|networkmanager-openconnect}}<br />
* {{Pkg|networkmanager-openvpn}}<br />
* {{Pkg|networkmanager-pptp}}<br />
* {{Pkg|networkmanager-vpnc}}<br />
* {{AUR|networkmanager-l2tp}}<br />
<br />
{{Warning|1=VPN support is [https://bugzilla.gnome.org/buglist.cgi?quicksearch=networkmanager%20vpn unstable], check the daemon processes options set via the GUI correctly and double-check with each package release.[https://bugzilla.gnome.org/show_bug.cgi?id=755350] [https://bugzilla.gnome.org/show_bug.cgi?id=758772] {{Bug|47535}}}}<br />
<br />
=== PPPoE / DSL support ===<br />
<br />
[[Install]] {{pkg|rp-pppoe}} for PPPoE / DSL connection support.<br />
<br />
== Front-ends ==<br />
<br />
To configure and have easy access to NetworkManager, most users will want to install an applet. This GUI front-end usually resides in the system tray (or notification area) and allows network selection and configuration of NetworkManager. Various applets exist for different types of desktops.<br />
<br />
=== GNOME ===<br />
<br />
[[GNOME]]'s {{Pkg|network-manager-applet}} works in all environments.<br />
<br />
To store authentication details for connections (Wireless/DSL) install and configure [[GNOME Keyring]].<br />
<br />
Be aware that after enabling the tick-box option {{ic|Make available to other users}} for a connection, NetworkManager stores the password in plain-text, though the respective file is accessible only to root (or other users via {{ic|nm-applet}}). See [[#Encrypted Wi-Fi passwords]].<br />
<br />
=== KDE Plasma ===<br />
<br />
[[Install]] the {{Pkg|plasma-nm}} applet.<br />
<br />
=== Xfce ===<br />
<br />
While {{Pkg|network-manager-applet}} works in [[Xfce]], in order to see notifications, including error messages, {{ic|nm-applet}} needs an implementation of the Freedesktop desktop notifications specification (see the [http://www.galago-project.org/specs/notification/0.9/index.html Galapago Project]) to display them. To enable notifications install {{Pkg|xfce4-notifyd}}, a package that provides an implementation for the specification.<br />
<br />
Without such a notification daemon, {{ic|nm-applet}} outputs the following errors to stdout/stderr:<br />
<br />
(nm-applet:24209): libnotify-WARNING **: Failed to connect to proxy<br />
** (nm-applet:24209): WARNING **: get_all_cb: couldn't retrieve<br />
system settings properties: (25) Launch helper exited with unknown<br />
return code 1.<br />
** (nm-applet:24209): WARNING **: fetch_connections_done: error<br />
fetching connections: (25) Launch helper exited with unknown return<br />
code 1.<br />
** (nm-applet:24209): WARNING **: Failed to register as an agent:<br />
(25) Launch helper exited with unknown return code 1<br />
<br />
{{ic|nm-applet}} will still work fine, though, but without notifications.<br />
<br />
If {{ic|nm-applet}} is not prompting for a password when connecting to new wifi networks, and is just disconnecting immediately, you may need to install {{Pkg|gnome-keyring}}. <br />
<br />
Should the applet not appear, install the {{AUR|xfce4-indicator-plugin}} package. [http://askubuntu.com/questions/449658/networkmanager-tray-nm-applet-is-gone-after-upgrade-to-14-04-trusty]<br />
<br />
=== Openbox ===<br />
<br />
To work properly in [[Openbox]], the GNOME applet requires the {{Pkg|xfce4-notifyd}} notification daemon for the same reason as in XFCE and the {{Pkg|gnome-icon-theme}} package to be able to display the applet in the systray.<br />
<br />
If you want to store authentication details (Wireless/DSL) install and configure [[gnome-keyring]].<br />
<br />
{{ic|nm-applet}} installs the autostart file at {{ic|/etc/xdg/autostart/nm-applet.desktop}}. If you have issues with it (e.g. {{ic|nm-applet}} is started twice or is not started at all), see [[Openbox#autostart]] or [https://bbs.archlinux.org/viewtopic.php?pid=993738] for solution.<br />
<br />
=== Other desktops and window managers ===<br />
<br />
In all other scenarios it is recommended to use the GNOME applet. You will also need to be sure that the {{Pkg|gnome-icon-theme}} package is installed to be able to display the applet.<br />
<br />
To store connection secrets install and configure [[GNOME Keyring]].<br />
<br />
In order to run {{ic|nm-applet}} without a systray, you can use {{Pkg|trayer}} or {{Pkg|stalonetray}}. For example, you can add a script like this one in your path:<br />
<br />
{{hc|nmgui|<nowiki><br />
#!/bin/sh<br />
nm-applet 2>&1 > /dev/null &<br />
stalonetray 2>&1 > /dev/null<br />
killall nm-applet<br />
</nowiki>}}<br />
<br />
When you close the ''stalonetray'' window, it closes {{ic|nm-applet}} too, so no extra memory is used once you are done with network settings.<br />
<br />
=== Command line ===<br />
<br />
{{Style|Why is this a subsection of [[#Graphical front-ends]]?}}<br />
<br />
The following applications can be useful for configuring and managing networks without X.<br />
<br />
==== nmcli ====<br />
<br />
A command line frontend, ''nmcli'', is included with {{Pkg|networkmanager}}.<br />
<br />
For usage information, see {{ic|man nmcli}}. Examples:<br />
<br />
* To connect to a wifi network: {{bc|nmcli dev wifi connect <name> password <password>}}<br />
* To connect to a wifi on the {{ic|wlan1}} wifi interface: {{bc|nmcli dev wifi connect <name> password <password> iface wlan1 [profile name]}}<br />
* To disconnect an interface: {{bc|nmcli dev disconnect iface eth0}}<br />
* To reconnect an interface marked as disconnected: {{bc|nmcli con up uuid <uuid>}}<br />
* To get a list of UUIDs: {{bc|nmcli con show}}<br />
* To see a list of network devices and their state: {{bc|nmcli dev}}<br />
* To turn off wifi: {{bc|nmcli r wifi off}}<br />
<br />
==== nmtui ====<br />
<br />
A curses based graphical frontend, ''nmtui'', is included with {{Pkg|networkmanager}}.<br />
<br />
For usage information, see {{ic|man nmtui}}.<br />
<br />
==== nmcli-dmenu ====<br />
<br />
Alternatively there is {{AUR|networkmanager-dmenu-git}} which is a small script to manage NetworkManager connections with ''dmenu'' instead of {{ic|nm-applet}}. It provides all essential features such as connect to existing NetworkManager wifi or wired connections, connect to new wifi connections, requests passphrase if required, connect to existing VPN connections, enable/disable networking, launch ''nm-connection-editor'' GUI.<br />
<br />
== Configuration ==<br />
<br />
NetworkManager will require some additional steps to be able run properly. Make sure you have configured {{ic|/etc/hosts}} as described in [[Network configuration#Set the hostname]] section.<br />
<br />
=== Enable NetworkManager ===<br />
<br />
NetworkManager is [[systemd#Using units|controlled]] via {{ic|NetworkManager.service}}. Once the NetworkManager daemon is started, it will automatically connect to any available "system connections" that have already been configured. Any "user connections" or unconfigured connections will need ''nmcli'' or an applet to configure and connect.<br />
<br />
NetworkManager has a global configuration file at {{ic|/etc/NetworkManager/NetworkManager.conf}}. Usually no configuration needs to be done to the global defaults. <br />
<br />
{{Note|1=NetworkManager will print meaningless warnings ({{Bug|34971}}) to your system log, when [[#Network services with NetworkManager dispatcher|NetworkManager-dispatcher.service]] and [https://www.archlinux.org/packages/?name=modemmanager ModemManager.service] are not enabled. You may enable both to suppress the messages. ''As of May 2016, this is no more a problem because it was "fixed" upstream.''}}<br />
<br />
=== Enable NetworkManager Wait Online ===<br />
<br />
If you have services which fail if they are started before the network is up, you may use {{ic|NetworkManager-wait-online.service}} in addition to {{ic|NetworkManager.service}}. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.<br />
<br />
In some cases, the service will still fail to start successfully on boot due to the timeout setting in {{ic|/usr/lib/systemd/system/NetworkManager-wait-online.service}} being too short. Change the default timeout from 30 to a higher value.<br />
<br />
=== Set up PolicyKit permissions ===<br />
<br />
See [[General troubleshooting#Session permissions]] for setting up a working session.<br />
<br />
With a working session, you have several options for granting the necessary privileges to NetworkManager:<br />
<br />
* ''Option 1.'' Run a [[Polkit]] authentication agent when you log in, such as {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}} (part of {{Pkg|polkit-gnome}}). You will be prompted for your password whenever you add or remove a network connection.<br />
* ''Option 2.'' [[Users and groups#Group management|Add]] yourself to the {{ic|wheel}} group. You will not have to enter your password, but your user account may be granted other permissions as well, such as the ability to use [[sudo]] without entering the root password.<br />
* ''Option 3.'' [[Users and groups#Group management|Add]] yourself to the {{ic|network}} group and create the following file:<br />
<br />
{{hc|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
: All users in the {{ic|network}} group will be able to add and remove networks without a password. This will not work under [[systemd]] if you do not have an active session with ''systemd-logind''.<br />
<br />
=== Network services with NetworkManager dispatcher ===<br />
<br />
There are quite a few network services that you will not want running until NetworkManager brings up an interface. Good examples are [[NTPd]] and network filesystem mounts of various types (e.g. '''netfs'''). NetworkManager has the ability to start these services when you connect to a network and stop them when you disconnect. To activate the feature you need to [[start]] the {{ic|NetworkManager-dispatcher.service}}.<br />
<br />
Once the feature is active, scripts can be added to the {{ic|/etc/NetworkManager/dispatcher.d}} directory. These scripts must be '''owned by root''', otherwise the dispatcher will not execute them. For added security, set group ownership to root as well:<br />
<br />
# chown root:root ''scriptname''<br />
<br />
Also, the script must have '''write permission for owner only''', otherwise the dispatcher will not execute them:<br />
<br />
# chmod 755 ''scriptname''<br />
<br />
The scripts will be run in alphabetical order at connection time, and in reverse alphabetical order at disconnect time. They receive two arguments: the name of the interface (e.g. {{ic|eth0}}) and the status (''up'' or ''down'' for interfaces and ''vpn-up'' or ''vpn-down'' for vpn connections). To ensure what order they come up in, it is common to use numerical characters prior to the name of the script (e.g. {{ic|10_portmap}} or {{ic|30_netfs}} (which ensures that the ''portmapper'' is up before NFS mounts are attempted).<br />
<br />
{{Warning|If you connect to foreign or public networks, be aware of what services you are starting and what servers you expect to be available for them to connect to. You could make a security hole by starting the wrong services while connected to a public network}}<br />
<br />
==== Avoiding the dispatcher timeout ====<br />
<br />
If the above is working, then this section is not relevant. However, there is a general problem related to running dispatcher scripts which take longer to be executed. Initially an internal timeout of three seconds only was used. If the called script did not complete in time, it was killed. Later the timeout was extended to about 20 seconds (see the [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] for more information). If the timeout still creates the problem, a work around may be to modify the dispatcher service file {{ic|/usr/lib/systemd/system/NetworkManager-dispatcher.service}} to remain active after exit: <br />
<br />
{{hc|/etc/systemd/system/NetworkManager-dispatcher.service|2=<br />
.include /usr/lib/systemd/system/NetworkManager-dispatcher.service<br />
[Service]<br />
RemainAfterExit=yes}}<br />
<br />
Now start and enable the modified {{ic|NetworkManager-dispatcher}} service.<br />
<br />
{{Warning|Adding the {{ic|RemainAfterExit}} line to it will prevent the dispatcher from closing. Unfortunately, the dispatcher '''has''' to close before it can run your scripts again. With it the dispatcher will not time out but it also will not close, which means that the scripts will only run once per boot. Therefore, do not add the line unless the timeout is definitely causing a problem.}}<br />
<br />
==== Start OpenNTPD ====<br />
<br />
Install the {{Pkg|networkmanager-dispatcher-openntpd}} package.<br />
<br />
==== Mount remote folder with sshfs ====<br />
<br />
As the script is run in a very restrictive environment, you have to export {{ic|SSH_AUTH_SOCK}} in order to connect to your SSH agent. There are different ways to accomplish this, see [https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 this message] for more information. The example below works with [[GNOME Keyring]], and will ask you for the password if not unlocked already. In case NetworkManager connects automatically on login, it is likely ''gnome-keyring'' has not yet started and the export will fail (hence the sleep). The {{ic|UUID}} to match can be found with the command {{ic|nmcli con status}} or {{ic|nmcli con list}}. <br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
USER='username'<br />
REMOTE='user@host:/remote/path'<br />
LOCAL='/local/path'<br />
<br />
interface=$1 status=$2<br />
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then<br />
case $status in<br />
up)<br />
export SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')<br />
su "$USER" -c "sshfs $REMOTE $LOCAL"<br />
;;<br />
down)<br />
fusermount -u "$LOCAL"<br />
;;<br />
esac<br />
fi<br />
</nowiki>}}<br />
<br />
==== Use dispatcher to connect to a VPN after a network connection is established ====<br />
<br />
In this example we want to connect automatically to a previously defined VPN connection after connecting to a specific Wi-Fi network. First thing to do is to create the dispatcher script that defines what to do after we are connected to the network.<br />
<br />
:1. Create the dispatcher script:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki><br />
#!/bin/sh<br />
VPN_NAME="name of VPN connection defined in NetworkManager"<br />
ESSID="Wi-Fi network ESSID (not connection name)"<br />
<br />
interface=$1 status=$2<br />
case $status in<br />
up|vpn-down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
nmcli con up id "$VPN_NAME"<br />
fi<br />
;;<br />
down)<br />
if iwgetid | grep -qs ":\"$ESSID\""; then<br />
if nmcli con show --active | grep "$VPN_NAME"; then<br />
nmcli con down id "$VPN_NAME"<br />
fi<br />
fi<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you would like to attempt to automatically connect to VPN for all Wi-Fi networks, you can use the following definition of the ESSID: {{ic|1=ESSID=$(iwgetid -r)}}. Remember to set the script's permissions [[#Network services with NetworkManager dispatcher|accordingly]]. <br />
<br />
If you require and tick the {{ic|nm-applet}} option to ''Make the VPN connection available to all users'', trying to connect may still fail and NetworkManager will complain about 'no valid VPN secrets', because of [http://developer.gnome.org/NetworkManager/0.9/secrets-flags.html the way VPN secrets are stored], which brings us to step 2:<br />
<br />
:2. Either edit the VPN connection configuration file to make NetworkManager store the secrets by itself rather than inside a keyring [https://bugzilla.redhat.com/show_bug.cgi?id=710552 that will be inaccessible for root]: open up {{ic|/etc/NetworkManager/system-connections/''name of your VPN connection''}} and change the {{ic|password-flags}} and {{ic|secret-flags}} from {{ic|1}} to {{ic|0}}.<br />
<br />
Alternatively put the password directly in the configuration file adding the section {{ic|vpn-secrets}}:<br />
<br />
[vpn]<br />
....<br />
password-flags=0<br />
<br />
[vpn-secrets]<br />
password=''your_password''<br />
<br />
{{Note|It may now be necessary to re-open the NetworkManager connection editor and save the VPN passwords/secrets again.}}<br />
<br />
==== Use dispatcher to handle mounting of CIFS shares ====<br />
<br />
Some CIFS shares are only available on certain networks or locations (e.g. at home). You can use the dispatcher to only mount CIFS shares that are present at your current location.<br />
<br />
The following script will check if we connected to a specific network and mount shares accordingly:<br />
{{hc|/etc/NetworkManager/dispatcher.d/mount_cifs|<nowiki><br />
#!/bin/bash<br />
if [ "$2" = "up" ]<br />
if [ "$CONNECTION_UUID" = "uuid" ]<br />
mount /your/mount/point & <br />
# add more shares as needed<br />
fi<br />
fi<br />
</nowiki>}}<br />
{{Note|You can get a list of uuids using [[#nmcli|nmcli]].}}<br />
<br />
The following script will unmount all CIFS before a disconnect from a specific network:<br />
{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/mount_cifs|<nowiki><br />
#!/bin/bash<br />
umount -a -l -t cifs<br />
</nowiki>}}<br />
{{Note|Make sure this script is located in the pre-down.d subdirectory as shown above, otherwise it will unmount all shares on any connection state change.}}<br />
{{Note|Ever since NetworkManager 0.9.8, the 'pre-down' and 'down' actions are not executed on shutdown or restart, so the above script will only work if you manually disconnect from the network. See [https://bugzilla.gnome.org/show_bug.cgi?id&#61;701242 this bug report] for more info.}}<br />
<br />
As before, do not forget to set the script permissions [[#Network services with NetworkManager dispatcher|accordingly]].<br />
<br />
See also [[NFS#NetworkManager dispatcher]] for another example script that parses {{ic|/etc/fstab}} mounts during dispatcher actions.<br />
<br />
=== Proxy settings ===<br />
<br />
NetworkManager does not directly handle proxy settings, but if you are using GNOME or KDE, you could use [http://marin.jb.free.fr/proxydriver/ proxydriver] wich handles proxy settings using NetworkManager's informations. proxydriver is found in the package {{AUR|proxydriver}}.<br />
<br />
In order for ''proxydriver'' to be able to change the proxy settings, you would need to execute this command, as part of the GNOME startup process (System -> Preferences -> Startup Applications):<br />
<br />
xhost +si:localuser:''your_username''<br />
<br />
See: [[Proxy settings]].<br />
<br />
=== Disable NetworkManager ===<br />
<br />
It might not be obvious, but the service automatically starts through ''dbus''. To completely disable it you can [[mask]] the services {{ic|NetworkManager}} and {{ic|NetworkManager-dispatcher}}.<br />
<br />
== Testing ==<br />
<br />
NetworkManager applets are designed to load upon login so no further configuration should be necessary for most users. If you have already disabled your previous network settings and disconnected from your network, you can now test if NetworkManager will work. The first step is to [[start]] {{ic|NetworkManager.service}}.<br />
<br />
Some applets will provide you with a {{ic|.desktop}} file so that the NetworkManager applet can be loaded through the application menu. If it does not, you are going to either have to discover the command to use or logout and login again to start the applet. Once the applet is started, it will likely begin polling network connections with for auto-configuration with a DHCP server.<br />
<br />
To start the GNOME applet in non-xdg-compliant window managers like [[awesome]]:<br />
<br />
nm-applet --sm-disable &<br />
<br />
For static IP addresses, you will have to configure NetworkManager to understand them. The process usually involves right-clicking the applet and selecting something like 'Edit Connections'.<br />
<br />
== Troubleshooting ==<br />
<br />
Some fixes to common problems.<br />
<br />
=== No prompt for password of secured Wi-Fi networks ===<br />
<br />
When trying to connect to a secured Wi-Fi network, no prompt for a password is shown and no connection is established. This happens when no keyring package is installed. An easy solution is to install {{Pkg|gnome-keyring}}. If you want the passwords to be stored in encrypted form, follow [[GNOME Keyring]] to set up the ''gnome-keyring-daemon''.<br />
<br />
=== No traffic via PPTP tunnel ===<br />
<br />
PPTP connection logins successfully; you see a ppp0 interface with the correct VPN IP address, but you cannot even ping the remote IP address. It is due to lack of MPPE (Microsoft Point-to-Point Encryption) support in stock Arch pppd. It is recommended to first try with the stock Arch {{Pkg|ppp}} as it may work as intended.<br />
<br />
To solve the problem it should be sufficient to install the {{AUR|ppp-mppe}}{{Broken package link|{{aur-mirror|ppp-mppe}}}} package.<br />
<br />
See also [[WPA2 Enterprise#MS-CHAPv2]].<br />
<br />
=== Network management disabled ===<br />
<br />
When NetworkManager shuts down but the pid (state) file is not removed, you will see a {{ic|Network management disabled}} message. If this happens, remove the file manually:<br />
<br />
# rm /var/lib/NetworkManager/NetworkManager.state<br />
<br />
=== Customizing resolv.conf ===<br />
<br />
See the main page: [[resolv.conf]]. If you use {{Pkg|dhclient}}, you may try the {{AUR|networkmanager-dispatch-resolv}}{{Broken package link|{{aur-mirror|networkmanager-dispatch-resolv}}}} package.<br />
<br />
=== DHCP problems with dhclient ===<br />
<br />
If you have problems with getting an IP address via DHCP, try to add the following to your {{ic|/etc/dhclient.conf}}:<br />
<br />
interface "eth0" {<br />
send dhcp-client-identifier 01:aa:bb:cc:dd:ee:ff;<br />
}<br />
<br />
Where {{ic|aa:bb:cc:dd:ee:ff}} is the MAC address of this NIC. The MAC address can be found using the {{ic|ip link show ''interface''}} command from the {{Pkg|iproute2}} package.<br />
<br />
=== Hostname problems ===<br />
<br />
It depends on the NetworkManager plugins used, whether the hostname is forwarded to a router on connect. The generic "keyfile" plugin does not forward the hostname in default configuration. To make it forward the hostname, add the following to {{ic|/etc/NetworkManager/NetworkManager.conf}}:<br />
<br />
[keyfile]<br />
hostname=''your_hostname''<br />
<br />
The options under {{ic|[keyfile]}} will be applied to network connections in the default {{ic|/etc/NetworkManager/system-connections}} path. <br />
<br />
Another option is to configure the DHCP client, which NetworkManager starts automatically, to forward it. NetworkManager utilizes {{Pkg|dhclient}} in default and falls back to its internal DHCP funtionality, if the former is not installed. To make ''dhclient'' forward the hostname requires to set a non-default option, ''dhcpcd'' forwards the hostname by default. <br />
<br />
First, check which DHCP client is used (''dhclient'' in this example):<br />
<br />
{{hc|<nowiki># journalctl -b | egrep "dhc"</nowiki>|<br />
...<br />
Nov 17 21:03:20 zenbook dhclient[2949]: Nov 17 21:03:20 zenbook dhclient[2949]: Bound to *:546<br />
Nov 17 21:03:20 zenbook dhclient[2949]: Listening on Socket/wlan0<br />
Nov 17 21:03:20 zenbook dhclient[2949]: Sending on Socket/wlan0<br />
Nov 17 21:03:20 zenbook dhclient[2949]: XMT: Info-Request on wlan0, interval 1020ms.<br />
Nov 17 21:03:20 zenbook dhclient[2949]: RCV: Reply message on wlan0 from fe80::126f:3fff:fe0c:2dc.<br />
}}<br />
<br />
==== Configure dhclient to push the hostname to the DHCP server ====<br />
<br />
Copy the example configuration file:<br />
<br />
# cp /usr/share/dhclient/dhclient.conf.example /etc/dhclient.conf<br />
<br />
Take a look at the file - there will only really be one line we want to keep and ''dhclient'' will use it's defaults (as it has been using if you did not have this file) for the other options. This is the important line:<br />
<br />
{{hc|/etc/dhclient.conf|2=send host-name = pick-first-value(gethostname(), "ISC-dhclient");}}<br />
<br />
Force an IP address renewal by your favorite means, and you should now see your hostname on your DHCP server.<br />
<br />
IPv6 push host name:<br />
<br />
# cp /usr/share/dhclient/dhclient.conf.example /etc/dhclient6.conf<br />
<br />
{{hc|/etc/dhclient6.conf|2=send fqdn.fqdn = pick-first-value(gethostname(), "ISC-dhclient");}}<br />
<br />
==== Configure NetworkManager to use a specific DHCP client ====<br />
<br />
If you want to explicitly set the DHCP client used by NetworkManager, it can be set in the global configuration: <br />
<br />
{{hc|1=/etc/NetworkManager/NetworkManager.conf|2=dhcp=internal}}<br />
<br />
The alternative {{ic|1=dhcp=dhclient}} is used per default, if this option is not set. <br />
<br />
Then [[restart]] {{ic|NetworkManager.service}}.<br />
<br />
{{Note|1=Support for {{Pkg|dhcpcd}} has been [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/networkmanager&id=a1df79cbcebaec0c043789eb31965e57d17b6cdb disabled] in {{Pkg|networkmanager}}-1.0.0-2 (2015-02-14).}}<br />
<br />
=== Missing default route ===<br />
<br />
On at least one KDE4 system, no default route was created when establishing wireless connections with NetworkManager. Changing the route settings of the wireless connection to remove the default selection "Use only for resources on this connection" solved the issue.<br />
<br />
=== 3G modem not detected ===<br />
<br />
See [[USB 3G Modem#Network Manager]].<br />
<br />
=== Switching off WLAN on laptops ===<br />
<br />
Sometimes NetworkManager will not work when you disable your Wi-Fi adapter with a switch on your laptop and try to enable it again afterwards. This is often a problem with ''rfkill''. [[Install]] the {{Pkg|rfkill}} package and use:<br />
<br />
$ watch -n1 rfkill list all<br />
<br />
to check if the driver notifies ''rfkill'' about the wireless adapter's status. If one identifier stays blocked after you switch on the adapter you could try to manually unblock it with (where X is the number of the identifier provided by the above output):<br />
<br />
# rfkill event unblock X<br />
<br />
=== Static IP address settings revert to DHCP ===<br />
<br />
Due to an unresolved bug, when changing default connections to a static IP address, {{ic|nm-applet}} may not properly store the configuration change, and will revert to automatic DHCP.<br />
<br />
To work around this issue you have to edit the default connection (e.g. "Auto eth0") in {{ic|nm-applet}}, change the connection name (e.g. "my eth0"), uncheck the "Available to all users" checkbox, change your static IP address settings as desired, and click '''Apply'''. This will save a new connection with the given name.<br />
<br />
Next, you will want to make the default connection not connect automatically. To do so, run {{ic|nm-connection-editor}} ('''not''' as root). In the connection editor, edit the default connection (e.g. "Auto eth0") and uncheck "Connect automatically". Click '''Apply''' and close the connection editor.<br />
<br />
=== Cannot edit connections as normal user ===<br />
<br />
See [[#Set up PolicyKit permissions]].<br />
<br />
=== Forget hidden wireless network ===<br />
<br />
Since hidden networks are not displayed in the selection list of the Wireless view, they cannot be forgotten (removed) with the GUI. You can delete one with the following command:<br />
<br />
# rm /etc/NetworkManager/system-connections/''SSID''<br />
<br />
This works for any other connection.<br />
<br />
=== VPN not working in GNOME ===<br />
<br />
When setting up OpenConnect or vpnc connections in NetworkManager while using GNOME, you will sometimes never see the dialog box pop up and the following error appears in {{ic|/var/log/errors.log}}:<br />
<br />
localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.<br />
<br />
This is caused by the GNOME NM Applet expecting dialog scripts to be at {{ic|/usr/lib/gnome-shell}}, when NetworkManager's packages put them in {{ic|/usr/lib/networkmanager}}.<br />
As a "temporary" fix (this bug has been around for a while now), make the following symlink(s):<br />
<br />
* For OpenConnect: {{ic|ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}<br />
* For VPNC (i.e. Cisco VPN): {{ic|ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}<br />
<br />
This may need to be done for any other NM VPN plugins as well, but these are the two most common.<br />
<br />
=== Unable to connect to visible European wireless networks ===<br />
<br />
WLAN chips are shipped with a default [[Wireless network configuration#Respecting the regulatory domain|regulatory domain]]. If your access point does not operate within these limitations, you will not be able to connect to the network. Fixing this is easy:<br />
<br />
# [[Install]] {{Pkg|crda}}<br />
# Uncomment the correct Country Code in {{ic|/etc/conf.d/wireless-regdom}}<br />
# Reboot the system, because the setting is only read on boot<br />
<br />
=== Automatic connect to VPN on boot is not working ===<br />
<br />
The problem occurs when the system (i.e. NetworkManager running as the root user) tries to establish a VPN connection, but the password is not accessible because it is stored in the Gnome keyring of a particular user. <br />
<br />
A solution is to keep the password to your VPN in plaintext, as described in step (2.) of [[#Use dispatcher to connect to a VPN after a network connection is established]]. <br />
<br />
You do not need to use the dispatcher described in step (1.) to auto-connect anymore, if you use the new "auto-connect VPN" option from the {{ic|nm-applet}} GUI.<br />
<br />
=== Systemd Bottleneck ===<br />
<br />
Over time the log files ({{ic|/var/log/journal}}) can become very large. This can have a big impact on boot performance when using NetworkManager, see: [[Systemd#Boot time increasing over time]].<br />
<br />
=== Regular network disconnects (WiFi) ===<br />
<br />
Some WiFi drivers have issues when scanning for base stations whilst connected/associated. Symptoms include VPN disconnects/reconnects and lost packets, web pages failing to load and then refresh fine.<br />
<br />
Running {{ic|journalctl -f}} will indicate that this is taking place, messages like the following will be contained in the logs at regular intervals.<br />
<br />
NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))<br />
<br />
There is a patched version of NetworkManager which should prevent this type of scanning: {{AUR|networkmanager-noscan}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted Wi-Fi passwords ===<br />
<br />
By default, NetworkManager stores passwords in clear text in the connection files at {{ic|/etc/NetworkManager/system-connections/}}. To print the stored passwords, use the following command:<br />
<br />
# grep -H '^psk=' /etc/NetworkManager/system-connections/*<br />
<br />
The passwords are accessible to the root user in the filesystem and to users with access to settings via the GUI (e.g. {{ic|nm-applet}}). <br />
<br />
If it is preferable to save the passwords in encrypted form instead of clear text, this can be achieved by storing them in a keyring which NetworkManager then queries for the passwords. A suggested keyring daemon is [[GNOME Keyring]] or (for KDE specifically) [[KDE Wallet]]. The keyring daemon has to be started and the keyring needs to be unlocked for the following to work.<br />
<br />
Furthermore, NetworkManager needs to be configured not to store the password for all users. Using GNOME {{ic|nm-applet}}, run {{ic|nm-connection-editor}} from a terminal, select a network connection, click {{ic|Edit}}, select the {{ic|Wifi-Security}} tab and click on the right icon of password and check {{ic|Store the password for this user}}. Using KDE's {{Pkg|kdeplasma-applets-plasma-nm}}{{Broken package link|{{aur-mirror|kdeplasma-applets-plasma-nm}}}}, click the applet, click on the top right {{ic|Settings}} icon, double click on a network connection, in the {{ic|General settings}} tab, untick {{ic|all users may connect to this network}}. If the option is ticked, the passwords will still be stored in clear text, even if a keyring daemon is running.<br />
<br />
If the option was selected previously and you un-tick it, you may have to use the {{ic|reset}} option first to make the password disappear from the file. Alternatively, delete the connection first and set it up again. <br />
<br />
The downside of using the keyring is that the connections have to be set up for each user.<br />
<br />
=== Sharing internet connection over Wi-Fi ===<br />
<br />
You can share your internet connection (e.g. 3G or wired) with a few clicks using nm. You will need a supported Wi-Fi card (Cards based on Atheros AR9xx or at least AR5xx are probably best choice). Please note that a [[firewall]] may interfere with internet sharing.<br />
<br />
==== Ad-hoc ====<br />
<br />
{{Style|"I think so"...}}<br />
<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Custom {{ic|dnsmasq.conf}} may interfere with NetworkManager (not sure about this, but I think so).<br />
* Click on applet and choose "Create new wireless network".<br />
* Follow wizard (if using WEP, be sure to use 5 or 13 character long password, different lengths will fail).<br />
* Settings will remain stored for the next time you need it.<br />
<br />
==== Real AP ====<br />
<br />
Support of infrastructure mode (which is needed by Android phones as they intentionally do not support ad-hoc) is added by NetworkManager as of late 2012.<br />
<br />
See [https://fedoraproject.org/wiki/Features/RealHotspot Fedora's wiki].<br />
<br />
=== Sharing internet connection over Ethernet ===<br />
<br />
Scenario: your device has internet connection over wi-fi and you want to share the internet connection to other devices over ethernet.<br />
<br />
Requirements:<br />
* [[Install]] the {{Pkg|dnsmasq}} package to be able to actually share the connection.<br />
* Your internet connected device and the other devices are connected over a suitable ethernet cable (this usually means a cross over cable or a switch in between).<br />
* Internet sharing is not blocked by a [[firewall]].<br />
<br />
Steps:<br />
* Run {{ic|nm-connection-editor}} from terminal.<br />
* Add a new ethernet connection.<br />
* Give it some sensible name. For example "Shared Internet"<br />
* Go to "IPv4 Settings".<br />
* For "Method:" select "Shared to other computers".<br />
* Save<br />
<br />
Now you should have a new option "Shared Internet" under the Wired connections in NetworkManager.<br />
<br />
=== Checking if networking is up inside a cron job or script ===<br />
<br />
Some ''cron'' jobs require networking to be up to succeed. You may wish to avoid running these jobs when the network is down. To accomplish this, add an '''if''' test for networking that queries NetworkManager's ''nm-tool'' and checks the state of networking. The test shown here succeeds if any interface is up, and fails if they are all down. This is convenient for laptops that might be hardwired, might be on wireless, or might be off the network.<br />
<br />
{{bc|<nowiki><br />
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then<br />
#Whatever you want to do if the network is online<br />
else<br />
#Whatever you want to do if the network is offline - note, this and the else above are optional<br />
fi<br />
</nowiki>}}<br />
<br />
This useful for a {{ic|cron.hourly}} script that runs ''fpupdate'' for the F-Prot virus scanner signature update, as an example. Another way it might be useful, with a little modification, is to differentiate between networks using various parts of the output from ''nm-tool''; for example, since the active wireless network is denoted with an asterisk, you could grep for the network name and then grep for a literal asterisk.<br />
<br />
=== Automatically unlock keyring after login ===<br />
<br />
==== GNOME ====<br />
<br />
# Right click on the {{ic|nm-applet}} icon in your panel and select Edit Connections and open the Wireless tab<br />
# Select the connection you want to work with and click the Edit button<br />
# Check the boxes “Connect Automatically” and “Available to all users”<br />
Log out and log back in to complete.<br />
<br />
{{Note|The following method is dated and known not to work on at least one machine!}}<br />
* In {{ic|/etc/pam.d/gdm}} (or your corresponding daemon in {{ic|/etc/pam.d}}), add these lines at the end of the "auth" and "session" blocks if they do not exist already: <br />
auth optional pam_gnome_keyring.so<br />
session optional pam_gnome_keyring.so auto_start<br />
<br />
* In {{ic|/etc/pam.d/passwd}}, use this line for the 'password' block:<br />
password optional pam_gnome_keyring.so<br />
<br />
:Next time you log in, you should be asked if you want the password to be unlocked automatically on login.<br />
<br />
==== SLiM login manager ====<br />
<br />
See [[SLiM#SLiM and Gnome Keyring]].<br />
<br />
=== KDE and OpenConnect VPN with password authentication ===<br />
<br />
{{Pkg|kdeplasma-applets-plasma-nm}}{{Broken package link|{{aur-mirror|kdeplasma-applets-plasma-nm}}}} now supports configuring username and password for OpenConnect VPN connections. Open your VPN connection, accept the certificate, and connection fields will appear. If not, see the instructions below. Now enter the correct username and password.<br />
<br />
==== Troubleshooting ====<br />
<br />
While you may type both values at connection time, {{Pkg|kdeplasma-applets-plasma-nm}}{{Broken package link|{{aur-mirror|kdeplasma-applets-plasma-nm}}}} 0.9.3.2-1 and above are capable of retrieving OpenConnect username and password directly from KWallet.<br />
<br />
Open "KDE Wallet Manager" and look up your OpenConnect VPN connection under "Network Management|Maps". Click "Show values" and <br />
enter your credentials in key "VpnSecrets" in this form (replace ''username'' and ''password'' accordingly):<br />
<br />
form:main:username%SEP%''username''%SEP%form:main:password%SEP%''password''<br />
<br />
Next time you connect, username and password should appear in the "VPN secrets" dialog box.<br />
<br />
=== Ignore specific devices ===<br />
<br />
Sometimes it may be desired that NetworkManager ignores specific devices and does not try to configure addresses and routes for them.You can quickly and easily ignore devices by MAC or interface-name by using the following in {{ic|/etc/NetworkManager/NetworkManager.conf}}:<br />
[keyfile]<br />
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0<br />
After you have put this in, [[Daemon|restart]] NetworkManager, and you should be able to configure interfaces without NetworkManager altering what you have set.<br />
<br />
=== Enable DNS Caching ===<br />
<br />
See [[dnsmasq#NetworkManager]] to enable the plugin that allows DNS caching using [[dnsmasq]].<br />
<br />
=== Enable IPv6 Privacy Extensions ===<br />
<br />
See [[IPv6#NetworkManager]]<br />
<br />
== See also ==<br />
<br />
* [http://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Multiboot_USB_drive&diff=437809Multiboot USB drive2016-06-10T15:45:37Z<p>Pelzflorian: Fix Fedora Workstation menuentry</p>
<hr />
<div>[[Category:Boot process]]<br />
[[de:Multiboot USB Stick]]<br />
[[ja:マルチブート USB ドライブ]]<br />
{{Related articles start}}<br />
{{Related|GRUB}}<br />
{{Related|Syslinux}}<br />
{{Related|Archiso}}<br />
{{Related articles end}}<br />
{{Move|Multiboot disk images|See discussion|section=Scope and title}}<br />
A multiboot USB flash drive allows booting multiple ISO files from a single device. The ISO files can be copied to the device and booted directly without unpacking them first. There are multiple methods available, but they may not work for all ISO images.<br />
<br />
== Using GRUB and loopback devices ==<br />
<br />
{{Poor writing|multiple [[Help:Style|style]] issues}}<br />
<br />
advantages:<br />
* only a single partition required<br />
* all ISO files are found in one directory<br />
* adding and removing ISO files is simple<br />
<br />
disadvantages:<br />
* not all ISO images are compatible<br />
* the original boot menu for the ISO file is not shown<br />
* it can be difficult to find a working boot entry<br />
<br />
=== Preparation ===<br />
<br />
{{Expansion|How much extra space is needed for the bootloader?}}<br />
<br />
Create at least one partition and a filesystem supported by [[GRUB]] on the USB drive. See [[Partitioning]] and [[File systems#Create a filesystem]]. Choose the size based on the total size of the ISO files that you want to store on the drive, and plan for extra space for the bootloader.<br />
<br />
=== Installing GRUB ===<br />
<br />
==== Simple installation ====<br />
<br />
Mount the filesystem located on the USB drive:<br />
<br />
# mount /dev/sdXY /mnt<br />
<br />
Create the directory /boot:<br />
<br />
# mkdir /mnt/boot<br />
<br />
Install grub on the USB drive:<br />
<br />
# grub-install --target=i386-pc --recheck --boot-directory=/mnt/boot /dev/sdX<br />
<br />
In case you want to boot ISOs in UEFI mode, you have to install grub for the UEFI target:<br />
<br />
# grub-install --target x86_64-efi --efi-directory /mnt --boot-directory=/mnt/boot --removable<br />
<br />
For UEFI, the partition has to be the first one in an MBR partition table and formatted with FAT32.<br />
<br />
==== Hybrid UEFI GPT + BIOS GPT/MBR boot ====<br />
This configuration is useful for creating an universal USB key, bootable everywhere.<br />
First of all you must create a [[GPT]] partition table on your device. You need at least 3 partitions:<br />
# A BIOS boot partition (type EF02)<br />
# An EFI System partition (type EF00)<br />
# Your data partition (use a filesystem supported by [[GRUB]])<br />
<br />
The BIOS boot partition must be sized 1 MB, while the EFI System partition can be at least as small as 50 MB. The data partition can take up the rest of the space of your drive.<br />
<br />
Next you must create a hybrid MBR partition table, as setting the boot flag on the protective MBR partition might not be enough.<br />
<br />
Hybrid MBR partition table creation example using gdisk:<br />
<br />
{{bc|<br />
$ gdisk /dev/sdX<br />
<br />
Command (? for help): r<br />
Recovery/transformation command (? for help): h<br />
Type from one to three GPT partition numbers, separated by spaces, to be added to the hybrid MBR, in sequence: 1 2 3<br />
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): N<br />
<br />
Creating entry for GPT partition #1 (MBR partition #2)<br />
Enter an MBR hex code (default EF): <br />
Set the bootable flag? (Y/N): N<br />
<br />
Creating entry for GPT partition #2 (MBR partition #3)<br />
Enter an MBR hex code (default EF): <br />
Set the bootable flag? (Y/N): N<br />
<br />
Creating entry for GPT partition #3 (MBR partition #4)<br />
Enter an MBR hex code (default 83): <br />
Set the bootable flag? (Y/N): Y<br />
<br />
Recovery/transformation command (? for help): x<br />
Expert command (? for help): h<br />
Expert command (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed? (Y/N): Y<br />
}}<br />
<br />
You can now install GRUB to support both EFI + GPT and BIOS + GPT/MBR. The GRUB configuration (--boot-directory) can be kept in the same place.<br />
<br />
First, you need to mount the EFI System partition and the data partition of your USB drive. Then, you can install GRUB for EFI with:<br />
$ grub-install --target=x86_64-efi --efi-directory=/EFI_MOUNTPOINT --boot-directory=/DATA_MOUNTPOINT/boot --removable --recheck<br />
<br />
And for BIOS with:<br />
$ grub-install --target=i386-pc --boot-directory=/DATA_MOUNTPOINT/boot --recheck /dev/sdX<br />
<br />
As an additional fallback, you can also install GRUB on your MBR-bootable data partition:<br />
$ grub-install --target=i386-pc --boot-directory=/DATA_MOUNTPOINT/boot --recheck /dev/sdX3<br />
<br />
=== Configuring GRUB ===<br />
<br />
==== Using a template ====<br />
There are some git projects which provide some pre-existing GRUB configuration files, and a nice generic grub.cfg which can be used to load the other boot entries on demand, showing them only if the specified ISO files - or folders containing them - are present on the drive.<br />
<br />
Multiboot USB: https://github.com/aguslr/multibootusb<br />
<br />
GLIM (GRUB2 Live ISO Multiboot): https://github.com/thias/glim<br />
<br />
==== Manual configuration ====<br />
<br />
For the purpose of multiboot USB drive it is easier to edit {{ic|grub.cfg}} by hand instead of generating it. Alternatively, make the following changes in {{ic|/etc/grub.d/40_custom}} or {{ic|/mnt/boot/grub/custom.cfg}} and generate {{ic|/mnt/boot/grub/grub.cfg}} using [[GRUB#Generate the main configuration file|grub-mkconfig]].<br />
<br />
As it is recommend to use a [[Persistent block device naming|persistent name]] instead of {{ic|/dev/sd''xY''}} to identify the partition on the USB drive where the image files are located, define a variable for convenience to hold the value. If the ISO images are on the same partition as grub, use the following to read the UUID at boot time:<br />
<br />
{{hc|/mnt/boot/grub/grub.cfg|2=<br />
# path to the partition holding ISO images (using UUID)<br />
probe -u $root --set=rootuuid<br />
set imgdevpath="/dev/disk/by-uuid/$rootuuid"<br />
}}<br />
<br />
Or specify the UUID explicitly:<br />
<br />
{{hc|/mnt/boot/grub/grub.cfg|2=<br />
# path to the partition holding ISO images (using UUID)<br />
set imgdevpath="/dev/disk/by-uuid/''UUID_value''"<br />
}}<br />
<br />
Alternatively, use the device label instead of UUID:<br />
<br />
{{hc|/mnt/boot/grub/grub.cfg|2=<br />
# path to the partition holding ISO images (using labels)<br />
set imgdevpath="/dev/disk/by-label/''label_value''"<br />
}}<br />
<br />
The necessary UUID or label can be found using {{ic|lsblk -f}}. Do not use the same label as the Arch ISO for the USB device, otherwise the boot process will fail.<br />
<br />
To complete the configuration, a boot entry for each ISO image has to be added below this header, see the next section for examples.<br />
<br />
=== Boot entries ===<br />
<br />
{{Poor writing|The only boxes used should be code blocks, otherwise the section will be unreadable. Anything else should be plain text.}}<br />
<br />
It is assumed that the ISO images are stored in the {{ic|boot/iso/}} directory on the same filesystem where GRUB is installed. Otherwise it would be necessary to prefix the path to ISO file with device identification when using the {{ic|loopback}} command, for example {{ic|loopback loop '''(hd1,2)'''$isofile}}. As this identification of devices is not [[Persistent block device naming|persistent]], it is not used in the examples in this section.<br />
<br />
One can use persistent block device naming like this:<br />
{{bc|1=<br />
# define globally (i.e outside any menuentry)<br />
insmod search_fs_uuid<br />
search --no-floppy --set='''isopart''' --fs-uuid d6de9100-1981-11e5-9fb9-74867a652f05 # your iso fs uuid here<br />
# later use inside each menuentry instead<br />
loopback loop '''($isopart)'''$isofile<br />
}}<br />
<br />
{{Tip| For a list of kernel parameters, see https://www.kernel.org/doc/Documentation/kernel-parameters.txt (still incomplete)}}<br />
<br />
==== Alpine Linux ====<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|x86}}.}}<br />
<br />
* Initramfs framework: ???<br />
* Live framework: ???<br />
* Init system: [http://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System OpenRC] (cmdline: ''RFD'')<br />
<br />
{{bc|1=<br />
menuentry '[loopback]alpine x86_64' {<br />
set isofile='/boot/iso/alpine-3.3.3-x86_64.iso'<br />
loopback loop $isofile<br />
set root=loop<br />
linux /boot/vmlinuz-grsec modloop=/boot/modloop-grsec modules=loop,squashfs,sd-mod,usb-storage quiet<br />
initrd /boot/initramfs-grsec<br />
}<br />
}}<br />
<br />
==== Alt Linux ====<br />
<br />
* Initramfs framework: ???<br />
* Live framework: ???<br />
* Init system: ???<br />
<br />
{{bc|1=<br />
menuentry "[loopback]altlinux-7.0.5-simply-x86_64-install-dvd5.iso" {<br />
set gfxpayload=keep<br />
insmod gzio<br />
insmod part_msdos<br />
insmod ext2<br />
insmod xfs<br />
set bootpart=uuid:df46d821-e7f9-4e35-bbd2-728bdce8d89a<br />
set isodir=/boot/iso<br />
set isofile=altlinux-7.0.5-simply-x86_64-install-dvd5.iso<br />
loopback loop (${root})${isodir}/${isofile}<br />
linux (loop)/syslinux/alt0/vmlinuz automatic=method:disk,${bootpart},directory:${isodir}/${isofile} ramdisk_size=183210 changedisk lang=ru_RU splash noeject xdriver=auto quiet=1 showopts<br />
initrd (loop)/syslinux/alt0/full.cz<br />
}<br />
}}<br />
<br />
==== Arch Linux ====<br />
<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
<br />
===== monthly release =====<br />
<br />
* Initramfs framework: [[mkinitcpio]] (cmdline: [https://projects.archlinux.org/mkinitcpio.git/tree/man/mkinitcpio.8.txt#n212])<br />
* Live framework: [[archiso]] (cmdline: [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams])<br />
* Init system: [[systemd]] (cmdline: [http://www.freedesktop.org/software/systemd/man/kernel-command-line.html])<br />
<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.12.01-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2014.12.01-dual.iso'<br />
loopback loop $isofile<br />
linux (loop)/arch/boot/'''x86_64'''/vmlinuz archisodevice=/dev/loop0 img_dev=$imgdevpath img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/'''x86_64'''/archiso.img<br />
}<br />
}}<br />
<br />
{{note|As of archiso v23 (monthly release 2015.10.01), the parameter {{ic|1=archisodevice=/dev/loop0}} is no longer necessary when boot using GRUB and loopback devices.}}<br />
<br />
===== archboot =====<br />
<br />
* Initramfs framework: [[mkinitcpio]] (cmdline: [https://projects.archlinux.org/mkinitcpio.git/tree/man/mkinitcpio.8.txt#n212])<br />
* Live framework: [[archboot]] (cmdline: none? ''RFD'')<br />
* Init system: [[systemd]] (cmdline: [http://www.freedesktop.org/software/systemd/man/kernel-command-line.html])<br />
<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.11-1-archboot' {<br />
set isofile='/boot/iso/archlinux-2014.11-1-archboot.iso'<br />
loopback loop $isofile<br />
linux (loop)/boot/vmlinuz_'''x86_64''' iso_loop_dev=$imgdevpath iso_loop_path=$isofile<br />
initrd (loop)/boot/initramfs_'''x86_64'''.img<br />
}<br />
}}<br />
<br />
==== CentOS ====<br />
<br />
===== Stock installation medium =====<br />
<br />
* Initramfs framework: [https://fedoraproject.org/wiki/Dracut Dracut] (cmdline: [https://git.kernel.org/cgit/boot/dracut/dracut.git/tree/dracut.cmdline.7.asc])<br />
* Installation program: [https://fedoraproject.org/wiki/Anaconda Anaconda] (cmdline: [https://github.com/rhinstaller/anaconda/blob/master/docs/boot-options.rst])<br />
* Init system: [[systemd]] (cmdline: [http://www.freedesktop.org/software/systemd/man/kernel-command-line.html])<br />
<br />
{{bc|1=<br />
menuentry "[loopback]CentOS-7.0-1406-x86_64-'''DVD'''" {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-'''DVD'''.iso'<br />
loopback loop $isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
{{tip|1=The boot parameter of second stage install image location {{ic|1=/dev/sdb2}} which is used by Anaconda, is similar to [[fstab]]'s first field (fs_spec), could be replaced with one of:<br />
* {{ic|1=/dev/sd'''''xY'''''}}<br />
* {{ic|1=LABEL=MYUSBSTICK}}<br />
* {{ic|1=UUID=00000000-0000-0000-0000-0000deadbeef}}<br />
<br />
For example, {{ic|1=linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''LABEL=MYUSBSTICK''':/$isofile}}.<br />
<br />
When using some special disk label (e.g. GPT), it's also possible to use {{ic|1=PARTUUID=}} and/or {{ic|1=PARTLABEL=}}.<br />
}}<br />
<br />
===== Desktop live medium =====<br />
<br />
* Initramfs framework: [https://fedoraproject.org/wiki/Dracut Dracut] (cmdline: [https://git.kernel.org/cgit/boot/dracut/dracut.git/tree/dracut.cmdline.7.asc])<br />
* Live framework: fedora [https://fedoraproject.org/wiki/FedoraLiveCD livecd-tools] (cmdline: none)<br />
* Init system: [[systemd]] (cmdline: [http://www.freedesktop.org/software/systemd/man/kernel-command-line.html])<br />
<br />
{{bc|1=<br />
menuentry '[loopback]CentOS-7.0-1406-x86_64-GnomeLive' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-GnomeLive.iso'<br />
loopback loop $isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=CentOS-7-live-GNOME-x86_64 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Clonezilla Live ====<br />
{{tip|1=Since 2014.01.05[https://projects.archlinux.org/archiso.git/commit/?id=5cd02c704046cdb6974f6b10f0cac366eeebec0e], the Arch Linux monthly release contains clonezilla.}}<br />
<br />
* Initramfs framework: [https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/ initramfs-tools] (cmdline: ''RFD'')<br />
* Live framework: [http://live.debian.net/ Debian Live] (cmdline: [http://manpages.debian.org/cgi-bin/man.cgi?query=live-boot&apropos=0&sektion=7&manpath=Debian+unstable+sid&format=html&locale=en])<br />
* Init system: [https://savannah.nongnu.org/projects/sysvinit sysvinit] (cmdline: ''RFD'')<br />
<br />
{{bc|1=<br />
menuentry "[loopback]clonezilla-live-2.2.3-25-amd64" {<br />
set isofile="/boot/iso/clonezilla-live-2.2.3-25-amd64.iso"<br />
loopback loop $isofile<br />
linux (loop)/live/vmlinuz findiso=$isofile boot=live union=overlay username=user config<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== Debian ====<br />
<br />
===== Stock install medium =====<br />
<br />
* Initramfs framework: [https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/ initramfs-tools] (cmdline: ''RFD'')<br />
* Installation program: [https://wiki.debian.org/DebianInstaller#Development debian-installer] (cmdline: ''exists but missing online documentation'')<br />
* Init system: [https://savannah.nongnu.org/projects/sysvinit sysvinit] (cmdline: ''RFD'')<br />
<br />
{{tip|To install debian from any stock install medium on a non-optical medium (e.g. usb stick, HDD), it's necessary to use a different initramfs instead of the default one on the installation medium which is located at {{ic|(loop)/install.amd/initrd.gz}}. If you boot with the default one, the installer will unable to find or mount the proper iso image for installation.<br />
<br />
Please download the initramfs for hard disk installation from [https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/initrd.gz an official mirror site], put it in the same directory with the image file and give it a suitable name ({{ic|debian-7.8.0-amd64-DVD-1.hdd.initrd.gz}} in this example).}}<br />
<br />
{{bc|1=<br />
menuentry '[loopback]debian-7.8.0-amd64-DVD-1' {<br />
set isofile='/boot/iso/debian-7.8.0-amd64-DVD-1.iso'<br />
set initrdfile='/boot/iso/debian-7.8.0-amd64-DVD-1.hdd.initrd.gz'<br />
loopback loop $isofile<br />
linux (loop)/install.amd/vmlinuz vga=791 iso-scan/ask_second_pass=true iso-scan/filename=$isofile<br />
initrd $initrdfile<br />
}<br />
}}<br />
<br />
===== Live install medium =====<br />
<br />
* Initramfs framework: [https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/ initramfs-tools] (cmdline: ''RFD'')<br />
* Live framework: [http://live.debian.net/ Debian Live] (cmdline: [http://manpages.debian.org/cgi-bin/man.cgi?query=live-boot&apropos=0&sektion=7&manpath=Debian+unstable+sid&format=html&locale=en])<br />
* Init system: [https://savannah.nongnu.org/projects/sysvinit sysvinit] (cmdline: ''RFD'')<br />
<br />
{{bc|1=<br />
menuentry '[loopback]debian-live-7.8.0-amd64-xfce-desktop' {<br />
set isofile='/boot/iso/debian-live-7.8.0-amd64-xfce-desktop.iso'<br />
loopback loop $isofile<br />
linux (loop)/live/vmlinuz boot=live config fromiso='''/dev/sdb2'''/$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
{{note|It's also OK to use {{ic|1=findiso=$isofile}} instead of the longer {{ic|1=fromiso=/dev/disk/by-.../.../$isofile}}. Anyway, using {{ic|1=fromiso=}} instead of {{ic|1=findiso=}} may speed up the initialization progress because it avoids unnecessary mounting.}}<br />
<br />
==== Elementary OS ====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework or installation program: ''RFD''<br />
* Init system: upstart (cmdline: ''RFD'')<br />
<br />
{{bc|1=<br />
menuentry '[loopback]elementaryos-freya-amd64.20150411' {<br />
set isofile='/boot/iso/elementaryos-freya-amd64.20150411.iso'<br />
loopback loop $isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
==== Fedora ====<br />
<br />
===== Stock installation medium =====<br />
<br />
* Initramfs framework: [https://fedoraproject.org/wiki/Dracut Dracut] (cmdline: [https://git.kernel.org/cgit/boot/dracut/dracut.git/tree/dracut.cmdline.7.asc])<br />
* Installation program: [https://fedoraproject.org/wiki/Anaconda Anaconda] (cmdline: [https://github.com/rhinstaller/anaconda/blob/master/docs/boot-options.rst])<br />
* Init system: [[systemd]] (cmdline: [http://www.freedesktop.org/software/systemd/man/kernel-command-line.html])<br />
<br />
{{bc|1=<br />
menuentry '[loopback]Fedora-20-x86_64-DVD' {<br />
set isofile='/boot/iso/Fedora-20-x86_64-DVD.iso'<br />
loopback loop $isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
===== Workstation live medium =====<br />
<br />
* Initramfs framework: [https://fedoraproject.org/wiki/Dracut Dracut] (cmdline: [https://git.kernel.org/cgit/boot/dracut/dracut.git/tree/dracut.cmdline.7.asc])<br />
* Live framework: fedora [https://fedoraproject.org/wiki/FedoraLiveCD livecd-tools] (cmdline: none)<br />
* Init system: [[systemd]] (cmdline: [http://www.freedesktop.org/software/systemd/man/kernel-command-line.html])<br />
<br />
{{bc|1=<br />
menuentry '[loopback]Fedora-Live-Workstation-x86_64-23-10' {<br />
set isofile='/boot/iso/Fedora-Live-Workstation-x86_64-23-10.iso'<br />
loopback loop $isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-WS-x86_64-23-10 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Gentoo ====<br />
===== Desktop LiveDVD =====<br />
<br />
* Initramfs framework: [https://wiki.gentoo.org/wiki/Genkernel genkernel] (cmdline: [https://gitweb.gentoo.org/proj/genkernel.git/tree/doc/genkernel.8.txt#n393])<br />
* Live framework: [https://gitweb.gentoo.org/proj/livecd-tools.git/ livecd-tools] (cmdline: ''RFD'')<br />
* Init system: [https://wiki.gentoo.org/wiki/Project:OpenRC OpenRC] (cmdline: ''RFD'')<br />
<br />
{{bc|1=<br />
menuentry "[loopback]livedvd-amd64-multilib-20160514" {<br />
set isofile="/boot/iso/livedvd-amd64-multilib-20160514.iso"<br />
loopback loop $isofile<br />
linux (loop)/isolinux/gentoo root=/dev/ram0 init=/linuxrc aufs looptype=squashfs loop=/image.squashfs cdroot isoboot=$isofile vga='''791''' splash=silent,theme:default console=tty0<br />
initrd (loop)/isolinux/gentoo.xz <br />
}<br />
}}<br />
<br />
{{Tip|This should also works for minimal medium.}}<br />
<br />
==== GParted Live ====<br />
<br />
* Initramfs framework: [https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/ initramfs-tools] (cmdline: ''RFD'')<br />
* Live framework: [http://live.debian.net/ Debian Live] (cmdline: [http://manpages.debian.org/cgi-bin/man.cgi?query=live-boot&apropos=0&sektion=7&manpath=Debian+unstable+sid&format=html&locale=en])<br />
* Init system: [https://savannah.nongnu.org/projects/sysvinit sysvinit] (cmdline: ''RFD'')<br />
<br />
{{bc|1=<br />
menuentry "[loopback]gparted-live-0.22.0-2-'''amd64'''" {<br />
set isofile="/boot/iso/gparted-live-0.22.0-2-'''amd64'''.iso"<br />
loopback loop $isofile<br />
linux (loop)/live/vmlinuz boot=live union=overlay username=user config components quiet noswap noeject toram=filesystem.squashfs ip= nosplash findiso=$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== Kali Linux ====<br />
<br />
* Initramfs framework: [https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/ initramfs-tools] (cmdline: ''RFD'')<br />
* Live framework: [http://live.debian.net/ Debian Live] (cmdline: [http://manpages.debian.org/cgi-bin/man.cgi?query=live-boot&apropos=0&sektion=7&manpath=Debian+unstable+sid&format=html&locale=en])<br />
* Init system: [https://savannah.nongnu.org/projects/sysvinit sysvinit] (cmdline: ''RFD'')<br />
<br />
{{bc|1=<br />
menuentry "[loopback]kali-linux-1.0.7-'''amd64'''" {<br />
set isofile='/boot/iso/kali-linux-1.0.7-'''amd64'''.iso'<br />
loopback loop $isofile<br />
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== Knoppix ====<br />
<br />
* Initramfs framework: ''Unknown''<br />
* Live framework: ''Unknown''<br />
* Init system: ''Unknown''<br />
<br />
{{bc|1=<br />
menuentry "[loopback]KNOPPIX_V7.4.2DVD-2014-09-28-EN" {<br />
set isofile="/boot/iso/KNOPPIX_V7.4.2DVD-2014-09-28-EN.iso"<br />
loopback loop $isofile<br />
linux (loop)/boot/isolinux/linux bootfrom=/mnt-iso/$isofile acpi=off keyboard=us lang=us<br />
initrd (loop)/boot/isolinux/minirt.gz<br />
}<br />
}}<br />
<br />
==== Linux Mint ====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework or installation program: ''RFD''<br />
* Init system: ''RFD''<br />
<br />
{{bc|1=<br />
menuentry "[loopback]linuxmint-201403-cinnamon-dvd-'''32'''bit" {<br />
set isofile="/boot/iso/linuxmint-201403-cinnamon-dvd-'''32'''bit.iso"<br />
loopback loop $isofile<br />
linux (loop)/live/vmlinuz isofrom='''/dev/sdb2'''/iso/$isofile boot=live live-config live-media-path=/live quiet splash noeject noprompt<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
If you boot with the above configuration and get the error message '/live/vmlinuz not found' try the below<br />
<br />
{{bc|1=<br />
menuentry "Linux Mint 17.2 Cinnamon LTS RC (x64)" {<br />
set iso=/boot/iso/linuxmint-17.2-cinnamon-64bit.iso<br />
loopback loop $iso<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$iso noeject noprompt <br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
==== openSUSE ====<br />
<br />
===== Stock installation medium =====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework or installation program: Kiwi? ''RFD''<br />
* Init system: ''RFD''<br />
<br />
{{bc|1=<br />
menuentry '[loopback]openSUSE-13.1-DVD-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-DVD-x86_64.iso'<br />
loopback loop $isofile<br />
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
===== Desktop Live medium =====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework or installation program: Kiwi? ''RFD''<br />
* Init system: ''RFD''<br />
<br />
{{bc|1=<br />
menuentry '[loopback]openSUSE-13.1-KDE-Live-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-KDE-Live-x86_64.iso'<br />
loopback loop $isofile<br />
linux (loop)/boot/x86_64/loader/linux isofrom_device=$imgdevpath isofrom_system=$isofile LANG='''en_US.UTF-8'''<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
==== Parabola GNU/Linux-libre ====<br />
<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
<br />
{{bc|1=<br />
menuentry '[loopback]parabola-2015.07.01-dual.iso' {<br />
set isofile='/boot/iso/parabola-2015.07.01-dual.iso'<br />
loopback loop $isofile<br />
linux (loop)/parabola/boot/'''x86_64'''/vmlinuz parabolaisolabel=PARA_'''201507''' img_dev=$imgdevpath img_loop=$isofile earlymodules=loop<br />
initrd (loop)/parabola/boot/'''x86_64'''/parabolaiso.img<br />
}<br />
}}<br />
<br />
{{Tip| The label string after {{ic|1=parabolaisolabel=}} needs to be edited when a newer release is used.}}<br />
<br />
==== Sabayon ====<br />
<br />
* Initramfs framework: genkernel? ''RFD''<br />
* Live framework or installation program: ''RFD''<br />
* Init system: openrc? ''RFD''<br />
<br />
{{bc|1=<br />
menuentry '[loopback]Sabayon_Linux_14.05_amd64_KDE' {<br />
set isofile='/boot/iso/Sabayon_Linux_14.05_amd64_KDE.iso'<br />
loopback loop $isofile<br />
linux (loop)/boot/sabayon root=/dev/ram0 aufs cdroot locale='''en_US''' loop=/livecd.squashfs looptype=squashfs isoboot=$isofile<br />
initrd (loop)/boot/sabayon.igz<br />
}<br />
}}<br />
<br />
==== Slackware Linux ====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework or installation program: ''RFD''<br />
* Init system: ''RFD''<br />
<br />
{{bc|1=<br />
menuentry '[loopback]slackware64-14.1-install-dvd' {<br />
set isofile='/boot/iso/slackware64-14.1-install-dvd.iso'<br />
loopback loop $isofile<br />
linux (loop)/kernels/huge.s/bzImage printk.time=0<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
==== SystemRescueCD ====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework or installation program: ''RFD''<br />
* Init system: ''RFD''<br />
<br />
{{note|Replace {{ic|64}} with {{ic|32}} if you want to boot into a 32-bit system.}}<br />
{{bc|1=<br />
menuentry '[loopback]systemrescuecd-x86-4.5.2' {<br />
set isofile='/boot/iso/systemrescuecd-x86-4.5.2.iso'<br />
loopback loop $isofile<br />
linux (loop)/isolinux/rescue'''64''' isoloop=$isofile<br />
initrd (loop)/isolinux/initram.igz<br />
}<br />
}}<br />
<br />
==== Slitaz ====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework: ''RFD''<br />
* Init system: ''RFD''<br />
<br />
First, download slitaz iso, then extract somewhere (in this case, /live/slitaz-4.0 on /dev/sda3)<br />
<br />
{{bc|1=<br />
menuentry 'slitaz-4.0 core' {<br />
set dir='/live/slitaz-4.0'<br />
set root=(hd0,msdos3)<br />
set lang='pt_BR'<br />
set kmap='br-abnt2'<br />
linux ($root)/$dir/bzImage lang=$lang kmap=$kmap rw root=/dev/null vga=normal autologin<br />
initrd ($root)/$dir/rootfs4.gz ($root)/$dir/rootfs3.gz ($root)/$dir/rootfs2.gz ($root)/$dir/rootfs1.gz<br />
}<br />
}}<br />
<br />
==== Slax ====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework: ''RFD''<br />
* Init system: ''RFD''<br />
<br />
First, download Slax zip (for USB), then extract somewhere (in this case, /live/slax on /dev/sda3)<br />
<br />
{{bc|1=<br />
menuentry 'slax' {<br />
set dir=/live/slax<br />
set root=(hd0,msdos3)<br />
linux $dir/boot/vmlinuz from=$dir vga=normal load_ramdisk=1 prompt_ramdisk=0 printk.time=0 slax.flags=perch,xmode<br />
initrd $dir/boot/initrfs.img<br />
}<br />
}}<br />
<br />
==== Tails ====<br />
<br />
* Initramfs framework: ''Unknown''<br />
* Live framework: ''Unknown''<br />
* Init system: ''Unknown''<br />
<br />
Simply download and verify integrity of the Tails iso.<br />
<br />
{{bc|1=<br />
menuentry "[loopback]tails-i386-1.5.iso" {<br />
set isofile='/boot/iso/tails-i386-1.5.iso'<br />
loopback loop $isofile<br />
linux (loop)/live/vmlinuz2 boot=live config findiso=${isofile} live-media=removable apparmor=1 security=apparmor nopersistent noprompt timezone=Etc/UTC block.events_dfl_poll_msecs=1000 noautologin module=Tails<br />
initrd (loop)/live/initrd2.img<br />
}<br />
}}<br />
<br />
{{Warning|Emergency memory erasure does not seem to work when booting this way.}}<br />
<br />
Remove the {{ic|1=live-media=removable}} option if the iso file is not on removable media.<br />
<br />
==== Ubuntu ====<br />
<br />
* Initramfs framework: ''RFD''<br />
* Live framework or installation program: ''RFD''<br />
* Init system: upstart (cmdline: ''RFD'')<br />
<br />
{{bc|1=<br />
menuentry '[loopback]ubuntu-14.04.1-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04.1-desktop-amd64.iso'<br />
loopback loop $isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
==== Xubuntu (32 bit) ====<br />
{{bc|1=<br />
menuentry '[loopback]Xubuntu-16.04-desktop-i386' {<br />
set isofile='/boot/iso/xubuntu-16.04-desktop-i386.iso'<br />
loopback loop $isofile<br />
linux (loop)/casper/vmlinuz file=/cdrom/preseed/xubuntu.seed boot=casper iso-scan/filename=$isofile quiet splash ---<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
== Chainloading Windows ==<br />
<br />
It can be very difficult to loopback a Windows install disc. One simple solution that allows you to install a variety of platforms from a USB drive with a single, unified partition is to start with a working, bootable Windows USB drive, and to replace its bootloader with GRUB.<br />
<br />
Before installing GRUB, rename or move the Windows bootloader. It should be the default ''.efi'' executable - located at {{ic|''(USB)''/efi/boot/bootx64.efi}} for a 64-bit system. Install GRUB in its place, and ensure that it is now the default executable.<br />
<br />
You can then chainload the renamed Windows bootloader from GRUB, and also configure GRUB to loopback ''.iso'' files as described above.<br />
<br />
{{bc|1=<br />
menuentry '[chain]en_windows_8.1_professional_x64' {<br />
insmod chain<br />
chainloader /efi/boot/bootx64.efi.windows<br />
}<br />
}}<br />
<br />
== Using Syslinux and memdisk ==<br />
<br />
Using the [http://www.syslinux.org/wiki/index.php/MEMDISK memdisk] module, the ISO image is loaded into memory, and its bootloader is loaded. Make sure that the system that will boot this USB drive has sufficient amount of memory for the image file and running operating system.<br />
<br />
=== Preparation ===<br />
<br />
Make sure that the USB drive is properly [[Partitioning|partitioned]] and that there is a partition with [[file system]] supported by Syslinux, for example fat32 or ext4. Then install Syslinux to this partition, see [[Syslinux#Installation]].<br />
<br />
=== Install the memdisk module ===<br />
<br />
The memdisk module was not installed during Syslinux installation, it has to be installed manually. Mount the partition where Syslinux is installed to {{ic|/mnt/}} and copy the memdisk module to the same directory where Syslinux is installed:<br />
<br />
# cp /usr/lib/syslinux/bios/memdisk /mnt/boot/syslinux/<br />
<br />
=== Configuration ===<br />
<br />
After copying the ISO files on the USB drive, edit the [[Syslinux#Configuration|Syslinux configuration file]] and create menu entries for the ISO images. The basic entry looks like this:<br />
<br />
{{hc|boot/syslinux/syslinux.cfg|<br />
LABEL ''some_label''<br />
LINUX memdisk<br />
INITRD ''/path/to/image.iso''<br />
APPEND iso<br />
}}<br />
<br />
See [http://www.syslinux.org/wiki/index.php/MEMDISK memdisk on Syslinux wiki] for more configuration options.<br />
<br />
=== Caveat for 32-bit systems ===<br />
<br />
When booting a 32-bit system from an image larger than 128MiB, it is necessary to increase the maximum memory usage of vmalloc. This is done by adding {{ic|1=vmalloc=''value''M}} to the kernel parameters, where {{ic|''value''}} is larger than the size of the ISO image in MiB.[http://www.syslinux.org/wiki/index.php/MEMDISK#-_memdiskfind_in_combination_with_phram_and_mtdblock]<br />
<br />
For example when booting the 32-bit system from the [https://www.archlinux.org/download/ Arch installation ISO], press the {{ic|Tab}} key over the {{ic|Boot Arch Linux (i686)}} entry and add {{ic|1=vmalloc=768M}} at the end. Skipping this step will result in the following error during boot:<br />
<br />
modprobe: ERROR: could not insert 'phram': Input/output error<br />
<br />
== See also ==<br />
<br />
* GRUB:<br />
** https://help.ubuntu.com/community/Grub2/ISOBoot/Examples<br />
** https://help.ubuntu.com/community/Grub2/ISOBoot<br />
* Syslinux:<br />
** [http://www.syslinux.org/wiki/index.php/Boot_an_Iso_image Boot an ISO image]</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Vino&diff=435673Vino2016-05-19T21:24:46Z<p>Pelzflorian: Add instructions for headless servers</p>
<hr />
<div>[[Category:Remote desktop]]<br />
[[Category:GNOME]]<br />
[[ja:Vino]]<br />
'''Vino''' is a VNC (Virtual Network Computing) server allowing remote connection to your actual desktop. It is a default component of the [[GNOME]] [[Desktop environment]].<br />
<br />
== Installation ==<br />
<br />
=== GNOME ===<br />
[[Install]] the package {{Pkg|vino}}, which is available in the [[official repositories]].<br />
<br />
You need to restart GNOME so that {{ic|vino-server}} is started automatically when enabling the remote desktop feature. The remote desktop feature can usually be enabled in Settings > Sharing, however this only seems to be functional when [[NetworkManager]] is installed and functional.<br />
<br />
=== Alternative Desktop Environments ===<br />
As of version 3.9.2, Vino no longer includes a standalone preferences dialog (see [https://bugzilla.gnome.org/show_bug.cgi?id=700070 bug 700070]), thus making configuration difficult without the GNOME Control Center.<br />
<br />
The easiest solution is to install {{AUR|vino38}} from the [[AUR]], which provides the latest version with the preferences dialog, accessible via the {{ic|vino-preferences}} command.<br />
<br />
== Configuration ==<br />
<br />
You can configure vino via gnome-control-center.<br />
<br />
Now you can connect remotely to your desktop via a VNC viewer like TightVNC or Remmina. Remember to forward port 5900 if you are behind a NAT device and to allow the connection through iptables.<br />
<br />
If you are having problems regarding security and encryption you could try:<br />
<br />
$ gsettings set org.gnome.Vino require-encryption false<br />
<br />
If you use a standalone [[window manager]] like [[Openbox]] and it does not work, you can start {{ic|vino-server}} manually or add the command to the window manager's autostart script<br />
<br />
# /usr/lib/vino/vino-server &<br />
<br />
== Running on a headless server ==<br />
<br />
Vino can be used to manage a headless server with a graphical desktop via VNC. For this, a graphics driver like {{Pkg|xf86-video-dummy}} must be installed and [[Xorg#Configuration|configured]]. [http://xpra.org/xorg.conf xpra's sample xorg.conf] for the Xdummy driver can be used as a base. Then, the server can be configured to [[Xinitrc#Autostart_X_at_login|start X at boot]] for the user account that should be usable remotely. Vino must be made to [[Desktop_entries#Autostart|autostart with the desktop environment]] by creating a desktop entry in the user's home directory such as this one:<br />
<br />
{{hc|~/.config/autostart/vino-server.desktop|2=<br />
[Desktop Entry]<br />
Type=Application<br />
Name=Vino VNC server<br />
Exec=/usr/lib/vino/vino-server<br />
NoDisplay=true<br />
}}<br />
<br />
Next, make Vino accept VNC connections without asking for confirmation by running the following command as the graphical desktop user:<br />
<br />
$ dbus-launch gsettings set org.gnome.Vino prompt-enabled false<br />
<br />
You may wish to revoke suspend and hibernate permissions using [[Polkit]].<br />
<br />
For the [[GNOME]] desktop environment, the following are some further options you may want for GNOME:<br />
<br />
$ dbus-launch gsettings set org.gnome.desktop.lockdown disable-user-switching true<br />
$ dbus-launch gsettings set org.gnome.desktop.lockdown disable-log-out true<br />
$ dbus-launch gsettings set org.gnome.desktop.interface enable-animations false<br />
<br />
Remember to configure your [[Firewalls|firewall]] to not block the {{ic|rfb}} port used for VNC. For secure authentication – which should be used when giving access to privileged users on the open internet –, you should tunnel the VNC protocol through e.g. [[Secure Shell|SSH]] or {{Pkg|stunnel}} instead of unblocking the {{ic|rfb}} port. When using stunnel, you should require a [[Security#Passwords|password]]:<br />
<br />
$ dbus-launch gsettings set org.gnome.Vino authentication-methods "['vnc']"<br />
$ dbus-launch gsettings set org.gnome.Vino vnc-password $(echo "mypassword"|base64)<br />
<br />
You can now log in to your server with a VNC client such as {{Pkg|vinagre}}.<br />
<br />
The above setup can also be used with multiple remote users logging in automatically, e.g. by using multiple copies of {{AUR|xlogin-git}}'s service files in {{ic|/etc/systemd/system/}}, each modified to log in a different user on a different X11 display and virtual terminal. With Vino, each user's VNC server can be configured to listen on a different port as well:<br />
<br />
$ dbus-launch gsettings set org.gnome.Vino alternative-port 5910<br />
$ dbus-launch gsettings set org.gnome.Vino use-alternative-port true</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Prosody&diff=408376Prosody2015-11-07T08:48:58Z<p>Pelzflorian: Update See also links</p>
<hr />
<div>[[Category:Internet applications]]<br />
[[de:Prosody]]<br />
[[ja:Prosody]]<br />
[http://prosody.im/ Prosody] (pronunciation: [http://www.merriam-webster.com/cgi-bin/audio.pl?prosod05.wav=prosody%27 1], [http://www.merriam-webster.com/cgi-bin/audio.pl?prosod04.wav=prosody%27 2]) is an [http://xmpp.org/ XMPP] server written in the [http://www.lua.org/ Lua] programming language. Prosody is designed to be lightweight and highly extensible. It is licensed under a permissive [http://prosody.im/source/mit MIT license]. Prosody is available for Arch Linux in the Community repository with some optional dependencies available from the [[Arch User Repository]].<br />
<br />
Previous experience with building and installing packages from the AUR and basic knowledge of XMPP will be very helpful when following the guide.<br />
<br />
==Installation==<br />
<br />
[[Install]] the {{Pkg|prosody}} package.<br />
<br />
===Optional dependencies===<br />
Prosody has optional depedencies that although not strictly required for its operation, provide useful features. These dependencies may also have to be built and installed from the AUR. If you are unfamiliar with how to build and install packages from the AUR please see [[AUR User Guidelines#Installing packages]].<br />
<br />
; TLS/SSL Support (Recommended)<br />
: Allow Prosody to encrypt streams to prevent eavesdropping.<br>''Requires:'' {{Pkg|lua51-sec}}<br />
<br />
; MySQL/Postgresql Backend<br />
: Allow Prosody to use a MySQL/mariadb/Postgresql backend for better scaling and performance.<br>''Requires:'' {{AUR|luadbi}}<br />
<br />
; Better Connection Scaling (Recommended)<br />
: Allow Prosody to use [http://www.monkey.org/~provos/libevent/ libevent] to handle a greater number of simultaneous connections.<br>''Requires:'' {{AUR|lua51-event}}<br />
<br />
{{Warning|Due to an open issue, when enabled luaevent, all s2s functionality breaks. A fix is expected in v0.10 [https://prosody.im/issues/issue/555]}}<br />
<br />
; Stream Compression<br />
: Allow Prosody to compress client-to-server streams for compatible clients to save bandwidth.<br>''Requires:'' {{Pkg|lua51-zlib}}<br />
<br />
; Cyrus SASL Support<br />
: Allow Prosody to use the [http://asg.web.cmu.edu/sasl/sasl-library.html Cyrus SASL] library to provide authentication.<br>''Requires:'' {{AUR|lua-cyrussasl}}{{Broken package link|{{aur-mirror|lua-cyrussasl}}}}<br />
<br />
==Configuration==<br />
<br />
{{Note|The {{Ic|posix}} module and {{Ic|pidfile}} setting contained in the default configuration file are required for Prosody's proper operation on Arch Linux. Please do not disable or alter them.}}<br />
<br />
The main configuration file is located at {{ic|/etc/prosody/prosody.cfg.lua}}, information on how to configure Prosody can be found in Prosody's [http://prosody.im/doc/configure documentation]. The syntax of the configuration file can be checked after any changes are made by running: <br />
<br />
{{Ic|$ luac5.1 -p /etc/prosody/prosody.cfg.lua}}<br />
<br />
No output means the syntax is correct.<br />
<br />
===Logging===<br />
The Arch Linux Prosody package is pre-configured to log to syslog. Thus, by default, Prosody log messages are available in the [[systemd journal]].<br />
<br />
==Operation==<br />
<br />
You can start Prosody through the included Systemd script:<br />
<br />
{{Ic|# systemctl start prosody}}<br />
<br />
To automatically start Prosody at boot execute:<br />
<br />
{{Ic|# systemctl enable prosody}}<br />
<br />
Prosody uses the default XMPP ports, 5222 and 5269, for client-to-server and server-to-server communications respectively. Configure your firewall as necessary.<br />
<br />
You can manipulate Prosody users by using the {{Ic|prosodyctl}} program. To add a user:<br />
<br />
{{Ic|# prosodyctl adduser <JID>}}<br />
<br />
{{Tip|You will likely want to make at least one user an administrator by adding their Jabber ID to the {{Ic|admins}} list in the configuration file.}}<br />
<br />
Issue {{Ic|man prosodyctl}} to see the man page for {{Ic|prosodyctl}}.<br />
<br />
===Security===<br />
====User registration====<br />
Prosody supports XMPP's in-band registration [http://xmpp.org/extensions/xep-0077.html standard], which allows users to register with an XMPP client from within their client and change their passwords. While this is convenient for users it does not allow administrators to moderate the registration of new users. As such, the {{Ic|register}} module is enabled in the default configuration but {{Ic|allow_registration}} is set to {{Ic|false}}. This allows existing users to change their passwords from within their client but does not allow new users to register themselves.<br />
<br />
{{Tip|If you do decide to support new in-band registrations, you will likely find the {{Ic|watchregistrations}} and {{Ic|welcome}} modules useful.}}<br />
<br />
====Stream encryption====<br />
Prosody can utilize TLS certificates to encrypt client-to-server communications (if the proper [[#Optional dependencies|dependencies]] are installed). See the relevant sections of {{ic|prosody.cfg.lua}} to configure Prosody to utilize these certificates.<br />
<br />
To require encryption for client-to-server communications add the following to your configuration file:<br />
{{hc|/etc/prosody/prosody.cfg.lua|2=<br />
Host "*"<br />
<br />
c2s_require_encryption = true<br />
}}<br />
<br />
Similarly, for server-to-server communications you may do:<br />
{{hc|/etc/prosody/prosody.cfg.lua|2=<br />
Host "*"<br />
<br />
s2s_require_encryption = true<br />
}}<br />
<br />
While requiring client-to-server encryption is generally a good idea, please keep in mind that some popular XMPP services such as Google Talk/Gmail do not support server-to-server encryption.<br />
<br />
===Listing users===<br />
A simple way to see a list of the registered users is<br />
# ls -l /var/lib/prosody/*/accounts/*<br />
<br />
alternatively, you can download the module [http://prosody.im/files/mod_listusers.lua mod_listusers.lua], and use it as<br />
# prosodyctl mod_listusers<br />
<br />
==Removal==<br />
<br />
After normally uninstalling Prosody with pacman, the {{ic|/etc/prosody}} and {{ic|/var/lib/prosody}} directories may be left on your filesystem, and you may want to remove them if you do not plan on reinstalling Prosody.<br />
<br />
==Tips and tricks==<br />
===Components===<br />
Prosody supports XMPP components, which provide extra services to clients. Components are either provided internally by special Prosody modules or externally using the protocol specified in [http://xmpp.org/extensions/xep-0114.html XEP-0114].<br />
<br />
{{Note|Components must use a different hostname from the {{Ic|VirtualHost}} names defined in {{Ic|prosody.cfg.lua}}. Attempting to host a component on the same hostname as a defined {{Ic|VirtualHost}} '''will''' result in errors.}}<br />
<br />
By default, Prosody will listen for external components. If you do not plan to use any external components with Prosody you can disable this behavior by adding the following your configuration:<br />
<br />
{{hc|/etc/prosody/prosody.cfg.lua|2=<br />
component_ports = {}<br />
}}<br />
<br />
====Multi-User Chat====<br />
A common component used with XMPP servers is Multi-User Chat (MUC), which allows conferences between multiple users. MUC is provided as an internal component with Prosody. To enable MUC add the following to your configuration file:<br />
<br />
{{hc|/etc/prosody/prosody.cfg.lua|<br />
Component "conference.example.com" "muc"<br />
}}<br />
<br />
This will enable the MUC component on host {{Ic|conference.example.com}}.<br />
<br />
===Prosody modules===<br />
[http://code.google.com/p/prosody-modules/ Prosody Modules] is a collection of extra modules not distributed with Prosody. These modules are in various states of development from highly experimental to relatively stable. You should consult a given module's wiki page for more information. An example of an extra module is {{Ic|[http://code.google.com/p/prosody-modules/wiki/mod_pastebin pastebin]}}, which when loaded will intercept long messages (for example, log file output) and replace them with a link to a pastebin hosted using Prosody's internal HTTP server (provided by the core module, {{Ic|httpserver}}).<br />
<br />
To use an extra module download its raw file(s) from the source browser (when viewing a file, search for the link "View raw file"). Alternatively and likely easier, use Mercurial to clone the entire repository:<br />
<br />
{{Ic|$ hg clone <nowiki>https://prosody-modules.googlecode.com/hg/ prosody-modules</nowiki>}}<br />
<br />
Now you can copy the module (and any additional files it needs) to Prosody's module directory at {{ic|/usr/lib/prosody/modules}}. To enable the module add it to your {{Ic|modules_enabled}} list in your {{ic|prosody.cfg.lua}} for the host or component you wish to use it for. For example, to use the {{Ic|pastebin}} module on a MUC component:<br />
<br />
{{hc|/etc/prosody/prosody.cfg.lua|2=<br />
Component "conference.example.com" "muc"<br />
modules_enabled = { "pastebin" }<br />
}}<br />
<br />
{{Note|An enforced Prosody convention is that modules are named {{Ic|mod_''foo''.lua}} but simply enabled by adding {{Ic|''foo''}} to the {{Ic|modules_enabled}} list.}}<br />
<br />
===Console===<br />
{{Warning|The console does not require any authentication so any user on a multi-user system can connect and issue commands on the console. Therefore it is '''not''' recommended to enable the {{Ic|console}} module on a multi-user system.}}<br />
<br />
The {{Ic|console}} module provides a telnet console from which administrative operations and queries can be performed. You can connect to the console by issuing:<br />
<br />
{{Ic|$ telnet localhost 5582}}<br />
<br />
You of course need the {{Ic|telnet}} program provided by the {{Ic|inetutils}} package. Use the {{Ic|help}} command in the console to get usage help.<br />
<br />
The console even allows you to execute Lua commands directly on the server by preceding a command with {{Ic|>}}. For example to see if a client connection is compressed:<br />
<br />
{{Ic|> full_sessions["romeo@montague.lit/Resource"].compressed}}<br />
<br />
Will return {{Ic|true}} if the connection is compressed or {{Ic|nil}} if it is not.<br />
<br />
==Troubleshooting==<br />
One of Prosody's primary design principles is to be simple to use and configure. However, issues can still arise (and likely will as is the case with any complex software). If you encounter a problem there are a variety of steps you can take to narrow down the cause:<br />
<br />
* '''Check for known issues'''<br>Look at the [http://prosody.im/doc/release release notes] for your Prosody version to see if your issue is listed as a known issue. Also check the [http://code.google.com/p/lxmppd/issues/list issue tracker] to see if your issue has already been reported.<br />
* '''Check configuration syntax'''<br>Run {{Ic|luac5.1 -p /etc/prosody/prosody.cfg.lua}} to check for any syntax errors in your configuration file. If there is no output your syntax is fine.<br />
* '''Check the log'''<br>Errors are only logged if there is a critical problem so always address those issues. If you think you have a very low level issue (like protocol compatibility between clients and servers with Prosody) then you can enable the very verbose debug level logging.<br />
* '''Check permissions'''<br>The Prosody package should add a new {{Ic|prosody}} user and group to your system and set appropriate permissions, but it is always good to double check. Ensure that {{ic|/etc/prosody}} and {{ic|/var/lib/prosody}} are owned by the {{Ic|prosody}} user and that the user has appropriate permissions to read and write to those paths and all contained files.<br />
* '''Check listening ports'''<br>When troubleshooting connection issues make sure that Prosody is actually listening for connections. You may do so by running {{Ic|ss -tul}} and making sure that {{Ic|xmpp-client}} (port 5222) and {{Ic|xmpp-server}} (port 5269) are listed.<br />
* '''Restart'''<br>Like most things, it does not hurt to restart Prosody ({{Ic|systemctl restart prosody}}) to see if it resolves an issue.<br />
<br />
If you are unable to resolve your issue yourself there are a variety of resources you can use to seek help. In order of immediacy with which you will likely receive help:<br />
<br />
# XMPP Conference: {{Ic|prosody@conference.prosody.im}}<br />
# Mailing List: [http://groups.google.co.uk/group/prosody-users Web Interface], [mailto:prosody-users@googlegroups.com Email]<br />
# [https://bbs.archlinux.org/viewforum.php?id=4 Arch Forums] (for package issues)<br />
<br />
==Development==<br />
<br />
Two development packages are maintained for Prosody in the AUR, {{AUR|prosody-devel}}{{Broken package link|{{aur-mirror|prosody-devel}}}} and {{AUR|prosody-hg}}{{Broken package link|{{aur-mirror|prosody-hg}}}}. {{Ic|prosody-devel}} tracks the latest source release of a development version (alpha, beta, release candidate) and will actually be behind the stable version if a final version of the development version is released. {{Ic|prosody-hg}} tracks the [http://www.selenic.com/mercurial/wiki/ Mercurial] repository tip for Prosody and will always contain the latest code as it is checked in. Both packages are built similarly to the stable package.<br />
<br />
==Communication==<br />
* Mailing Lists: [http://groups.google.co.uk/group/prosody-dev prosody-dev], [http://groups.google.co.uk/group/prosody-users prosody-users]<br />
* Conference: {{Ic|prosody@conference.prosody.im}}<br />
* Blog: [http://blog.prosody.im/ Prosodical Thoughts]<br />
<br />
== See also ==<br />
<br />
* [https://prosody.im/doc Official documentation]<br />
* [http://blog.prosody.im/ Prosodical Thoughts] (Blog)<br />
* [https://prosody.im/issues/ Issue Tracker]<br />
* [https://hg.prosody.im/prosody-modules/ Prosody Modules] (Extra Modules)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:Pacman/Tips_and_tricks&diff=387022Talk:Pacman/Tips and tricks2015-07-22T10:16:44Z<p>Pelzflorian: /* Remove everything doesn't work with pacman -Qeq */</p>
<hr />
<div>== Listing changed configuration files ==<br />
<br />
Regarding the shell script to manually list the configuration files that have changed, I wrote the following script instead that only uses awk to process the {{ic|/var/lib/pacman/local/*/files}}:<br />
{{hc|changed-files.sh|<nowiki><br />
#!/bin/sh<br />
cat /var/lib/pacman/local/*/files | awk '<br />
/^$/ { backups = 0 }<br />
{<br />
if (backups) {<br />
$1 = "/"$1<br />
if ($2 == "(null)") {<br />
if (! system("test -e "$1)) {<br />
print "d41d8cd98f00b204e9800998ecf8427e "$1<br />
}<br />
} else {<br />
print $2" "$1<br />
}<br />
}<br />
}<br />
/^%BACKUP%$/ { backups = 1 }<br />
' | md5sum -c --quiet<br />
</nowiki>}}<br />
<br />
It supports empty/non-existent files that have {{ic|(null)}} instead of a hash but does not list to which package owns a file. --[[User:Gdiscry|Gdiscry]] ([[User talk:Gdiscry|talk]]) 03:55, 8 October 2013 (UTC)<br />
<br />
:I don't think we need a third one?: [[Pacman tips#Listing changed configuration files]] --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 20:32, 21 July 2015 (UTC)<br />
<br />
== Remove everything doesn't work with pacman -Qeq ==<br />
<br />
Removing everything but the base group didn't work for me until I replaced "pacman -Qeq" with "pacman -Qq" without the e. Was it a bad idea to omit the e? Should this be changed in the command on the page? When I didn't omit the e some packages (akonadi and a few others) printed ":: akonadi: requires mariadb" and similar errors and I couldn't remove the packages. [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 16:45, 14 June 2014 (UTC)<br />
: I think you should keep the 'e' and you should change the installation reason for mariadb. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 17:27, 14 June 2014 (UTC)<br />
:: Hmm. It wasn't just mariadb, there were also similar messages with libgl and a few (not that many) other packages. Using pacman -Qq worked for me; I'm not sure if it did something it wasn't supposed to. But it's not like I wanted to keep mariadb and the others, so I'm not sure what's wrong about -Qq? [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 20:19, 14 June 2014 (UTC)<br />
<br />
:::Can I assume you're referring to [[Pacman tips#Removing everything but base group]]?<br />
:::* {{ic|<nowiki>pacman -Qeq|sort</nowiki>}} (listA) finds all explicitly-installed packages<br />
:::* {{ic|<nowiki>(for i in $(pacman -Qqg base); do pactree -ul $i; done)|sort -u|cut -d ' ' -f 1</nowiki>}} (listB) finds all the installed packages of the base group AND their dependencies<br />
:::* {{ic|<nowiki>comm -23 listA listB</nowiki>}} (listC) finds all installed packages that are explicitly installed AND are not in base group AND are not dependencies of a package in the base group<br />
:::* {{ic|pacman -Rs listC}} tries to remove all these packages AND their non-explicitly-installed dependencies<br />
:::When you ran the command, pacman tried to remove mariadb but akonadi was needing it, and it wasn't on the list, so that was the error.<br />
:::* Neither mariadb nor akonadi could be on your listB<br />
:::* mariadb or a package that was needing it was on your listA<br />
:::* akonadi, instead, wasn't on your listA either, nor there was a package that was needing it<br />
:::This means that akonadi wasn't installed explicitly, but also there wasn't any explicitly-installed package that was needing it => akonadi was a '''top-level''' (orphan) '''dependency'''<br />
:::So yes, the one-liner is buggy, orphan packages can break it. There are some possible ways to fix it, we could add {{ic|pacman -Qdt}} to the lists, we could remove everything with {{ic|pacman -Rsc}} (but this could leave some orphan dependencies installed), or we could indeed remove the {{ic|-e}} option to create listA, and in that case there would be no more point to remove packages with {{ic|-Rs}}, and a simple {{ic|-R}} should do.<br />
:::I'm editing the article with the third solution, which seems the cleanest and simplest. Using {{ic|-Rs}}, though, didn't do any damage, Pelzflorian, it was just unnecessary.<br />
:::This is untested, however, so I'm leaving this discussion open for comments.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:36, 16 June 2014 (UTC)<br />
::::Thank you for the clarification. I don't know pacman all that well, but I do think it is better if that script works with orphans (I'm sure others have orphaned packages as well) and I'm glad the command I used wasn't all wrong (even if the -Rs could have been an -R). [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 09:42, 16 June 2014 (UTC)<br />
:::::Solved? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 20:30, 21 July 2015 (UTC)<br />
::::::Yes :) . The current one-liner also seems to work; the packages to be removed include my orphan packages. [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 10:16, 22 July 2015 (UTC)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:Official_repositories&diff=376631Talk:Official repositories2015-05-31T16:48:01Z<p>Pelzflorian: /* Wikipedia Link */</p>
<hr />
<div>== Wikipedia Link ==<br />
<br />
Hi, I saw this article still used a non-HTTPS link to Wikipedia's article on software repositories and wanted to do something about it. After a quick search I found [[Template_talk:Wikipedia]]. However, the way I edited it apparently was wrong and [[User:Lahwaacz]] reverted it. What is the right way to fix this? [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 10:27, 31 May 2015 (UTC)<br />
<br />
:As mentioned in [[Template talk:Wikipedia#Update Wikipedia inter-wiki link to use the SSL version of Wikipedia]], a bug report should be opened for the ArchWiki backend (see similar reports [https://bugs.archlinux.org/index.php?string={wiki}&project=1 here]). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:25, 31 May 2015 (UTC)<br />
<br />
::I've reported a bug at [https://bugs.archlinux.org/task/45157]. Thank you! Although I probably should have called it {wiki} like the other bugs… [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 16:48, 31 May 2015 (UTC)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:Official_repositories&diff=376489Talk:Official repositories2015-05-31T10:27:50Z<p>Pelzflorian: /* Wikipedia Link */ new section</p>
<hr />
<div>== Wikipedia Link ==<br />
<br />
Hi, I saw this article still used a non-HTTPS link to Wikipedia's article on software repositories and wanted to do something about it. After a quick search I found [[Template_talk:Wikipedia]]. However, the way I edited it apparently was wrong and [[User:Lahwaacz]] reverted it. What is the right way to fix this? [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 10:27, 31 May 2015 (UTC)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Official_repositories&diff=376380Official repositories2015-05-31T08:27:32Z<p>Pelzflorian: replace deprecated Wikipedia template use by plain link</p>
<hr />
<div>[[Category:Package management]]<br />
[[Category:About Arch]]<br />
[[ar:Official Repositories]]<br />
[[cs:Official Repositories]]<br />
[[es:Official Repositories]]<br />
[[fr:Depots]]<br />
[[it:Official Repositories]]<br />
[[ja:公式リポジトリ]]<br />
[[nl:Official Repositories]]<br />
[[pt:Official Repositories]]<br />
[[ro:Depozitele oficiale]]<br />
[[ru:Official repositories]]<br />
[[tr:Resmi_Depolar]]<br />
[[zh-CN:Official repositories]]<br />
[[zh-TW:Official Repositories]]<br />
{{Related articles start}}<br />
{{Related|Mirrors}}<br />
{{Related|Arch User Repository}}<br />
{{Related|Unofficial user repositories}}<br />
{{Related|PKGBUILD}}<br />
{{Related|makepkg}}<br />
{{Related|pacman}}<br />
{{Related|Arch Build System}}<br />
{{Related articles end}}<br />
A [https://en.wikipedia.org/wiki/Software_repository software repository] is a storage location from which software packages are retrieved for installation.<br />
<br />
'''Official repositories''' containing essential and popular software, readily accessible via [[pacman]].<br />
<br />
They are maintained by [[Arch Terminology#Package maintainer|package maintainers]].<br />
<br />
== Repositories ==<br />
<br />
=== core ===<br />
<br />
This repository can be found in {{ic|.../core/os/}} on your favorite [[mirror]].<br />
<br />
core contains packages for:<br />
<br />
* booting Arch Linux<br />
* [[Network configuration|connecting to the Internet]]<br />
* [[Creating packages|building packages]]<br />
* management and repair of supported [[file systems]]<br />
* the system setup process (e.g. {{Pkg|openssh}})<br />
as well as dependencies of the above (not necessarily makedepends)<br />
<br />
''core'' has fairly strict quality requirements. Developers/users need to signoff on updates before package updates are accepted. For packages with low usage, a reasonable exposure is enough: informing people about update, requesting signoffs, keeping in testing up to a week depending on the severity of the change, lack of outstanding bug reports, along with the implicit signoff of the package maintainer.<br />
<br />
{{Note|To create a local repository with packages from ''core'' (or other repositories) without an internet connection see [[Pacman tips#Installing_packages_from_a_CD.2FDVD_or_USB_stick|Installing packages from a CD/DVD or USB stick]].}}<br />
<br />
=== extra ===<br />
<br />
This repository can be found in {{ic|.../extra/os/}} on your favorite mirror.<br />
<br />
''extra'' contains all packages that do not fit in ''core''. Example: Xorg, window managers, web browsers, media players, tools for working with languages such as Python and Ruby, and a lot more.<br />
<br />
=== community ===<br />
<br />
This repository can be found in {{ic|.../community/os/}} on your favorite mirror.<br />
<br />
''community'' contains packages that have been adopted by [[Trusted Users]] from the [[Arch User Repository]]. Some of these packages may eventually make the transition to the [[#core|core]] or [[#extra|extra]] repositories as the developers consider them crucial to the distribution.<br />
<br />
=== multilib ===<br />
<br />
This repository can be found in {{ic|.../multilib/os/}} on your favorite mirror.<br />
<br />
''multilib'' contains 32 bit software and libraries that can be used to run and build 32 bit applications on 64 bit installs (e.g. {{Pkg|wine}}, {{Pkg|skype}}, etc).<br />
<br />
For more information, see [[Multilib]].<br />
<br />
=== testing ===<br />
<br />
{{Warning|Be careful when enabling the ''testing'' repository. Your system may break after performing an update. Only experienced users who know how to deal with potential system breakage should use it.}}<br />
<br />
This repository can be found in {{ic|.../testing/os/}} on your favorite mirror.<br />
<br />
''testing'' contains packages that are candidates for the ''core'' or ''extra'' repositories.<br />
<br />
New packages go into ''testing'' if:<br />
<br />
* They are expected to break something on update and need to be tested first.<br />
<br />
* They require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into ''testing'' first and when all rebuilds are done, they are moved back to the other repositories.<br />
<br />
''testing'' is the only repository that can have name collisions with any of the other official repositories. If enabled, it has to be the first repository listed in your {{ic|/etc/pacman.conf}} file.<br />
<br />
{{Note|''testing'' is not for the "newest of the new" package versions. Part of its purpose is to hold package updates that have the potential to break the system, either by being part of the ''core'' set of packages, or by being critical in other ways. As such, users of ''testing'' are strongly encouraged to subscribe to the [https://mailman.archlinux.org/mailman/listinfo/arch-dev-public arch-dev-public mailing list], watch the [https://bbs.archlinux.org/viewforum.php?id&#61;49 testing repository forum], and to [[Reporting Bug Guidelines|report all bugs]].}}<br />
<br />
If you enable ''testing'', you must also enable ''community-testing''.<br />
<br />
==== community-testing ====<br />
<br />
This repository is like the ''testing'' repository, but for packages that are candidates for the ''community'' repository.<br />
<br />
If you enable it, you must also enable ''testing''.<br />
<br />
==== multilib-testing ====<br />
<br />
This repository is like the ''testing'' repository, but for packages that are candidates for the ''multilib'' repository.<br />
<br />
If you enable it, you must also enable ''testing''.<br />
<br />
==== Disabling testing repositories ====<br />
<br />
If you enabled testing repositories, but later on decided to disable them, you should:<br />
<br />
# Remove (comment out) them from {{ic|/etc/pacman.conf}}<br />
# Perform a {{ic|# pacman -Syyuu}} to "rollback" your updates from these repositories.<br />
<br />
The second item is optional, but keep it in mind if you notice any problems.<br />
<br />
== Historical background ==<br />
<br />
Most of the repository splits are for historical reasons. Originally, when Arch Linux was used by very few users, there was only one repository known as '''official''' (now ''core''). At the time, ''official'' basically contained Judd Vinet's preferred applications. It was designed to contain one of each "type" of program -- one DE, one major browser, etc.<br />
<br />
There were users back then that did not like Judd's selection, so since the [[Arch Build System]] is so easy to use, they created packages of their own. These packages went into a repository called '''unofficial''', and were maintained by developers other than Judd. Eventually, the two repositories were both considered equally supported by the developers, so the names ''official'' and ''unofficial'' no longer reflected their true purpose. They were subsequently renamed to '''current''' and '''extra''' sometime near the release version 0.5.<br />
<br />
Shortly after the 2007.8.1 release, ''current'' was renamed '''core''' in order to prevent confusion over what exactly it contains. The repositories are now more or less equal in the eyes of the developers and the community, but ''core'' does have some differences. The main distinction is that packages used for Installation CDs and release snapshots are taken only from ''core''. This repository still gives a complete Linux system, though it may not be the Linux system you want.<br />
<br />
Some time around 0.5/0.6, there were a lot of packages that the developers did not want to maintain. [https://www.archlinux.org/fellows/#jason Jason Chu] set up the "Trusted User Repositories", which were unofficial repositories in which trusted users could place packages they had created. There was a '''staging''' repository where packages could be promoted into the official repositories by one of the Arch Linux developers, but other than this, the developers and trusted users were more or less distinct.<br />
<br />
This worked for a while, but not when trusted users got bored with their repositories, and not when untrusted users wanted to share their own packages. This led to the development of the [https://aur.archlinux.org/ AUR]. The TUs were conglomerated into a more closely knit group, and they now collectively maintain the '''community''' repository. The Trusted Users are still a separate group from the Arch Linux developers, and there is not a lot of communication between them. However, popular packages are still promoted from ''community'' to ''extra'' on occasion. The [https://aur.archlinux.org/ AUR] also allows untrusted users to submit PKGBUILDs.<br />
<br />
After a kernel in ''core'' [https://www.archlinux.org/news/please-avoid-kernel-261614-1/ broke many user systems], the "core signoff policy" was introduced. Since then, all package updates for ''core'' need to go through a '''testing''' repository first, and only after multiple signoffs from other developers are they allowed to move. Over time, it was noticed that various ''core'' packages had low usage, and user signoffs or even lack of bug reports became informally accepted as criteria to accept such packages.<br />
<br />
In late 2009/the beginning of 2010, with the advent of some new filesystems and the desire to support them during installation, along with the realization that ''core'' was never clearly defined (just "important packages, handpicked by developers"), the repository received a more accurate description.</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Prosody&diff=338518Prosody2014-10-03T13:08:19Z<p>Pelzflorian: changed luac to luac5.1</p>
<hr />
<div>[[Category:Internet applications]]<br />
[[de:Prosody]]<br />
[http://prosody.im/ Prosody] (pronunciation: [http://www.merriam-webster.com/cgi-bin/audio.pl?prosod05.wav=prosody%27 1], [http://www.merriam-webster.com/cgi-bin/audio.pl?prosod04.wav=prosody%27 2]) is an [http://xmpp.org/ XMPP] server written in the [http://www.lua.org/ Lua] programming language. Prosody is designed to be lightweight and highly extensible. It is licensed under a permissive [http://prosody.im/source/mit MIT license]. Prosody is available for Arch Linux in the Community repository with some optional dependencies available from the [[Arch User Repository]].<br />
<br />
Previous experience with building and installing packages from the AUR and basic knowledge of XMPP will be very helpful when following the guide.<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] {{Pkg|prosody}} from the official repositories.<br />
<br />
===Optional dependencies===<br />
Prosody has optional depedencies that although not strictly required for its operation, provide useful features. These dependencies may also have to be built and installed from the AUR. If you are unfamiliar with how to build and install packages from the AUR please see [[AUR User Guidelines#Installing packages]].<br />
<br />
; TLS/SSL Support (Recommended)<br />
: Allow Prosody to encrypt streams to prevent eavesdropping.<br>''Requires:'' {{Pkg|lua51-sec}} (Community)<br />
<br />
; MySQL Backend<br />
: Allow Prosody to use a MySQL backend like mariadb for better scaling and performance.<br>''Requires:'' {{Pkg|lua-sql-mysql}} (Community)<br />
<br />
; Better Connection Scaling (Recommended)<br />
: Allow Prosody to use [http://www.monkey.org/~provos/libevent/ libevent] to handle a greater number of simultaneous connections.<br>''Requires:'' {{AUR|lua51-event}} (AUR)<br />
<br />
; Stream Compression<br />
: Allow Prosody to compress client-to-server streams for compatible clients to save bandwidth.<br>''Requires:'' {{Pkg|lua51-zlib}} (Community)<br />
<br />
; Cyrus SASL Support<br />
: Allow Prosody to use the [http://asg.web.cmu.edu/sasl/sasl-library.html Cyrus SASL] library to provide authentication.<br>''Requires:'' {{AUR|lua-cyrussasl}} (AUR)<br />
<br />
==Configuration==<br />
<br />
{{Note|The {{Ic|posix}} module and {{Ic|pidfile}} setting contained in the default configuration file are required for Prosody's proper operation on Arch Linux. Please do not disable or alter them.}}<br />
<br />
The main configuration file is located at {{ic|/etc/prosody/prosody.cfg.lua}}, information on how to configure Prosody can be found in Prosody's [http://prosody.im/doc/configure documentation]. The syntax of the configuration file can be checked after any changes are made by running: <br />
<br />
{{Ic|$ luac5.1 -p /etc/prosody/prosody.cfg.lua}}<br />
<br />
No output means the syntax is correct.<br />
<br />
===Logging===<br />
The Arch Linux Prosody package is pre-configured to log to syslog. Thus, by default, Prosody log messages are available in the [[Systemd#Journal|systemd journal]].<br />
<br />
==Operation==<br />
<br />
You can start Prosody through the included Systemd script:<br />
<br />
{{Ic|# systemctl start prosody}}<br />
<br />
To automatically start Prosody at boot execute:<br />
<br />
{{Ic|# systemctl enable prosody}}<br />
<br />
Prosody uses the default XMPP ports, 5222 and 5269, for client-to-server and server-to-server communications respectively. Configure your firewall as necessary.<br />
<br />
You can manipulate Prosody users by using the {{Ic|prosodyctl}} program. To add a user:<br />
<br />
{{Ic|# prosodyctl adduser <JID>}}<br />
<br />
{{Tip|You will likely want to make at least one user an administrator by adding their Jabber ID to the {{Ic|admins}} list in the configuration file.}}<br />
<br />
Issue {{Ic|man prosodyctl}} to see the man page for {{Ic|prosodyctl}}.<br />
<br />
===Security===<br />
====User registration====<br />
Prosody supports XMPP's in-band registration [http://xmpp.org/extensions/xep-0077.html standard], which allows users to register with an XMPP client from within their client and change their passwords. While this is convenient for users it does not allow administrators to moderate the registration of new users. As such, the {{Ic|register}} module is enabled in the default configuration but {{Ic|allow_registration}} is set to {{Ic|false}}. This allows existing users to change their passwords from within their client but does not allow new users to register themselves.<br />
<br />
{{Tip|If you do decide to support new in-band registrations, you will likely find the {{Ic|watchregistrations}} and {{Ic|welcome}} modules useful.}}<br />
<br />
====Stream encryption====<br />
Prosody can utilize TLS certificates to encrypt client-to-server communications (if the proper [[#Optional Dependencies|dependencies]] are installed). See the relevant sections of {{ic|prosody.cfg.lua}} to configure Prosody to utilize these certificates.<br />
<br />
To require encryption for client-to-server communications add the following to your configuration file:<br />
{{hc|/etc/prosody/prosody.cfg.lua|2=<br />
Host "*"<br />
<br />
c2s_require_encryption = true<br />
}}<br />
<br />
Similarly, for server-to-server communications you may do:<br />
{{hc|/etc/prosody/prosody.cfg.lua|2=<br />
Host "*"<br />
<br />
s2s_require_encryption = true<br />
}}<br />
<br />
While requiring client-to-server encryption is generally a good idea, please keep in mind that some popular XMPP services such as Google Talk/Gmail do not support server-to-server encryption.<br />
<br />
===Listing users===<br />
A simple way to see a list of the registered users is<br />
# ls -l /var/lib/prosody/*/accounts/*<br />
<br />
alternatively, you can download the module [http://prosody.im/files/mod_listusers.lua mod_listusers.lua], and use it as<br />
# prosodyctl mod_listusers<br />
<br />
==Removal==<br />
<br />
After normally uninstalling Prosody with pacman, the {{ic|/etc/prosody}} and {{ic|/var/lib/prosody}} directories may be left on your filesystem, and you may want to remove them if you do not plan on reinstalling Prosody.<br />
<br />
==Tips and tricks==<br />
===Components===<br />
Prosody supports XMPP components, which provide extra services to clients. Components are either provided internally by special Prosody modules or externally using the protocol specified in [http://xmpp.org/extensions/xep-0114.html XEP-0114].<br />
<br />
{{Note|Components must use a different hostname from the {{Ic|VirtualHost}} names defined in {{Ic|prosody.cfg.lua}}. Attempting to host a component on the same hostname as a defined {{Ic|VirtualHost}} '''will''' result in errors.}}<br />
<br />
By default, Prosody will listen for external components. If you do not plan to use any external components with Prosody you can disable this behavior by adding the following your configuration:<br />
<br />
{{hc|/etc/prosody/prosody.cfg.lua|2=<br />
component_ports = {}<br />
}}<br />
<br />
====Multi-User Chat====<br />
A common component used with XMPP servers is Multi-User Chat (MUC), which allows conferences between multiple users. MUC is provided as an internal component with Prosody. To enable MUC add the following to your configuration file:<br />
<br />
{{hc|/etc/prosody/prosody.cfg.lua|<br />
Component "conference.example.com" "muc"<br />
}}<br />
<br />
This will enable the MUC component on host {{Ic|conference.example.com}}.<br />
<br />
===Prosody modules===<br />
[http://code.google.com/p/prosody-modules/ Prosody Modules] is a collection of extra modules not distributed with Prosody. These modules are in various states of development from highly experimental to relatively stable. You should consult a given module's wiki page for more information. An example of an extra module is {{Ic|[http://code.google.com/p/prosody-modules/wiki/mod_pastebin pastebin]}}, which when loaded will intercept long messages (for example, log file output) and replace them with a link to a pastebin hosted using Prosody's internal HTTP server (provided by the core module, {{Ic|httpserver}}).<br />
<br />
To use an extra module download its raw file(s) from the source browser (when viewing a file, search for the link "View raw file"). Alternatively and likely easier, use Mercurial to clone the entire repository:<br />
<br />
{{Ic|$ hg clone <nowiki>https://prosody-modules.googlecode.com/hg/ prosody-modules</nowiki>}}<br />
<br />
Now you can copy the module (and any additional files it needs) to Prosody's module directory at {{ic|/usr/lib/prosody/modules}}. To enable the module add it to your {{Ic|modules_enabled}} list in your {{ic|prosody.cfg.lua}} for the host or component you wish to use it for. For example, to use the {{Ic|pastebin}} module on a MUC component:<br />
<br />
{{hc|/etc/prosody/prosody.cfg.lua|2=<br />
Component "conference.example.com" "muc"<br />
modules_enabled = { "pastebin" }<br />
}}<br />
<br />
{{Note|An enforced Prosody convention is that modules are named {{Ic|mod_''foo''.lua}} but simply enabled by adding {{Ic|''foo''}} to the {{Ic|modules_enabled}} list.}}<br />
<br />
===Console===<br />
{{Warning|The console does not require any authentication so any user on a multi-user system can connect and issue commands on the console. Therefore it is '''not''' recommended to enable the {{Ic|console}} module on a multi-user system.}}<br />
<br />
The {{Ic|console}} module provides a telnet console from which administrative operations and queries can be performed. You can connect to the console by issuing:<br />
<br />
{{Ic|$ telnet localhost 5582}}<br />
<br />
You of course need the {{Ic|telnet}} program provided by the {{Ic|inetutils}} package. Use the {{Ic|help}} command in the console to get usage help.<br />
<br />
The console even allows you to execute Lua commands directly on the server by preceding a command with {{Ic|>}}. For example to see if a client connection is compressed:<br />
<br />
{{Ic|> full_sessions["romeo@montague.lit/Resource"].compressed}}<br />
<br />
Will return {{Ic|true}} if the connection is compressed or {{Ic|nil}} if it is not.<br />
<br />
==Troubleshooting==<br />
One of Prosody's primary design principles is to be simple to use and configure. However, issues can still arise (and likely will as is the case with any complex software). If you encounter a problem there are a variety of steps you can take to narrow down the cause:<br />
<br />
* '''Check for known issues'''<br>Look at the [http://prosody.im/doc/release release notes] for your Prosody version to see if your issue is listed as a known issue. Also check the [http://code.google.com/p/lxmppd/issues/list issue tracker] to see if your issue has already been reported.<br />
* '''Check configuration syntax'''<br>Run {{Ic|luac5.1 -p /etc/prosody/prosody.cfg.lua}} to check for any syntax errors in your configuration file. If there is no output your syntax is fine.<br />
* '''Check the log'''<br>Errors are only logged if there is a critical problem so always address those issues. If you think you have a very low level issue (like protocol compatibility between clients and servers with Prosody) then you can enable the very verbose debug level logging.<br />
* '''Check permissions'''<br>The Prosody package should add a new {{Ic|prosody}} user and group to your system and set appropriate permissions, but it is always good to double check. Ensure that {{ic|/etc/prosody}} and {{ic|/var/lib/prosody}} are owned by the {{Ic|prosody}} user and that the user has appropriate permissions to read and write to those paths and all contained files.<br />
* '''Check listening ports'''<br>When troubleshooting connection issues make sure that Prosody is actually listening for connections. You may do so by running {{Ic|ss -tul}} and making sure that {{Ic|xmpp-client}} (port 5222) and {{Ic|xmpp-server}} (port 5269) are listed.<br />
* '''Restart'''<br>Like most things, it does not hurt to restart Prosody ({{Ic|systemctl restart prosody}}) to see if it resolves an issue.<br />
<br />
If you are unable to resolve your issue yourself there are a variety of resources you can use to seek help. In order of immediacy with which you will likely receive help:<br />
<br />
# XMPP Conference: {{Ic|prosody@conference.prosody.im}}<br />
# Mailing List: [http://groups.google.co.uk/group/prosody-users Web Interface], [mailto:prosody-users@googlegroups.com Email]<br />
# [https://bbs.archlinux.org/viewforum.php?id=4 Arch Forums] (for package issues)<br />
<br />
==Development==<br />
<br />
Two development packages are maintained for Prosody in the AUR, {{AUR|prosody-devel}} and {{AUR|prosody-hg}}. {{Ic|prosody-devel}} tracks the latest source release of a development version (alpha, beta, release candidate) and will actually be behind the stable version if a final version of the development version is released. {{Ic|prosody-hg}} tracks the [http://www.selenic.com/mercurial/wiki/ Mercurial] repository tip for Prosody and will always contain the latest code as it is checked in. Both packages are built similarly to the stable package.<br />
<br />
==Communication==<br />
* Mailing Lists: [http://groups.google.co.uk/group/prosody-dev prosody-dev], [http://groups.google.co.uk/group/prosody-users prosody-users]<br />
* Conference: {{Ic|prosody@conference.prosody.im}}<br />
* Blog: [http://blog.prosody.im/ Prosodical Thoughts]<br />
<br />
== See also ==<br />
<br />
* [http://prosody.im/doc Official documentation]<br />
* [http://blog.prosody.im/ Prosodical Thoughts] (Blog)<br />
* [http://code.google.com/p/lxmppd/issues/list Issue Tracker]<br />
* [http://prosody.im/source/browse/ Prosody Modules] (Extra Modules)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:Pacman/Tips_and_tricks&diff=320318Talk:Pacman/Tips and tricks2014-06-16T09:42:21Z<p>Pelzflorian: </p>
<hr />
<div>== Listing changed configuration files ==<br />
<br />
Regarding the shell script to manually list the configuration files that have changed, I wrote the following script instead that only uses awk to process the {{ic|/var/lib/pacman/local/*/files}}:<br />
{{hc|changed-files.sh|<nowiki><br />
#!/bin/sh<br />
cat /var/lib/pacman/local/*/files | awk '<br />
/^$/ { backups = 0 }<br />
{<br />
if (backups) {<br />
$1 = "/"$1<br />
if ($2 == "(null)") {<br />
if (! system("test -e "$1)) {<br />
print "d41d8cd98f00b204e9800998ecf8427e "$1<br />
}<br />
} else {<br />
print $2" "$1<br />
}<br />
}<br />
}<br />
/^%BACKUP%$/ { backups = 1 }<br />
' | md5sum -c --quiet<br />
</nowiki>}}<br />
<br />
It supports empty/non-existent files that have {{ic|(null)}} instead of a hash but does not list to which package owns a file. --[[User:Gdiscry|Gdiscry]] ([[User talk:Gdiscry|talk]]) 03:55, 8 October 2013 (UTC)<br />
<br />
== Remove everything doesn't work with pacman -Qeq ==<br />
<br />
Removing everything but the base group didn't work for me until I replaced "pacman -Qeq" with "pacman -Qq" without the e. Was it a bad idea to omit the e? Should this be changed in the command on the page? When I didn't omit the e some packages (akonadi and a few others) printed ":: akonadi: requires mariadb" and similar errors and I couldn't remove the packages. [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 16:45, 14 June 2014 (UTC)<br />
: I think you should keep the 'e' and you should change the installation reason for mariadb. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 17:27, 14 June 2014 (UTC)<br />
:: Hmm. It wasn't just mariadb, there were also similar messages with libgl and a few (not that many) other packages. Using pacman -Qq worked for me; I'm not sure if it did something it wasn't supposed to. But it's not like I wanted to keep mariadb and the others, so I'm not sure what's wrong about -Qq? [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 20:19, 14 June 2014 (UTC)<br />
<br />
:::Can I assume you're referring to [[Pacman tips#Removing everything but base group]]?<br />
:::* {{ic|<nowiki>pacman -Qeq|sort</nowiki>}} (listA) finds all explicitly-installed packages<br />
:::* {{ic|<nowiki>(for i in $(pacman -Qqg base); do pactree -ul $i; done)|sort -u|cut -d ' ' -f 1</nowiki>}} (listB) finds all the installed packages of the base group AND their dependencies<br />
:::* {{ic|<nowiki>comm -23 listA listB</nowiki>}} (listC) finds all installed packages that are explicitly installed AND are not in base group AND are not dependencies of a package in the base group<br />
:::* {{ic|pacman -Rs listC}} tries to remove all these packages AND their non-explicitly-installed dependencies<br />
:::When you ran the command, pacman tried to remove mariadb but akonadi was needing it, and it wasn't on the list, so that was the error.<br />
:::* Neither mariadb nor akonadi could be on your listB<br />
:::* mariadb or a package that was needing it was on your listA<br />
:::* akonadi, instead, wasn't on your listA either, nor there was a package that was needing it<br />
:::This means that akonadi wasn't installed explicitly, but also there wasn't any explicitly-installed package that was needing it => akonadi was a '''top-level''' (orphan) '''dependency'''<br />
:::So yes, the one-liner is buggy, orphan packages can break it. There are some possible ways to fix it, we could add {{ic|pacman -Qdt}} to the lists, we could remove everything with {{ic|pacman -Rsc}} (but this could leave some orphan dependencies installed), or we could indeed remove the {{ic|-e}} option to create listA, and in that case there would be no more point to remove packages with {{ic|-Rs}}, and a simple {{ic|-R}} should do.<br />
:::I'm editing the article with the third solution, which seems the cleanest and simplest. Using {{ic|-Rs}}, though, didn't do any damage, Pelzflorian, it was just unnecessary.<br />
:::This is untested, however, so I'm leaving this discussion open for comments.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:36, 16 June 2014 (UTC)<br />
::::Thank you for the clarification. I don't know pacman all that well, but I do think it is better if that script works with orphans (I'm sure others have orphaned packages as well) and I'm glad the command I used wasn't all wrong (even if the -Rs could have been an -R). [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 09:42, 16 June 2014 (UTC)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:Pacman/Tips_and_tricks&diff=320008Talk:Pacman/Tips and tricks2014-06-14T20:19:23Z<p>Pelzflorian: /* Remove everything doesn't work with pacman -Qeq */</p>
<hr />
<div>== Listing changed configuration files ==<br />
<br />
Regarding the shell script to manually list the configuration files that have changed, I wrote the following script instead that only uses awk to process the {{ic|/var/lib/pacman/local/*/files}}:<br />
{{hc|changed-files.sh|<nowiki><br />
#!/bin/sh<br />
cat /var/lib/pacman/local/*/files | awk '<br />
/^$/ { backups = 0 }<br />
{<br />
if (backups) {<br />
$1 = "/"$1<br />
if ($2 == "(null)") {<br />
if (! system("test -e "$1)) {<br />
print "d41d8cd98f00b204e9800998ecf8427e "$1<br />
}<br />
} else {<br />
print $2" "$1<br />
}<br />
}<br />
}<br />
/^%BACKUP%$/ { backups = 1 }<br />
' | md5sum -c --quiet<br />
</nowiki>}}<br />
<br />
It supports empty/non-existent files that have {{ic|(null)}} instead of a hash but does not list to which package owns a file. --[[User:Gdiscry|Gdiscry]] ([[User talk:Gdiscry|talk]]) 03:55, 8 October 2013 (UTC)<br />
<br />
== Remove everything doesn't work with pacman -Qeq ==<br />
<br />
Removing everything but the base group didn't work for me until I replaced "pacman -Qeq" with "pacman -Qq" without the e. Was it a bad idea to omit the e? Should this be changed in the command on the page? When I didn't omit the e some packages (akonadi and a few others) printed ":: akonadi: requires mariadb" and similar errors and I couldn't remove the packages. [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 16:45, 14 June 2014 (UTC)<br />
: I think you should keep the 'e' and you should change the installation reason for mariadb. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 17:27, 14 June 2014 (UTC)<br />
:: Hmm. It wasn't just mariadb, there were also similar messages with libgl and a few (not that many) other packages. Using pacman -Qq worked for me; I'm not sure if it did something it wasn't supposed to. But it's not like I wanted to keep mariadb and the others, so I'm not sure what's wrong about -Qq? [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 20:19, 14 June 2014 (UTC)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:Pacman/Tips_and_tricks&diff=319929Talk:Pacman/Tips and tricks2014-06-14T16:45:57Z<p>Pelzflorian: /* Remove everything doesn't work with pacman -Qeq */ new section</p>
<hr />
<div>== Listing changed configuration files ==<br />
<br />
Regarding the shell script to manually list the configuration files that have changed, I wrote the following script instead that only uses awk to process the {{ic|/var/lib/pacman/local/*/files}}:<br />
{{hc|changed-files.sh|<nowiki><br />
#!/bin/sh<br />
cat /var/lib/pacman/local/*/files | awk '<br />
/^$/ { backups = 0 }<br />
{<br />
if (backups) {<br />
$1 = "/"$1<br />
if ($2 == "(null)") {<br />
if (! system("test -e "$1)) {<br />
print "d41d8cd98f00b204e9800998ecf8427e "$1<br />
}<br />
} else {<br />
print $2" "$1<br />
}<br />
}<br />
}<br />
/^%BACKUP%$/ { backups = 1 }<br />
' | md5sum -c --quiet<br />
</nowiki>}}<br />
<br />
It supports empty/non-existent files that have {{ic|(null)}} instead of a hash but does not list to which package owns a file. --[[User:Gdiscry|Gdiscry]] ([[User talk:Gdiscry|talk]]) 03:55, 8 October 2013 (UTC)<br />
<br />
== Remove everything doesn't work with pacman -Qeq ==<br />
<br />
Removing everything but the base group didn't work for me until I replaced "pacman -Qeq" with "pacman -Qq" without the e. Was it a bad idea to omit the e? Should this be changed in the command on the page? When I didn't omit the e some packages (akonadi and a few others) printed ":: akonadi: requires mariadb" and similar errors and I couldn't remove the packages. [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 16:45, 14 June 2014 (UTC)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:GNOME&diff=304474Talk:GNOME2014-03-14T16:31:09Z<p>Pelzflorian: /* Reference to NetworkManager */ new section</p>
<hr />
<div>== Installation ==<br />
Being that {{ic| pacman -S gnome}} produces a numbered list, wouldn't be prudent to specify packages that are ''critical'' for a workable desktop? [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 21:00, 28 January 2013 (UTC)<br />
<br />
== Candidates for removal (discussion) ==<br />
<br />
* [[GNOME#Some_.27System_Settings.27_not_preserved]] - Poor language and doubles what's explained (more thoroughly) in [[Systemd]]. Should be rewritten and reference to [[Systemd]]<br />
<br />
* [[GNOME#Extensions_do_not_work_after_GNOME_3_update]] - Advises people to skip version checks when extensions no longer load due to version incompatibility. I'm not sure this is something we should be telling users to do.<br />
<br />
* [[GNOME#Login_screen]] - GDM is not part of clean GNOME, should we add this to [[GDM]] in stead?<br />
:: +1. I think this part is created before [[GDM]] exist. Merge request added. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 09:33, 14 September 2012 (UTC) <br />
<br />
:: I would also like to gather and give a private section to extensions. Currently that information is spread around the article, I think it deserves its own section within this article.<br />
<br />
:: +1 Added clarity to merge tag. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 21:18, 28 January 2013 (UTC)<br />
<br />
::: *very good* info about exporting DBUS vars and editing GDM's dconf was killed in haste (12:19, 8 August 2013 Lahwaacz) [[User:Extofme|Extofme]] ([[User talk:Extofme|talk]]) 12:39, 22 October 2013 (UTC)<br />
<br />
::::You can still restore that, maybe in [[GDM#Configuration]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:00, 24 October 2013 (UTC)<br />
<br />
:: We should move to working part of this section to GDM. Their is a own page for GDM and this blows up the page for GNOME, necessary information is missing here (seems to be partially included on GDM-Page - this is the reason why I don't move it) and the lock-screen can now be configured through regular settings-UI in GNOME. [[User:Hoschi|Hoschi]] ([[User talk:Hoschi|talk]]) 16:43, 2 November 2013 (UTC)<br />
<br />
*[[GNOME#Shutdown_via_the_status_menu]] - As of Gnome (3.6.2), this is no longer the case. Gnome has switched back to using Power Off in the menu.<br />
<br />
: I see that the "Troubleshooting" section is bloated and requires cleanup. I support removal of material so as long that: It is proven to be irrelevant from this point forward, or condensed into notes/tips that are assimilated into the main article with external links for reference if need be. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 21:18, 28 January 2013 (UTC)<br />
<br />
*[[GNOME#Disable_Activity_hot_corner_hovering]] - As of GNOME Shell 3.8.3, this method doesn't work, as the mechanism of triggering "overview" display is updated and the old way is refered as "Fallback". A working hack may be to comment off <br />
{{hc|/usr/share/gnome-shell/js/ui/layout.js|<nowiki><br />
//this._pressureBarrier.connect('trigger', Lang.bind(this, this._toggleOverview));<br />
</nowiki>}}<br />
<br />
*[[GNOME#Disable_Message_Tray_hovering]] - As of GNOME Shell 3.8.3, this method doesn't work for similar reason. A working hack may be to comment off <br />
{{hc|/usr/share/gnome-shell/js/ui/layout.js|<nowiki><br />
//Main.messageTray.openTray();<br />
</nowiki>}} [[User:Lns|Lns]] ([[User talk:Lns|talk]]) 06:09, 4 August 2013 (UTC)<br />
<br />
== GNOME and fontconfig settings ==<br />
<br />
Since there isn't a section dedicated to fonts in GNOME 3 I was thinking about writing one, but I put it here first:<br />
<br />
GNOME doesn't use the dpi settings set by xorg server to scale fonts, instead it uses a fixed dpi of 96 that cannot be changed unlike previous versions:<br />
<br />
/* As we cannot rely on the X server giving us good DPI information, and<br />
* that we don't want multi-monitor screens to have different DPIs (thus<br />
* different text sizes), we'll hard-code the value of the DPI<br />
*<br />
* See also:<br />
* https://bugzilla.novell.com/show_bug.cgi?id=217790•<br />
* https://bugzilla.gnome.org/show_bug.cgi?id=643704<br />
*/<br />
<br />
The gnome-settings-daemon plugin xsettings relies on this hardcoded value for some calculations and there is currently no way of changing it beside customizing the code in abs. The dimension of text can be tweaked changing the text-scaling-factor (1.0 by default), using gnome-tweak-tool or editing the following key in dconf-editor:<br />
<br />
org.gnome.desktop.interface.text-scaling-factor<br />
<br />
The xsettings plugins will also merge some Xft values in the X resources db overwriting values set in .Xresources od .Xdefaults files. The defaults are:<br />
<br />
Xft.antialias: 1<br />
Xft.dpi: 96<br />
Xft.hinting: 1<br />
Xft.hintstyle: hintmedium<br />
Xft.lcdfilter: lcddefault<br />
Xft.rgba: none<br />
<br />
Some of those values can be changed using dconf-editor (org.gnome.settings-daemon.plugins.xsettings) or gnome-tweak-tool. It is possible to change this values using xrdb -merge ~/.Xresources after gnome is started but gnome will still use its values internally so it is not a good idea.<br />
<br />
It is a good idea to configure your fonts.conf in a way consistent with the gnome settings otherwise, at least on my laptop, fonts will looks weird in some gnome apps. <br />
<br />
The dpi setting of the Xserver can be changed to 96 following [https://wiki.archlinux.org/index.php/Xorg#Display_Size_and_DPI this] guide, this way it will be the same for all applications, the drawback is that fonts might look too small or too big in other application if the real DPI of your monitor differs too much from 96.<br />
<br />
For and LCD monitor it is a good idea to activate the lcd filter setting the following keys in dconf-editor:<br />
<br />
org.gnome.settings-daemon.plugins.xsettings.antialiasing rgba<br />
org.gnome.settings-daemon.plugins.xsettings.rgba-order rgb, bgr, vrgb or vbgr (as your monitor requires)<br />
<br />
Since the lcdfilter is not designed to work together with autohinting it is a good idea to disable it also in fonts.conf.<br />
It is also a good idea to use the same hinting value as in your font.conf, the default in gnome is medium:<br />
<br />
org.gnome.settings-daemon.plugins.xsettings.hinting medium<br />
<br />
This values in fonts.conf will match the gnome settings:<br />
<br />
<match target="font"><br />
<edit mode="assign" name="rgba"><const>rgb</const></edit><br />
<edit mode="assign" name="autohint"><bool>false</bool></edit><br />
<edit mode="assign" name="hinting"><bool>true</bool></edit><br />
<edit mode="assign" name="hintstyle"><const>hintmedium</const></edit><br />
<edit mode="assign" name="antialias"><bool>true</bool></edit><br />
<edit mode="assign" name="lcdfilter"><const>lcddefault</const></edit><br />
</match><br />
<br />
<br />
(to be finished, please comment or fix)<br />
<br />
== deleted manual hotkeys modification ==<br />
<br />
Manual edit of accel.scm into nautilus config doesn't fit with this page. And this can't be a generic method, cause not every application has an accels.scm file, even if it has that, it's location in ~/.config is not mandatory.<br />
[[User:4javier|4javier]] 08:09, 25 April 2011 (EDT)<br />
<br />
:It fits with this page just as much as the remaining part on changing hotkeys does because both serve the same purpose. So I disagree with that it should be downright deleted, particularly as for me (thus possibly others) the ''can-change-accels'' way did not work. I added it again (a bit more carefully phrased) to the "Troubleshooting" section. -- [[User:Misc|Misc]] 15:40, 25 April 2011 (EDT)<br />
<br />
::I still think that applications' specific method of changing accels should be mentioned in the application page itself. Into this page I'd leave just a reminder (i.e. "If this method doesn't work see application's wiki page for app specific file"). But I don't delete it anymore until somebody else tell us his opinion. [[User:4javier|4javier]] 20:35, 25 April 2011 (EDT)<br />
<br />
:::Perhaps update [[Nautilus]] and reference it? Perhaps simply add that article to the related articles? --[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 23:33, 6 September 2012 (UTC)<br />
<br />
== Xmonad section ==<br />
<br />
I think xmonad section should be generalized for every other wm: openbox, fluxbox, ratpoison etc. Is there some gnome3 user who can test the method with other wm than xmonad? --[[User:4javier|4javier]] 05:40, 16 May 2011 (EDT)<br />
<br />
== Add link to official extensions site ==<br />
<br />
I think to add a link to [https://extensions.gnome.org/ extensions.gnome.org], also in order to easy manage the extensions in the browser from the [https://extensions.gnome.org/local/ /local] page. --[[User:Gimmy|Gimmy]] 05:22, 23 January 2012 (EST)<br />
:Link added, this probably deserves a section of its own now that extensions play such a vital role in GNOME. A future rewrite / restructure of this article may be needed. --[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 23:52, 6 September 2012 (UTC)<br />
<br />
== Remove systemd configuration from 'Some 'System Settings' no preserved' section ==<br />
<br />
I think that part of the 'Some 'System Settings' no preserved' section regarding switching to systemd should be removed and replaced with a link to systemd wiki. Systemd wiki explains migration more thoroughly and shows how to configure and administrate it.<br />
:: This entire section can be removed IMO, SystemD has been the default for long enough. Objections? --[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 20:55, 14 October 2013 (UTC)<br />
::: +1. --[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 13:16, 19 October 2013 (UTC)<br />
<br />
== Reference to NetworkManager ==<br />
<br />
GNOME 3 uses network-manager-applet, which in turn uses NetworkManager. Maybe this page should contain a reference to NetworkManager, so people with network problems in GNOME know where to look for the solution. I suppose many people do not know that using GNOME means using NetworkManager. [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 16:31, 14 March 2014 (UTC)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=304473Talk:NetworkManager2014-03-14T16:26:41Z<p>Pelzflorian: /* Mention that dhcpcd is a conflicting networking service? */ new section</p>
<hr />
<div>== GNOME 3 and nm-applet ==<br />
<br />
Looks like GNOME 3 doesn't need nm-applet any more. Moreover, it competes with the shell's network agent for new connections. Does anyone copy this? Should this be mentioned on the page?<br />
<br />
== <s>DHCP service is enabled by default</s> ==<br />
<br />
https://wiki.archlinux.org/index.php/Installation_Guide#Connect_to_the_internet<br />
<br />
Wiki quote: "Connect to the internet A DHCP service is already enabled for all available devices."<br />
<br />
'''DHCP IS ENABLED BY DEFAULT according to this, is it not true?'''<br />
<br />
Why do you Scimmia and Lahwaacz insist on NOT allowing some detailed clarity on this issue? I was given the excuse, oh we can't have systemctl commands here, they belong in systemctl section of wiki. WTF I call bullshit on this ... look at all the other wiki subjects that contain the required systemctl commands! <br />
<br />
I see more than one attempt to clarify "fix" this issue have been deleted by you, and your insistence that the "note" completely covers it. Now you've made it worse by removing the note from configure section and placing it in the install area!<br />
<br />
This needs to be in the beginning of the configure section: <br />
<br />
'''You must stop and disable the following service before NM will work : <br />
<br />
# systemctl stop dhcpcd.service<br />
# systemctl disable dhcpcd.service'''<br />
<br />
Then the note:<br />
<br />
'''Note: It may be a good idea to use systemctl --type=service to ensure that no other service is running that may want to configure the network. Multiple networking services will conflict.<br />
'''<br />
<br />
Then why not explain what to look for with this command specifically? Why not mention stop and disable it with the above commands?<br />
<br />
How could this so hard for such intelligent people to understand? Do you have some other motivation to not include it?<br />
<br />
:Hi, first of all I'd like to ask you to please write in a more relaxed tone, nobody here edits the articles just to annoy people. Also, please sign your edits in talk pages as explained in [[Help:Discussion]].<br />
:Now, on to the topic, we have several style rules on this wiki, and in particular [[Help:Style#Daemon operations]] recommends to link to [[systemd]] instead of always explaining how to start/enable/stop services, so that's why those instructions have been correctly removed. I'm perfectly aware that there are still many articles giving examples of simple systemctl commands, and it's those that would need to conform to the style guide, not this article to them.<br />
:I've updated the note and made it clearer also for people coming from the installation guides, please have a look. I think such note is more visible in the Installation section rather than in Configuration.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:36, 2 January 2014 (UTC)<br />
<br />
::The problem now is that the note is wrong. Only those people that specifically enabled it need to disable it, and it's never even mentioned in the Installation Guide<br />
::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 10:24, 2 January 2014 (UTC)<br />
<br />
:::Uh I assumed he was trying to use networkmanager in the live system for particular reasons. You're right, the last part of the note I've written is indeed confusing, I've just removed it. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:51, 2 January 2014 (UTC)<br />
<br />
:The dhcpcd service is not enabled by default on the installed system. The link you gave says that it's enabled by default on the live install system, nothing more. If it's enabled on the installed system, YOU did it. Stop blaming others for your own shortcomings.<br />
:[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 10:16, 2 January 2014 (UTC)<br />
<br />
::I migrated from Slax to Arch ''years'' ago and mindlessly enabled the dhcpcd daemon because, well, I needed to. I installed NM recently and after all this time, I entirely forgot dhcpcd wasn't initially enabled by default. In fact in my ignorance, it's the last thing I would've thought to disable. I thought that NM would somehow negotiate a DHCP lease through the service itself. Of course dhcpcd hogs the interfaces and so on, which I know '''now'''. While I acknowledge only some people need to disable dhcpcd, I do '''not''' think it is up to them to remember, potentially years later, that they enabled such an apparantly-standard service themselves. Cheers [[User:Phillid|Phillid]] ([[User talk:Phillid|talk]]) 21:31, 30 January 2014 (UTC)<br />
<br />
:::I disagree, it is up to you to know what is running on your system, nobody else can tell you that. There is already a note that says you need to disable all other services that try to configure the network, and that note even gives you a way to check what is running in case you forgot like you mentioned. Do you want to list each and every example of services that need to be disabled? All of the versions of netctl, all of the versions of netcfg, connman, wicd, dhclient, etc. If you're going to list one, you should list them all.<br />
:::And ''years'' ago? We're talking about systemd services, just how many years have you been running systemd on the system in question?<br />
:::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 05:40, 31 January 2014 (UTC)<br />
::::That's actually a fair point - systemd's only been default for two or three years now, right? This goes to prove how bad some Arch users' memories are! :-) It '''is''' up to me, but I believe that a few reminders would've educated me ''before'' I went on a massive web search bender. Like I said, I knew dhcpcd.service was running. What I didn't know is that it hogs the interfaces. In my ignorant eyes, it was a service more core to the system, and I'd have thought NetworkManager would plug into dhcpcd.service for all its dhcp needs. Little did I know, I was wrong.<br />
::::What great harm does it cause to have a twenty word reminer about the most common services; dhcpcd, netcfg and netctl or whatever. Do you honestly and truly believe that it detracts more value than it gives to the article?<br />
::::[[User:Phillid|Phillid]] ([[User talk:Phillid|talk]]) 10:30, 31 January 2014 (UTC)<br />
<br />
:::::systemd has been the default for 15 months, it's only been in the repos for 2 years.<br />
:::::Like I said, if you want to add one thing, you should add them all and god help you if you miss one because some clueless user will start crying that theirs wasn't listed and it took them HOURS with google to figure it out. In short, yes, I believe it is better to give the tools to figure it out rather than listing exactly what needs to be done command by command.<br />
:::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 17:08, 31 January 2014 (UTC)<br />
<br />
:I should probably point out that the note originates from the [[netctl]] article, I've copied it from there. The true origin is in [https://bbs.archlinux.org/viewtopic.php?pid=1281413#p1281413 this forum thread], it is quite similar to this discussion...<br />
:It is a fact that '''all''' Arch users should be able to deal with problems using some web search engine and that '''they''' are responsible for what software they install and which services they enable. There are obviously many different combinations of what can go wrong and it is simply not possible to be this verbose. ArchWiki has provided you a hint, it is up to you if you ignore it or think and check if it is applicable to you.<br />
:That said, I'm closing this discussion. Please keep the note brief.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:49, 31 January 2014 (UTC)<br />
<br />
== Mention that dhcpcd is a conflicting networking service? ==<br />
<br />
This is related to the discussion below. The note at the beginning says that conflicting network configuration services should be disabled. I did not know the dhcpcd@.services are such services. It would have saved me a lot of time and frustration if this had been mentioned. [[User:Pelzflorian|Pelzflorian]] ([[User talk:Pelzflorian|talk]]) 16:26, 14 March 2014 (UTC)</div>Pelzflorianhttps://wiki.archlinux.org/index.php?title=FluidSynth&diff=303936FluidSynth2014-03-10T19:10:37Z<p>Pelzflorian: /* Standalone mode */</p>
<hr />
<div>[[Category:Audio/Video]]<br />
[http://www.fluidsynth.org/ FluidSynth] is a real-time software synthesizer based on the SoundFont 2 specifications.<br />
<br />
== Installing FluidSynth ==<br />
<br />
The first step is to [[pacman|install]] {{Pkg|fluidsynth}} from the [[official repositories]].<br />
<br />
'''However, FluidSynth will not produce any sound yet'''. This is because FluidSynth does not include any instrument samples. To produce sound, instrument patches and/or soundfonts need to be installed and fluidsynth configured so it knows where to find them. You can install [[Timidity#SoundFonts|SoundFont sample]].<br />
<br />
== How to use FluidSynth ==<br />
<br />
There are two ways to use FluidSynth. Either as MIDI player or as daemon adding MIDI support to ALSA.<br />
<br />
=== Standalone mode ===<br />
<br />
You can simply use fluidsynth to play MIDI files:<br />
$ fluidsynth -a alsa -m alsa_seq -l -i /usr/share/soundfonts/fluidr3/FluidR3GM.SF2 example.midi<br />
Assuming than you installed fluidr3.<br />
<br />
There are many other options to fluidsynth; see manpage or use -h to get help.<br />
<br />
One may wish to use pulseaudio instead of alsa as the argument to the -a option.<br />
<br />
=== ALSA daemon mode ===<br />
<br />
If you want fluidsynth to run as ALSA daemon, edit {{ic|/usr/lib/systemd/system/fluidsynth.service}} and append the {{ic|ExecStart}} Line with the soundfont you want to use, for fluidr3:<br />
ExecStart=/usr/bin/fluidsynth -is -a alsa -m alsa_seq -r 48000 "/usr/share/soundfonts/fluidr3/FluidR3GM.SF2"<br />
<br />
After that, you can start fluidsynth service and possibly enable it.<br />
<br />
This will give you an output software MIDI port (in addition of hardware MIDI ports on your system, if any):<br />
<br />
{{hc|$ aconnect -o|2=<br />
client 128: 'FLUID Synth (5117)' [type=user]<br />
0 'Synth input port (5117:0)'<br />
}}<br />
<br />
An example of usage for this is aplaymidi:<br />
<br />
$ aplaymidi -p128:0 example.midi<br />
<br />
== How to convert MIDI to OGG ==<br />
<br />
Simple command lines to convert midi to ogg:<br />
<br />
$ fluidsynth -nli -r 48000 -o synth.cpu-cores=2 -T oga -F example.ogg /usr/share/soundfonts/fluidr3/FluidR3GM.SF2 example.MID<br />
<br />
Here's a little script to convert multiple midi files to ogg in parallel:<br />
<br />
#!/bin/bash<br />
maxjobs=$(grep processor /proc/cpuinfo | wc -l)<br />
midi2ogg() {<br />
name=$(echo $@ | sed -r s/[.][mM][iI][dD][iI]?$//g | sed s/^[.][/]//g)<br />
for arg; do <br />
fluidsynth -nli -r 48000 -o synth.cpu-cores=$maxjobs -F "/dev/shm/$name.raw" /usr/share/soundfonts/fluidr3/FluidR3GM.SF2 "$@"<br />
oggenc -r -B 16 -C 2 -R 48000 "/dev/shm/$name.raw" -o "$name.ogg"<br />
rm "/dev/shm/$name.raw"<br />
## Uncomment for replaygain tagging<br />
#vorbisgain -f "$name.ogg" <br />
done<br />
}<br />
export -f midi2ogg<br />
find . -regex '.*[.][mM][iI][dD][iI]?$' -print0 | xargs -0 -n 1 -P $maxjobs bash -c 'midi2ogg "$@"' --</div>Pelzflorian