https://wiki.alpinelinux.org/w/api.php?action=feedcontributions&user=Ktprograms&feedformat=atomAlpine Linux - User contributions [en]2024-03-29T05:09:07ZUser contributionsMediaWiki 1.40.0https://wiki.alpinelinux.org/w/index.php?title=Release_Notes_for_Alpine_3.16.0&diff=21810Release Notes for Alpine 3.16.02022-05-04T13:18:52Z<p>Ktprograms: </p>
<hr />
<div>== Important changes ==<br />
<br />
=== /tmp mounted as tmpfs ===<br />
<br />
Previously <code>/tmp</code> was just part of the root filesystem and was cleaned on boot via the bootmisc openrc service script. In v3.16, on new installation, <code>/tmp</code> will be mounted as tmpfs. <br />
<br />
== New features and noteworthy new packages ==<br />
<br />
=== KDE ===<br />
<br />
Plasma has been upgraded from 5.23 to 5.24.<br />
<br />
KDE applications (the release service) have been upgraded from 21.08 to 22.04 and KDE Frameworks have been upgraded from 5.88 to 5.93.<br />
<br />
Plasma Mobile Gear have been upgraded from 21.12 to 22.04.<br />
<br />
=== Fixed not showing boot output using consoles with drivers compiled as modules ===<br />
<br />
Fixed OpenRC output not being shown on VirtIO consoles.</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=Nextcloud&diff=21379Nextcloud2022-01-06T01:10:18Z<p>Ktprograms: Use php8, fix minor problems</p>
<hr />
<div>[https://nextcloud.com/ Nextcloud] is WedDAV-based solution for storing and sharing on-line your data, files, images, video, music, calendars and contacts. [http://karlitschek.de/2016/06/nextcloud/ Nextcloud is a fork of ownCloud with enterprise features included].<br />
<br />
= Installation =<br />
{{pkg|nextcloud}} is available from Alpine 3.5 and greater.<br />
<br />
Before you start installing anything, make sure you have the latest packages available. Make sure you are using an 'http' repository in your {{path|/etc/apk/repositories}} file, then:<br />
{{cmd|apk update}}<br />
{{tip|Detailed information is found in [[Include:Upgrading_to_latest_release|this]] doc.}}<br />
<br />
== Database ==<br />
First you have to decide which database to use. Use one of the databases listed below.<br />
<br />
=== Sqlite ===<br />
All you need to do is to install the package:<br />
{{cmd|apk add nextcloud-sqlite}}<br />
<br />
=== PostgreSQL ===<br />
Install the package:<br />
{{cmd|apk add nextcloud-pgsql postgresql postgresql-client}}<br />
<br />
Next thing is to configure and start the database:<br />
{{cmd|/etc/init.d/postgresql setup<br />
/etc/init.d/postgresql start}}<br />
<br />
Next, you need to create a user and temporarily grant the CREATEDB privilege:<br />
{{cmd|psql -U postgres<br />
CREATE USER mycloud WITH PASSWORD 'test123';<br />
ALTER ROLE mycloud CREATEDB;<br />
\q}}<br />
{{Note|Replace the above username 'mycloud' and password 'test123' with something secure. Remember these settings. You will need them later when setting up nextcloud.}}<br />
<br />
=== MariaDB ===<br />
Install the package:<br />
{{cmd|apk add nextcloud-mysql mariadb mariadb-client}}<br />
<br />
Now configure and start {{pkg|mariadb}}:<br />
{{cmd|<nowiki>mysql_install_db --user=mysql --datadir=/var/lib/mysql</nowiki><br />
service mariadb start<br />
rc-update add mariadb<br />
mysql_secure_installation}}<br />
Follow the wizard to setup passwords, etc.<br />
{{Note|Remember the usernames/passwords that you set using the wizard. You will need them later.}}<br />
<br />
Next, you need to create a user and database and set permissions:<br />
{{cmd|mysql -u root -p<br />
CREATE DATABASE nextcloud;<br />
GRANT ALL ON nextcloud.* TO 'mycloud'@'localhost' IDENTIFIED BY 'test123';<br />
GRANT ALL ON nextcloud.* TO 'mycloud'@'localhost.localdomain' IDENTIFIED BY 'test123';<br />
FLUSH PRIVILEGES;<br />
EXIT}}<br />
{{Note|Replace the above username 'mycloud' and password 'test123' with something secure. Remember these settings. You will need them later when setting up nextcloud.}}<br />
<br />
{{pkg|mariadb-client}} is not needed anymore. Let's uninstall it:<br />
{{cmd|apk del mariadb-client}}<br />
<br />
== Webserver ==<br />
Next thing is to choose, install, and configure a webserver. In this example we will install {{pkg|nginx}} or {{pkg|lighttpd}}. ''Nginx'' is preferred over ''Lighttpd'' since the latter will consume a lot of memory when working with large files (see [http://redmine.lighttpd.net/issues/1283 lighty bug #1283]). You are free to install any other webserver of your choice as long as it supports PHP and FastCGI. Generating an SSL certificate for your webserver is outside of the scope of this document.<br />
<br />
{{pkg|nextcloud-initscript}} facilitates running the webserver with php-fpm.<br />
<br />
{{cmd|apk add nextcloud-initscript}}<br />
<br />
=== Nginx ===<br />
Install the needed packages:<br />
{{cmd|apk add nginx php8-fpm}}<br />
<br />
Delete the default nginx configuration:<br />
{{cmd|rm /etc/nginx/http.d/default.conf}}<br />
<br />
Create a configuration file for your site in {{path|/etc/nginx/http.d/mysite.mydomain.com.conf}}:<br />
{{Cat|/etc/nginx/http.d/mysite.mydomain.com.conf|server {<br />
#listen [::]:80; #uncomment for IPv6 support<br />
listen 80;<br />
return 301 https://$host$request_uri;<br />
server_name mysite.mydomain.com;<br />
}<br />
<br />
server {<br />
#listen [::]:443 ssl; #uncomment for IPv6 support<br />
listen 443 ssl;<br />
server_name mysite.mydomain.com;<br />
<br />
root /usr/share/webapps/nextcloud;<br />
index index.php index.html index.htm;<br />
disable_symlinks off;<br />
<br />
ssl_certificate /etc/ssl/cert.pem;<br />
ssl_certificate_key /etc/ssl/key.pem;<br />
ssl_session_timeout 5m;<br />
<br />
#Enable Perfect Forward Secrecy and ciphers without known vulnerabilities<br />
#Beware! It breaks compatibility with older OS and browsers (e.g. Windows XP, Android 2.x, etc.)<br />
#ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA;<br />
#ssl_prefer_server_ciphers on;<br />
<br />
<br />
location / {<br />
try_files $uri $uri/ /index.html;<br />
}<br />
<br />
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000<br />
location ~ [^/]\.php(/&#124;$) {<br />
fastcgi_split_path_info ^(.+?\.php)(/.*)$;<br />
if (!-f $document_root$fastcgi_script_name) {<br />
return 404;<br />
}<br />
#fastcgi_pass 127.0.0.1:9000;<br />
#fastcgi_pass unix:/run/php-fpm/socket;<br />
fastcgi_pass unix:/run/nextcloud/fastcgi.sock; # From the nextcloud-initscript package<br />
fastcgi_index index.php;<br />
include fastcgi.conf;<br />
}<br />
}<br />
}}<br />
<br />
If you are running from RAM and you're dealing with large files you might need to move the FastCGI temp file from {{path|/tmp}} to {{path|/var/tmp}} or to a directory that is mounted on hdd:<br />
<pre><br />
fastcgi_temp_path /var/tmp/nginx/fastcgi 1 2;<br />
</pre><br />
<br />
Large file uploads take some time to be processed by php-fpm, so you need to bump the Nginx default read timeout:<br />
<br />
<pre><br />
fastcgi_read_timeout 300s;<br />
</pre><br />
<br />
{{Note|If you are serving serveral users make sure to tune the *''pm.max_children'' setting in {{path|/etc/php8/php-fpm.d/nextcloud.conf}}}}<br />
<br />
{{path|/etc/nginx/nginx.conf}} should already be configured to load your site config from this directory:<br />
<pre><br />
...<br />
# Includes virtual hosts configs.<br />
include /etc/nginx/http.d/*;<br />
...<br />
</pre><br />
<br />
Start services:<br />
{{cmd|service nginx start<br />
service nextcloud start}}<br />
<br />
Enable automatic startup of services:<br />
{{cmd|rc-update add nginx<br />
rc-update add nextcloud}}<br />
<br />
=== Lighttpd ===<br />
Install the package:<br />
{{cmd|apk add lighttpd php5-cgi}}<br />
<br />
Make sure you have FastCGI enabled in {{pkg|lighttpd}}:<br />
{{cat|/etc/lighttpd/lighttpd.conf|...<br />
include "mod_fastcgi.conf"<br />
...}}<br />
<br />
Start up the webserver:<br />
{{cmd|/etc/init.d/lighttpd start}}<br />
<br />
{{tip|You might want to follow the [http://wiki.alpinelinux.org/wiki/Lighttpd_Https_access Lighttpd_Https_access] doc in order to configure lighttpd to use https ''(securing your connections to your nextcloud server)''.}}<br />
<br />
Link {{pkg|nextcloud}} installation to web server directory:<br />
{{cmd|ln -s /usr/share/webapps/nextcloud /var/www/localhost/htdocs}}<br />
<br />
== Other settings ==<br />
=== Hardening ===<br />
Consider updating the variable <code>url.access-deny</code> in {{path|/etc/lighttpd/lighttpd.conf}} for additional security. Add <code>"config.php"</code> to the variable ''(that's where the database is stored)'' so it looks something like this:<br />
{{cat|/etc/lighttpd/lighttpd.conf|...<br />
url.access-deny {{=}} ("~", ".inc", "config.php")<br />
...}}<br />
Restart {{pkg|lighttpd}} to activate the changes:<br />
{{cmd|/etc/init.d/lighttpd restart}}<br />
<br />
=== Additional packages ===<br />
Some large apps, such as pdfviewer, texteditor, notifications and videoplayer are in separate packages:<br />
{{cmd|apk add nextcloud-pdfviewer nextcloud-texteditor nextcloud-notifications nextcloud-videoplayer}}<br />
<br />
=== How To Create a Self-Signed SSL Certificate ===<br />
Install openssl:<br />
{{cmd|apk add openssl}}<br />
Generate your self signed certificate and its private key:<br />
{{cmd|<nowiki>openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout /etc/ssl1.1/private/nextcloud-selfsigned.key -out /etc/ssl1.1/certs/nextcloud-selfsigned.crt</nowiki>}}<br />
Edit your nginx configuration:<br />
{{cat|/etc/nginx/http.d/mysite.mydomain.com.conf|<br />
ssl_certificate /etc/ssl1.1/certs/nextcloud-selfsigned.crt;<br />
ssl_certificate_key /etc/ssl1.1/private/nextcloud-selfsigned.key;<br />
}}<br />
<br />
= Configure and use Nextcloud =<br />
== Configure ==<br />
Point your browser at <code><nowiki>https://mysite.mydomain.com</nowiki></code> and follow the on-screen instructions to complete the installation, supplying the database user and password created before.<br />
<br />
== Hardening PostgreSQL ==<br />
If you have chosen PGSQL backend, revoke CREATEDB privilege from 'mycloud' user:<br />
{{cmd|psql -U postgres<br />
ALTER ROLE mycloud NOCREATEDB;<br />
\q}}<br />
<br />
== Increase upload size ==<br />
{{path|/etc/php/php-fpm.d/nextcloud.conf}} has overridden default file sizes, but they can be modified further to suit your needs:<br />
<pre><br />
; Maximal size of a file that can be uploaded via web interface.<br />
php_admin_value[memory_limit] = 512M<br />
php_admin_value[post_max_size] = 513M<br />
php_admin_value[upload_max_filesize] = 513M<br />
</pre><br />
<br />
== enable opcache for nginx/php7 ==<br />
To increase performace install<br />
{{cmd|apk add php7-opcache}}<br />
<br />
Now uncomment/edit lines in /etc/php7/php.ini:<br />
<pre><br />
...<br />
opcache.enable=1<br />
opcache.enable_cli=1<br />
opcache.interned_strings_buffer=8<br />
opcache.max_accelerated_files=10000<br />
opcache.memory_consumption=128<br />
opcache.save_comments=1<br />
opcache.revalidate_freq=1<br />
...<br />
</pre><br />
<br />
Restart php-fpm7<br />
{{cmd|rc-service php-fpm7 restart}}<br />
<br />
== Clients ==<br />
There are clients available for many platforms, Android included:<br />
* http://nextcloud.org/sync-clients/ ''(nextcloud Sync clients)''<br />
* http://nextcloud.org/support/android/ ''(Android client)''<br />
<br />
[http://pkgs.alpinelinux.org/packages?name=nextcloud-client&branch=&repo=&arch=&maintainer= nextcloud-client] is currently available in the testing repo.<br />
<br />
= Video Communication =<br />
One of the major features of Nextcloud 11, available on Alpine 3.6 (currently edge) is a [https://nextcloud.com/webrtc/ WebRTC app], which relies on Spreed WebRTC server, which is available in the Alpine testing repository. Everything is still beta, so be aware of it :-). If you want a private video conferencing server install Nextcloud using Nginx and do the following (you can use Apache as well and follow the ''Apache config'' instructions [https://nextcloud.com/webrtc/ nextcloud.com]):<br />
<br />
Put the following config in the ''server'' section of Nginx:<br />
<pre><br />
# Spreed WebRTC<br />
location ^~ /webrtc {<br />
proxy_pass http://127.0.0.1:8080;<br />
proxy_http_version 1.1;<br />
proxy_set_header Upgrade $http_upgrade;<br />
proxy_set_header Connection $connection_upgrade;<br />
proxy_set_header X-Forwarded-Proto $scheme;<br />
proxy_set_header Host $http_host;<br />
proxy_set_header X-Real-IP $remote_addr;<br />
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<br />
<br />
proxy_buffering on;<br />
proxy_ignore_client_abort off;<br />
proxy_redirect off;<br />
proxy_connect_timeout 90;<br />
proxy_send_timeout 90;<br />
proxy_read_timeout 90;<br />
proxy_buffer_size 4k;<br />
proxy_buffers 4 32k;<br />
proxy_busy_buffers_size 64k;<br />
proxy_temp_file_write_size 64k;<br />
proxy_next_upstream error timeout invalid_header http_502 http_503 http_504;<br />
}<br />
</pre><br />
<br />
Put the following section in the ''http'' section of Nginx:<br />
<pre><br />
map $http_upgrade $connection_upgrade {<br />
default upgrade;<br />
'' close;<br />
}<br />
</pre><br />
<br />
Reload Nginx:<br />
{{cmd|rc-service nginx reload}}<br />
<br />
Install Spreed WedRTC server (make sure you have the testing [https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Packages_and_Repositories repository] enabled):<br />
{{cmd|apk add spreed-web-server}}<br />
<br />
Using the configuration file in ''/etc/spreed-webrtc/spreed-webrtc-server.conf'' follow the instructions at [https://nextcloud.com/webrtc/ nextcloud.com] to configure Spreed WebRTC server. Then start the server:<br />
{{cmd|rc-service spreed-web-server start}}<br />
{{cmd|rc-update add spreed-web-server}}<br />
<br />
Install the ''Spreed video calls'' app in Nextcloud and enjoy your private video calls.<br />
<br />
[[Category:Server]]</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=Gitea&diff=20846Gitea2021-12-16T00:00:15Z<p>Ktprograms: </p>
<hr />
<div>[https://gitea.io Gitea] is a community managed lightweight code hosting solution written in Go. It is a fork of Gogs.<br />
<br />
{{Note|This guide is not for installing Gitea in Docker. If you want to install Gitea in a Docker container, follow [https://docs.gitea.io/en-us/install-with-docker/ the official documentation]}}<br />
<br />
== Installation ==<br />
<br />
First, [[Enable Community Repository | Enable the Community Repository]]<br />
<br />
Then install the {{pkg|gitea}} package:<br />
{{cmd|apk add gitea}}<br />
<br />
== Setting up the Database ==<br />
<br />
{{Note|These instructions are for MariaDB. If you would like to set up another database, follow [https://docs.gitea.io/en-us/database-prep/ the official documentation]}}<br />
<br />
Install the MariaDB and {{pkg|mariadb-client}} packages:<br />
{{cmd|apk add mariadb mariadb-client}}<br />
<br />
Set up the MariaDB installation and secure it:<br />
{{cmd|<nowiki>mysql_install_db --user=mysql --datadir=/var/lib/mysql</nowiki><br />
service mariadb start<br />
rc-update add mariadb<br />
mysql_secure_installation}}<br />
<br />
Create the <code>gitea</code> database and a user with access to it:<br />
{{Note|Everything after the <code>mysql -u root -p</code> should be typed in the MariaDB prompt (looks like <code>MariaDB [(none)]></code>)}}<br />
{{Note|Replace the above username 'giteauser' and password 'giteapassword' with something secure. Remember these settings. You will need them later when setting up Gitea.}}<br />
{{cmd|mysql -u root -p<br />
<br />
CREATE DATABASE gitea DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;<br />
GRANT ALL ON gitea.* TO 'giteauser'@'localhost' IDENTIFIED BY 'giteapassword';<br />
FLUSH PRIVILEGES;<br />
EXIT}}<br />
<br />
If you want, you can uninstall the <code>mariadb-client</code> now as it's not needed anymore:<br />
{{cmd|apk del mariadb-client}}<br />
<br />
In {{path|/etc/gitea/app.ini}}, replace the contents of the <code>[database]</code> section with the following:<br />
<pre><br />
DB_TYPE = mysql<br />
HOST = /var/run/mysqld/mysqld.sock<br />
NAME = gitea ; The database name set with 'CREATE DATABASE'<br />
USER = giteauser ; The database user<br />
PASSWD = giteapassword ; The password for the database user<br />
</pre><br />
<br />
== Configurations ==<br />
<br />
The Gitea service can be configured using {{path|/etc/conf.d/gitea}}:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description !! Configuration Variable !! Default Value<br />
|-<br />
| User to run Gitea under || GITEA_USER || gitea<br />
|-<br />
| Gitea working directory || GITEA_WORK_DIR || /var/lib/gitea/<br />
|-<br />
| Gitea configuration file || GITEA_CONF || /etc/gitea/app.ini<br />
|}<br />
<br />
Some additional settings in {{path|/etc/gitea/app.ini}}:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description !! Configuration Variable !! Default Value<br />
|-<br />
| Gitea customization directory || <code>Cannot be configured</code> || /var/lib/gitea/custom/<br />
|-<br />
| Web files || STATIC_ROOT_PATH || /usr/share/webapps/gitea/<br />
|-<br />
| Data files || APP_DATA_PATH || /var/lib/gitea/data/<br />
|-<br />
| Git repository storage directory || ROOT || /var/lib/gitea/git/<br />
|-<br />
| Log directory || ROOT_PATH || /var/log/gitea/<br />
|}<br />
<br />
{{Note|Gitea has a built-in web server, so there is no need to configure one. However, you can [https://docs.gitea.io/en-us/reverse-proxies/ set up a reverse proxy].}}<br />
<br />
{{Note|To customize the look and feel of Gitea, find the correct path in {{path|/usr/share/webapps/gitea/}} and make the same path in {{path|/var/lib/gitea/custom/}}. For example, to add a new Gitea theme, create the {{path|/var/lib/gitea/custom/public/css/}} directory, then add the css for the theme there.}}<br />
<br />
== Controlling and starting gitea ==<br />
<br />
You should not start Gitea without setting certain environment variables and passing some options, since it won't know where to store data and logs, so it is recommended to start gitea using the init script:<br />
{{cmd|service gitea start}}<br />
<br />
To add Gitea to the default runlevel (such that it runs automatically on every boot):<br />
{{cmd|rc-update add gitea}}<br />
<br />
To stop the Gitea service:<br />
{{cmd|service gitea stop}}<br />
<br />
=== Running Gitea without the init script ===<br />
<br />
If (for whatever reason), you would like to start Gitea without using the initscript, you should first stop the Gitea service:<br />
{{cmd|service gitea stop}}<br />
<br />
Then, run Gitea with this command (as the <code>gitea</code> user):<br />
{{cmd|<nowiki>GITEA_WORK_DIR=/var/lib/gitea gitea web --config /etc/gitea/app.ini</nowiki>}}<br />
<br />
This will use the correct configuration file and write to the correct directories.<br />
<br />
== Post installation ==<br />
<br />
{{Expand}}<br />
<br />
After installing Gitea, go to http://localhost:3000 and start the post-installation process.<br />
<br />
== Setting up SSH Git access ==<br />
<br />
'''Do not''' try to be clever and use <code>ssh-copy-id</code>, as it will not have the correct command set.<br />
<br />
As an example, if this is the public key:<br />
<pre><br />
ssh-ed25519 ******************************************************************** **********@gmail.com<br />
</pre><br />
<br />
The line in {{path|.ssh/authorized_keys}} needs to be:<br />
<pre><br />
command="/usr/bin/gitea --config=/etc/gitea/app.ini serv key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 ******************************************************************** **********@gmail.com<br />
</pre><br />
<br />
In order to do this, [https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent generate a SSH key], then go to the Gitea settings panel and click the <code>Add Key</code> button, then paste in your public key.<br />
<br />
Now, once you've added your private key to the SSH agent, you can use SSH with Gitea like you normally would with GitHub, GitLab, etc.<br />
<br />
= See Also =<br />
<br />
* [[Alpine newbie]]<br />
<br />
[[Category:Server]]<br />
[[Category:Git]]</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=Gitea&diff=20765Gitea2021-12-11T14:05:35Z<p>Ktprograms: Move expand template to Post installation section</p>
<hr />
<div>[https://gitea.io Gitea] is a community managed lightweight code hosting solution written in Go. It is a fork of Gogs.<br />
<br />
{{Note|This guide is not for installing Gitea in Docker. If you want to install Gitea in a Docker container, follow [https://docs.gitea.io/en-us/install-with-docker/ the official documentation]}}<br />
<br />
== Installation ==<br />
<br />
First, [[Enable Community Repository | Enable the Community Repository]]<br />
<br />
Then install the {{pkg|gitea}} package:<br />
{{cmd|apk add gitea}}<br />
<br />
== Setting up the Database ==<br />
<br />
{{Note|These instructions are for MariaDB. If you would like to set up another database, follow [https://docs.gitea.io/en-us/database-prep/ the official documentation]}}<br />
<br />
Install the MariaDB and {{pkg|mariadb-client}} packages:<br />
{{cmd|apk add mariadb mariadb-client}}<br />
<br />
Set up the MariaDB installation and secure it:<br />
{{cmd|<nowiki>mysql_install_db --user=mysql --datadir=/var/lib/mysql</nowiki><br />
service mariadb start<br />
rc-update add mariadb<br />
mysql_secure_installation}}<br />
<br />
Create the <code>gitea</code> database and a user with access to it:<br />
{{Note|Everything after the <code>mysql -u root -p</code> should be typed in the MariaDB prompt (looks like <code>MariaDB [(none)]></code>)}}<br />
{{Note|Replace the above username 'giteauser' and password 'giteapassword' with something secure. Remember these settings. You will need them later when setting up Gitea.}}<br />
{{cmd|mysql -u root -p<br />
<br />
CREATE DATABASE gitea DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;<br />
GRANT ALL ON gitea.* TO 'giteauser'@'localhost' IDENTIFIED BY 'giteapassword';<br />
FLUSH PRIVILEGES;<br />
EXIT}}<br />
<br />
If you want, you can uninstall the <code>mariadb-client</code> now as it's not needed anymore:<br />
{{cmd|apk del mariadb-client}}<br />
<br />
In {{path|/etc/gitea/app.ini}}, replace the contents of the <code>[database]</code> section with the following:<br />
<pre><br />
DB_TYPE = mysql<br />
HOST = /var/run/mysqld/mysqld.sock<br />
NAME = gitea ; The database name set with 'CREATE DATABASE'<br />
USER = giteauser ; The database user<br />
PASSWD = giteapassword ; The password for the database user<br />
</pre><br />
<br />
== Configurations ==<br />
<br />
The Gitea service can be configured using {{path|/etc/conf.d/gitea}}:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description !! Configuration Variable !! Default Value<br />
|-<br />
| User to run Gitea under || GITEA_USER || gitea<br />
|-<br />
| Gitea working directory || GITEA_WORK_DIR || /var/lib/gitea/<br />
|-<br />
| Gitea configuration file || GITEA_CONF || /etc/gitea/app.ini<br />
|}<br />
<br />
Some additional settings in {{path|/etc/gitea/app.ini}}:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description !! Configuration Variable !! Default Value<br />
|-<br />
| Gitea customization directory || <code>Cannot be configured</code> || /var/lib/gitea/custom/<br />
|-<br />
| Web files || STATIC_ROOT_PATH || /usr/share/webapps/gitea/<br />
|-<br />
| Data files || APP_DATA_PATH || /var/lib/gitea/data/<br />
|-<br />
| Git repository storage directory || ROOT || /var/lib/gitea/git/<br />
|-<br />
| Log directory || ROOT_PATH || /var/log/gitea/<br />
|}<br />
<br />
{{Note|Gitea has a built-in web server, so there is no need to configure one. However, you can [https://docs.gitea.io/en-us/reverse-proxies/ set up a reverse proxy].}}<br />
<br />
{{Note|To customize the look and feel of Gitea, find the correct path in {{path|/usr/share/webapps/gitea/}} and make the same path in {{path|/var/lib/gitea/custom/}}. For example, to add a new Gitea theme, create the {{path|/var/lib/gitea/custom/public/css/}} directory, then add the css for the theme there.}}<br />
<br />
== Controlling and starting gitea ==<br />
<br />
You should not start Gitea without setting certain environment variables and passing some options, since it won't know where to store data and logs, so it is recommended to start gitea using the init script:<br />
{{cmd|service gitea start}}<br />
<br />
To add Gitea to the default runlevel (such that it runs automatically on every boot):<br />
{{cmd|rc-update add gitea}}<br />
<br />
To stop the Gitea service:<br />
{{cmd|service gitea stop}}<br />
<br />
=== Running Gitea without the init script ===<br />
<br />
If (for whatever reason), you would like to start Gitea without using the initscript, you should first stop the Gitea service:<br />
{{cmd|service gitea stop}}<br />
<br />
Then, run Gitea with this command (as the <code>gitea</code> user):<br />
{{cmd|<nowiki>GITEA_WORK_DIR=/var/lib/gitea gitea web --config /etc/gitea/app.ini</nowiki>}}<br />
<br />
This will use the correct configuration file and write to the correct directories.<br />
<br />
== Post installation ==<br />
<br />
{{Expand}}<br />
<br />
After installing Gitea, go to http://localhost:3000 and start the post-installation process.<br />
<br />
= See Also =<br />
<br />
* [[Alpine newbie]]<br />
<br />
[[Category:Server]]<br />
[[Category:Git]]</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=Talk:Alpine_and_UEFI&diff=20746Talk:Alpine and UEFI2021-12-09T08:06:58Z<p>Ktprograms: </p>
<hr />
<div>lasted changes from Grayhatter said "are so bad" .. bad due i cited the true of tha all 8086 derived procesors have embebed 16bit compatibility?<br />
<br />
manufeactures true?.. '''i like improvements but not "cutting" info.. so before me alpine wiki was a disorder poutdates pages.. seems this are the now crap of?'''<br />
<br />
<!-- Template:Unsigned --><span class="autosigned" style="font-size:85%;">—&nbsp;Preceding unsigned comments added by [[User:Mckaygerhard|Mckaygerhard ]] ([[User talk:Mckaygerhard #top|talk]] • [[Special:Contributions/Mckaygerhard |contribs]]) 19:37, 18 October 2019</span><br />
<br />
== Minimum Alpine partition sheme ==<br />
<br />
This section mentions that swap partition is needed... Is this true for the current alpine setup scripts? Can alpine be setup without swap? Or perhaps with a swap file instead? If the setup script allows no swap or swap file, the statement about swap partitions being mandatory should be removed.<br />
[[User:Zcrayfish|zcrayfish]] ([[User talk:Zcrayfish|talk]]) 01:30, 9 December 2021 (UTC)<br />
<br />
My comments on this:<br />
* If you run <code>setup-disk</code> with the <code>SWAP_SIZE</code> environment variable set to 0 (i.e. <code>SWAP_SIZE=0 setup-disk</code>), then the script won't create any swap.<br />
* As far as I can tell, a swap partition isn't mandatory (for example I've set up a VM that uses the entire disk without partitioning, the VM software handles loading the kernel so there's no bootloader either).<br />
* Also, it should be '''scheme''' instead of '''sheme''' (missing the 'c')<br />
[[User:Ktprograms|Ktprograms]] ([[User talk:Ktprograms|talk]]) 08:06, 9 December 2021 (UTC)</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=Gitea&diff=20745Gitea2021-12-09T07:11:18Z<p>Ktprograms: </p>
<hr />
<div>{{Expand}}<br />
<br />
[https://gitea.io Gitea] is a community managed lightweight code hosting solution written in Go. It is a fork of Gogs.<br />
<br />
{{Note|This guide is not for installing Gitea in Docker. If you want to install Gitea in a Docker container, follow [https://docs.gitea.io/en-us/install-with-docker/ the official documentation]}}<br />
<br />
== Installation ==<br />
<br />
First, [[Enable Community Repository | Enable the Community Repository]]<br />
<br />
Then install the {{pkg|gitea}} package:<br />
{{cmd|apk add gitea}}<br />
<br />
== Setting up the Database ==<br />
<br />
{{Note|These instructions are for MariaDB. If you would like to set up another database, follow [https://docs.gitea.io/en-us/database-prep/ the official documentation]}}<br />
<br />
Install the MariaDB and {{pkg|mariadb-client}} packages:<br />
{{cmd|apk add mariadb mariadb-client}}<br />
<br />
Set up the MariaDB installation and secure it:<br />
{{cmd|<nowiki>mysql_install_db --user=mysql --datadir=/var/lib/mysql</nowiki><br />
service mariadb start<br />
rc-update add mariadb<br />
mysql_secure_installation}}<br />
<br />
Create the <code>gitea</code> database and a user with access to it:<br />
{{Note|Everything after the <code>mysql -u root -p</code> should be typed in the MariaDB prompt (looks like <code>MariaDB [(none)]></code>)}}<br />
{{Note|Replace the above username 'giteauser' and password 'giteapassword' with something secure. Remember these settings. You will need them later when setting up Gitea.}}<br />
{{cmd|mysql -u root -p<br />
<br />
CREATE DATABASE gitea DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;<br />
GRANT ALL ON gitea.* TO 'giteauser'@'localhost' IDENTIFIED BY 'giteapassword';<br />
FLUSH PRIVILEGES;<br />
EXIT}}<br />
<br />
If you want, you can uninstall the <code>mariadb-client</code> now as it's not needed anymore:<br />
{{cmd|apk del mariadb-client}}<br />
<br />
In {{path|/etc/gitea/app.ini}}, replace the contents of the <code>[database]</code> section with the following:<br />
<pre><br />
DB_TYPE = mysql<br />
HOST = /var/run/mysqld/mysqld.sock<br />
NAME = gitea ; The database name set with 'CREATE DATABASE'<br />
USER = giteauser ; The database user<br />
PASSWD = giteapassword ; The password for the database user<br />
</pre><br />
<br />
== Configurations ==<br />
<br />
The Gitea service can be configured using {{path|/etc/conf.d/gitea}}:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description !! Configuration Variable !! Default Value<br />
|-<br />
| User to run Gitea under || GITEA_USER || gitea<br />
|-<br />
| Gitea working directory || GITEA_WORK_DIR || /var/lib/gitea/<br />
|-<br />
| Gitea configuration file || GITEA_CONF || /etc/gitea/app.ini<br />
|}<br />
<br />
Some additional settings in {{path|/etc/gitea/app.ini}}:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description !! Configuration Variable !! Default Value<br />
|-<br />
| Gitea customization directory || <code>Cannot be configured</code> || /var/lib/gitea/custom/<br />
|-<br />
| Web files || STATIC_ROOT_PATH || /usr/share/webapps/gitea/<br />
|-<br />
| Data files || APP_DATA_PATH || /var/lib/gitea/data/<br />
|-<br />
| Git repository storage directory || ROOT || /var/lib/gitea/git/<br />
|-<br />
| Log directory || ROOT_PATH || /var/log/gitea/<br />
|}<br />
<br />
{{Note|Gitea has a built-in web server, so there is no need to configure one. However, you can [https://docs.gitea.io/en-us/reverse-proxies/ set up a reverse proxy].}}<br />
<br />
{{Note|To customize the look and feel of Gitea, find the correct path in {{path|/usr/share/webapps/gitea/}} and make the same path in {{path|/var/lib/gitea/custom/}}. For example, to add a new Gitea theme, create the {{path|/var/lib/gitea/custom/public/css/}} directory, then add the css for the theme there.}}<br />
<br />
== Controlling and starting gitea ==<br />
<br />
You should not start Gitea without setting certain environment variables and passing some options, since it won't know where to store data and logs, so it is recommended to start gitea using the init script:<br />
{{cmd|service gitea start}}<br />
<br />
To add Gitea to the default runlevel (such that it runs automatically on every boot):<br />
{{cmd|rc-update add gitea}}<br />
<br />
To stop the Gitea service:<br />
{{cmd|service gitea stop}}<br />
<br />
=== Running Gitea without the init script ===<br />
<br />
If (for whatever reason), you would like to start Gitea without using the initscript, you should first stop the Gitea service:<br />
{{cmd|service gitea stop}}<br />
<br />
Then, run Gitea with this command (as the <code>gitea</code> user):<br />
{{cmd|<nowiki>GITEA_WORK_DIR=/var/lib/gitea gitea web --config /etc/gitea/app.ini</nowiki>}}<br />
<br />
This will use the correct configuration file and write to the correct directories.<br />
<br />
== Post installation ==<br />
<br />
After installing Gitea, go to http://localhost:3000 and start the post-installation process.<br />
<br />
= See Also =<br />
<br />
* [[Alpine newbie]]<br />
<br />
[[Category:Server]]<br />
[[Category:Git]]</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=Talk:Gitea&diff=20742Talk:Gitea2021-12-09T00:38:57Z<p>Ktprograms: </p>
<hr />
<div>== Suggested changes: ==<br />
The '''Clarifications''' section should probably be removed because (each number point is a reason to remove the corresponding number point in that section):<br />
# The user setting up Gitea would probably be familiar with what Gitea is, so there's no need to explain the history of Gitea<br />
# This should either be removed or directly link to the [https://docs.gitea.io/en-us/install-with-docker/ Gitea documentation for setting up in a Docker container]<br />
# Just remove this<br />
# (a) the '''git''' command doesn't need to be installed separately (it's a dependency of Gitea), (b) While the knowledge that server repositories are bare repositories can be important, I don't think it's critical in the setting up of Gitea.<br />
<br />
The '''Pre Requirements''' section isn't needed, and should be replaced with instructions on how to set up the databases (for example with mariadb):<br />
<pre><br />
apk add mariadb mariadb-client<br />
mysql_install_db --user=mysql --datadir=/var/lib/mysql<br />
service mariadb start<br />
rc-update add mariadb<br />
mysql_secure_installation<br />
<br />
mysql -u root -p<br />
CREATE DATABASE gitea;<br />
GRANT ALL ON gitea.* TO 'giteadbuser'@'localhost' IDENTIFIED BY 'giteadbpasswd';<br />
FLUSH PRIVILEGES;<br />
EXIT<br />
</pre><br />
<br />
As for the hostname configuration in the '''Pre Requirements''' section, if a user hasn't yet run setup-hostname, they will be having a bigger problem than not just being able to get Gitea working.<br />
<br />
The hacky 'Install most dependencies from community' then 'Switch to edge to install Gitea' and finally 'Switch back to community' instructions in the '''Installation''' section can be removed given that Gitea has been in stable community since v3.6. The warning about manually creating a user can also be removed since the pre-install script handles that.<br />
<br />
The '''Database configurations''' section can be removed since the info will be expanded on higher up (replacing the '''Pre requirements''' section)<br />
<br />
[[User:Ktprograms|Ktprograms]] ([[User talk:Ktprograms|talk]]) 00:38, 9 December 2021 (UTC) Ktprograms</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=Talk:Gitea&diff=20741Talk:Gitea2021-12-09T00:38:42Z<p>Ktprograms: Created page with "== Suggested changes: == The '''Clarifications''' section should probably be removed because (each number point is a reason to remove the corresponding number point in that se..."</p>
<hr />
<div>== Suggested changes: ==<br />
The '''Clarifications''' section should probably be removed because (each number point is a reason to remove the corresponding number point in that section):<br />
# The user setting up Gitea would probably be familiar with what Gitea is, so there's no need to explain the history of Gitea<br />
# This should either be removed or directly link to the [https://docs.gitea.io/en-us/install-with-docker/ Gitea documentation for setting up in a Docker container]<br />
# Just remove this<br />
# (a) the '''git''' command doesn't need to be installed separately (it's a dependency of Gitea), (b) While the knowledge that server repositories are bare repositories can be important, I don't think it's critical in the setting up of Gitea.<br />
<br />
The '''Pre Requirements''' section isn't needed, and should be replaced with instructions on how to set up the databases (for example with mariadb):<br />
<pre><br />
apk add mariadb mariadb-client<br />
mysql_install_db --user=mysql --datadir=/var/lib/mysql<br />
service mariadb start<br />
rc-update add mariadb<br />
mysql_secure_installation<br />
<br />
mysql -u root -p<br />
CREATE DATABASE gitea;<br />
GRANT ALL ON gitea.* TO 'giteadbuser'@'localhost' IDENTIFIED BY 'giteadbpasswd';<br />
FLUSH PRIVILEGES;<br />
EXIT<br />
</pre><br />
<br />
As for the hostname configuration in the '''Pre Requirements''' section, if a user hasn't yet run setup-hostname, they will be having a bigger problem than not just being able to get Gitea working.<br />
<br />
The hacky 'Install most dependencies from community' then 'Switch to edge to install Gitea' and finally 'Switch back to community' instructions in the '''Installation''' section can be removed given that Gitea has been in stable community since v3.6. The warning about manually creating a user can also be removed since the pre-install script handles that.<br />
<br />
The '''Database configurations''' section can be removed since the info will be expanded on higher up (replacing the '''Pre requirements''' section)</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=How_to_make_a_cross_architecture_chroot&diff=20209How to make a cross architecture chroot2021-10-27T08:31:23Z<p>Ktprograms: Added ppc64le and s390x magic/mask to the qemu-binfmt script</p>
<hr />
<div>=How to make a chroot to run a different architecture (e.g. x86 on arm)=<br />
<br />
If you have an arm computer, you might find that some software is only available for x86_64. One possible solution is to have a full x86_64 virtual machine, but that has quite a lot of overhead from having to emulate the entire system. Fortunately, there is [https://qemu-project.gitlab.io/qemu/user/main.html QEMU User space emulation] which still uses the host kernel, so there is less overhead. This guide will show you how to make a chroot and enable transparent x86_64 binary execution using qemu and binfmt_misc.<br />
<br />
==Prerequisites==<br />
<br />
You should be familiar with the linux command line.<br />
This guide is written assuming you have alpine as the main install as well as putting alpine in the chroot.<br />
<br />
Also, the commands shown assume you have root privileges. Either use sudo as needed or su first.<br />
<br />
==Installing necessary software==<br />
<br />
First, [[Enable Community Repository | Enable the Community Repository]]. Next, install the qemu user mode binaries for the architectures you want to use, in this case x86_64 and i386:<br />
<br />
<pre><br />
apk add qemu-x86_64 qemu-i386<br />
</pre><br />
<br />
Please note there are the <code>qemu-system-*</code> packages, you don't want those since they are used for full virtual machine emulation.<br />
<br />
Then, curl my modified version of the qemu-binfmt script (originally from the [https://pkgs.alpinelinux.org/package/edge/community/aarch64/qemu-openrc qemu-openrc] package):<br />
<br />
<pre><br />
curl -o /etc/init.d/qemu-binfmt 'https://gist.githubusercontent.com/ktprograms/c8ea850abde717376ff7a6f83dbabb2f/raw/0ff0596e8f9f1891f272393fa1ff0529bcbcef5d/qemu-binfmt'<br />
</pre><br />
<br />
I prefer to use this script instead of installing the qemu-openrc package since that adds a lot of unneeded dependencies. Right now this only supports i386, x86_64, arm, ppc64le and s390x but I'll be adding all the architectures soon.<br />
<br />
Make the qemu-binfmt script executable:<br />
<br />
<pre><br />
chmod +x /etc/init.d/qemu-binfmt<br />
</pre><br />
<br />
==Enable the <code>qemu-binfmt</code> service and start it==<br />
<br />
The qemu-binfmt script is an OpenRC init script that registers the binfmt_misc handlers when the service starts and unregisters them when the service stops. Add the service to the default runlevel and start it immediately:<br />
<br />
<pre><br />
rc-update add qemu-binfmt default<br />
service qemu-binfmt start<br />
</pre><br />
<br />
==Make the chroot folder==<br />
<br />
To keep it simple, we're just going to use the apk repositories specified on the host system. This guide assumes the <code>$CHROOT</code> environment variable holds the directory where you want to make the chroot. Make the chroot directory and the <code>etc/apk</code> subdirectory (which we'll copy the apk repositories file to):<br />
<br />
<pre><br />
mkdir -p $CHROOT/etc/apk/<br />
</pre><br />
<br />
Now copy the host's apk repositories into the chroot folder:<br />
<br />
<pre><br />
cp /etc/apk/repositories $CHROOT/etc/apk/<br />
</pre><br />
<br />
You'll also need to copy the resolv.conf file into the chroot so it can have internet access:<br />
<br />
<pre><br />
cp /etc/resolv.conf $CHROOT/etc/<br />
</pre><br />
<br />
==Install <code>alpine-base</code> into the chroot folder==<br />
<br />
The <code>alpine-base</code> meta package is all that's needed to have a fully working alpine system. The apk invocation used here has a few more options than what you might be used to:<br />
<br />
<pre><br />
apk add -p $CHROOT --initdb -U --arch x86_64 --allow-untrusted alpine-base<br />
</pre><br />
<br />
Here's what all the options do:<br />
*<code>-p $CHROOT</code>: Sets the root of the install to <code>$CHROOT</code> instead of <code>/</code><br />
*<code>--initdb</code>: Initialize a new package database.<br />
*<code>-U</code>: Alias for <code>--cache-max-age 1</code>. Basically means don't install from cache.<br />
*<code>--arch x86_64</code>: Install x86_64 packages instead of native packages. Replace this with whichever architecture you want to emulate instead (e.g. <code>--arch x86</code>).<br />
*<code>--allow-untrusted</code>: Install packages with untrusted signature or no signature. (This is needed since the keys for different architectures are different than what will be on your host. If you have the correct keys, you can copy them into the <code>$CHROOT/etc/apk/keys/</code> directory and remove this flag).<br />
<br />
==Mount the virtual file systems into the chroot==<br />
<br />
<pre><br />
mount -t proc proc $CHROOT/proc/<br />
mount -t sysfs sys $CHROOT/sys/<br />
mount -o bind /dev/ $CHROOT/dev/<br />
mount -o bind /dev/pts/ $CHROOT/dev/pts/<br />
mount -o bind /run $CHROOT/run/<br />
</pre><br />
<br />
==The exciting part: Enter the chroot==<br />
<br />
If you've followed all the steps, this part should be uneventful. The <code>chroot</code> invocation uses the special command of <code>ash -l</code> to run as a login shell and source <code>/etc/profile</code>:<br />
<br />
<pre><br />
chroot $CHROOT/ ash -l<br />
</pre><br />
<br />
==Troubleshooting==<br />
<br />
If you get a <code>ERROR: ${package_name}.post-install: script exited with error 127</code> while trying to add the alpine-base, that normally means that qemu binfmt_misc hasn't been setup properly. Check if the <code>qemu-$arch</code> package has been installed and see if the binfmt_misc service is running. You can also see if there is a <code>qemu-$arch</code> entry in <code>/proc/sys/fs/binfmt_misc/</code>.<br />
<br />
Programs that use [https://en.wikipedia.org/wiki/Netlink Netlink] (e.g. <code>ip addr</code>) don't seem to work properly since qemu doesn't emulate the Netlink protocol properly.<br />
<br />
==References==<br />
<br />
https://ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc/ (see the section titled <code>Emulating full ARM rootfs</code>)</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=How_to_make_a_cross_architecture_chroot&diff=20207How to make a cross architecture chroot2021-10-25T06:30:28Z<p>Ktprograms: I updated the qemu-binfmt script to include arm so here's the new link</p>
<hr />
<div>=How to make a chroot to run a different architecture (e.g. x86 on arm)=<br />
<br />
If you have an arm computer, you might find that some software is only available for x86_64. One possible solution is to have a full x86_64 virtual machine, but that has quite a lot of overhead from having to emulate the entire system. Fortunately, there is [https://qemu-project.gitlab.io/qemu/user/main.html QEMU User space emulation] which still uses the host kernel, so there is less overhead. This guide will show you how to make a chroot and enable transparent x86_64 binary execution using qemu and binfmt_misc.<br />
<br />
==Prerequisites==<br />
<br />
You should be familiar with the linux command line.<br />
This guide is written assuming you have alpine as the main install as well as putting alpine in the chroot.<br />
<br />
Also, the commands shown assume you have root privileges. Either use sudo as needed or su first.<br />
<br />
==Installing necessary software==<br />
<br />
First, [[Enable Community Repository | Enable the Community Repository]]. Next, install the qemu user mode binaries for the architectures you want to use, in this case x86_64 and i386:<br />
<br />
<pre><br />
apk add qemu-x86_64 qemu-i386<br />
</pre><br />
<br />
Please note there are the <code>qemu-system-*</code> packages, you don't want those since they are used for full virtual machine emulation.<br />
<br />
Then, curl my modified version of the qemu-binfmt script (originally from the [https://pkgs.alpinelinux.org/package/edge/community/aarch64/qemu-openrc qemu-openrc] package):<br />
<br />
<pre><br />
curl -o /etc/init.d/qemu-binfmt 'https://gist.githubusercontent.com/ktprograms/c8ea850abde717376ff7a6f83dbabb2f/raw/b14067975353a941fb8fc3ad8be9e375acab5eb4/qemu-binfmt'<br />
</pre><br />
<br />
I prefer to use this script instead of installing the qemu-openrc package since that adds a lot of unneeded dependencies. Right now this only supports i386, x86_64 and arm but I'll be adding all the architectures soon.<br />
<br />
Make the qemu-binfmt script executable:<br />
<br />
<pre><br />
chmod +x /etc/init.d/qemu-binfmt<br />
</pre><br />
<br />
==Enable the <code>qemu-binfmt</code> service and start it==<br />
<br />
The qemu-binfmt script is an OpenRC init script that registers the binfmt_misc handlers when the service starts and unregisters them when the service stops. Add the service to the default runlevel and start it immediately:<br />
<br />
<pre><br />
rc-update add qemu-binfmt default<br />
service qemu-binfmt start<br />
</pre><br />
<br />
==Make the chroot folder==<br />
<br />
To keep it simple, we're just going to use the apk repositories specified on the host system. This guide assumes the <code>$CHROOT</code> environment variable holds the directory where you want to make the chroot. Make the chroot directory and the <code>etc/apk</code> subdirectory (which we'll copy the apk repositories file to):<br />
<br />
<pre><br />
mkdir -p $CHROOT/etc/apk/<br />
</pre><br />
<br />
Now copy the host's apk repositories into the chroot folder:<br />
<br />
<pre><br />
cp /etc/apk/repositories $CHROOT/etc/apk/<br />
</pre><br />
<br />
You'll also need to copy the resolv.conf file into the chroot so it can have internet access:<br />
<br />
<pre><br />
cp /etc/resolv.conf $CHROOT/etc/<br />
</pre><br />
<br />
==Install <code>alpine-base</code> into the chroot folder==<br />
<br />
The <code>alpine-base</code> meta package is all that's needed to have a fully working alpine system. The apk invocation used here has a few more options than what you might be used to:<br />
<br />
<pre><br />
apk add -p $CHROOT --initdb -U --arch x86_64 --allow-untrusted alpine-base<br />
</pre><br />
<br />
Here's what all the options do:<br />
*<code>-p $CHROOT</code>: Sets the root of the install to <code>$CHROOT</code> instead of <code>/</code><br />
*<code>--initdb</code>: Initialize a new package database.<br />
*<code>-U</code>: Alias for <code>--cache-max-age 1</code>. Basically means don't install from cache.<br />
*<code>--arch x86_64</code>: Install x86_64 packages instead of native packages. Replace this with whichever architecture you want to emulate instead (e.g. <code>--arch x86</code>).<br />
*<code>--allow-untrusted</code>: Install packages with untrusted signature or no signature. (This is needed since the keys for different architectures are different than what will be on your host. If you have the correct keys, you can copy them into the <code>$CHROOT/etc/apk/keys/</code> directory and remove this flag).<br />
<br />
==Mount the virtual file systems into the chroot==<br />
<br />
<pre><br />
mount -t proc proc $CHROOT/proc/<br />
mount -t sysfs sys $CHROOT/sys/<br />
mount -o bind /dev/ $CHROOT/dev/<br />
mount -o bind /dev/pts/ $CHROOT/dev/pts/<br />
mount -o bind /run $CHROOT/run/<br />
</pre><br />
<br />
==The exciting part: Enter the chroot==<br />
<br />
If you've followed all the steps, this part should be uneventful. The <code>chroot</code> invocation uses the special command of <code>ash -l</code> to run as a login shell and source <code>/etc/profile</code>:<br />
<br />
<pre><br />
chroot $CHROOT/ ash -l<br />
</pre><br />
<br />
==Troubleshooting==<br />
<br />
If you get a <code>ERROR: ${package_name}.post-install: script exited with error 127</code> while trying to add the alpine-base, that normally means that qemu binfmt_misc hasn't been setup properly. Check if the <code>qemu-$arch</code> package has been installed and see if the binfmt_misc service is running. You can also see if there is a <code>qemu-$arch</code> entry in <code>/proc/sys/fs/binfmt_misc/</code>.<br />
<br />
Programs that use [https://en.wikipedia.org/wiki/Netlink Netlink] (e.g. <code>ip addr</code>) don't seem to work properly since qemu doesn't emulate the Netlink protocol properly.<br />
<br />
==References==<br />
<br />
https://ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc/ (see the section titled <code>Emulating full ARM rootfs</code>)</div>Ktprogramshttps://wiki.alpinelinux.org/w/index.php?title=How_to_make_a_cross_architecture_chroot&diff=20195How to make a cross architecture chroot2021-10-14T05:25:26Z<p>Ktprograms: Created page with "=How to make a chroot to run a different architecture (e.g. x86 on arm)= If you have an arm computer, you might find that some software is only available for x86_64. One poss..."</p>
<hr />
<div>=How to make a chroot to run a different architecture (e.g. x86 on arm)=<br />
<br />
If you have an arm computer, you might find that some software is only available for x86_64. One possible solution is to have a full x86_64 virtual machine, but that has quite a lot of overhead from having to emulate the entire system. Fortunately, there is [https://qemu-project.gitlab.io/qemu/user/main.html QEMU User space emulation] which still uses the host kernel, so there is less overhead. This guide will show you how to make a chroot and enable transparent x86_64 binary execution using qemu and binfmt_misc.<br />
<br />
==Prerequisites==<br />
<br />
You should be familiar with the linux command line.<br />
This guide is written assuming you have alpine as the main install as well as putting alpine in the chroot.<br />
<br />
Also, the commands shown assume you have root privileges. Either use sudo as needed or su first.<br />
<br />
==Installing necessary software==<br />
<br />
First, [[Enable Community Repository | Enable the Community Repository]]. Next, install the qemu user mode binaries for the architectures you want to use, in this case x86_64 and i386:<br />
<br />
<pre><br />
apk add qemu-x86_64 qemu-i386<br />
</pre><br />
<br />
Please note there are the <code>qemu-system-*</code> packages, you don't want those since they are used for full virtual machine emulation.<br />
<br />
Then, curl my modified version of the qemu-binfmt script (originally from the [https://pkgs.alpinelinux.org/package/edge/community/aarch64/qemu-openrc qemu-openrc] package):<br />
<br />
<pre><br />
curl -o /etc/init.d/qemu-binfmt 'https://gist.githubusercontent.com/ktprograms/c8ea850abde717376ff7a6f83dbabb2f/raw/facb4ae367d3c7219949f33a566234427b0c2f54/qemu-binfmt'<br />
</pre><br />
<br />
I prefer to use this script instead of installing the qemu-openrc package since that adds a lot of unneeded dependencies. Right now this only supports x86_64 and i386 but I'll be adding all the architectures soon.<br />
<br />
Make the qemu-binfmt script executable:<br />
<br />
<pre><br />
chmod +x /etc/init.d/qemu-binfmt<br />
</pre><br />
<br />
==Enable the <code>qemu-binfmt</code> service and start it==<br />
<br />
The qemu-binfmt script is an OpenRC init script that registers the binfmt_misc handlers when the service starts and unregisters them when the service stops. Add the service to the default runlevel and start it immediately:<br />
<br />
<pre><br />
rc-update add qemu-binfmt default<br />
service qemu-binfmt start<br />
</pre><br />
<br />
==Make the chroot folder==<br />
<br />
To keep it simple, we're just going to use the apk repositories specified on the host system. This guide assumes the <code>$CHROOT</code> environment variable holds the directory where you want to make the chroot. Make the chroot directory and the <code>etc/apk</code> subdirectory (which we'll copy the apk repositories file to):<br />
<br />
<pre><br />
mkdir -p $CHROOT/etc/apk/<br />
</pre><br />
<br />
Now copy the host's apk repositories into the chroot folder:<br />
<br />
<pre><br />
cp /etc/apk/repositories $CHROOT/etc/apk/<br />
</pre><br />
<br />
You'll also need to copy the resolv.conf file into the chroot so it can have internet access:<br />
<br />
<pre><br />
cp /etc/resolv.conf $CHROOT/etc/<br />
</pre><br />
<br />
==Install <code>alpine-base</code> into the chroot folder==<br />
<br />
The <code>alpine-base</code> meta package is all that's needed to have a fully working alpine system. The apk invocation used here has a few more options than what you might be used to:<br />
<br />
<pre><br />
apk add -p $CHROOT --initdb -U --arch x86_64 --allow-untrusted alpine-base<br />
</pre><br />
<br />
Here's what all the options do:<br />
*<code>-p $CHROOT</code>: Sets the root of the install to <code>$CHROOT</code> instead of <code>/</code><br />
*<code>--initdb</code>: Initialize a new package database.<br />
*<code>-U</code>: Alias for <code>--cache-max-age 1</code>. Basically means don't install from cache.<br />
*<code>--arch x86_64</code>: Install x86_64 packages instead of native packages. Replace this with whichever architecture you want to emulate instead (e.g. <code>--arch x86</code>).<br />
*<code>--allow-untrusted</code>: Install packages with untrusted signature or no signature. (This is needed since the keys for different architectures are different than what will be on your host. If you have the correct keys, you can copy them into the <code>$CHROOT/etc/apk/keys/</code> directory and remove this flag).<br />
<br />
==Mount the virtual file systems into the chroot==<br />
<br />
<pre><br />
mount -t proc proc $CHROOT/proc/<br />
mount -t sysfs sys $CHROOT/sys/<br />
mount -o bind /dev/ $CHROOT/dev/<br />
mount -o bind /dev/pts/ $CHROOT/dev/pts/<br />
mount -o bind /run $CHROOT/run/<br />
</pre><br />
<br />
==The exciting part: Enter the chroot==<br />
<br />
If you've followed all the steps, this part should be uneventful. The <code>chroot</code> invocation uses the special command of <code>ash -l</code> to run as a login shell and source <code>/etc/profile</code>:<br />
<br />
<pre><br />
chroot $CHROOT/ ash -l<br />
</pre><br />
<br />
==Troubleshooting==<br />
<br />
If you get a <code>ERROR: ${package_name}.post-install: script exited with error 127</code> while trying to add the alpine-base, that normally means that qemu binfmt_misc hasn't been setup properly. Check if the <code>qemu-$arch</code> package has been installed and see if the binfmt_misc service is running. You can also see if there is a <code>qemu-$arch</code> entry in <code>/proc/sys/fs/binfmt_misc/</code>.<br />
<br />
Programs that use [https://en.wikipedia.org/wiki/Netlink Netlink] (e.g. <code>ip addr</code>) don't seem to work properly since qemu doesn't emulate the Netlink protocol properly.<br />
<br />
==References==<br />
<br />
https://ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc/ (see the section titled <code>Emulating full ARM rootfs</code>)</div>Ktprograms