https://wiki.archlinux.org/api.php?action=feedcontributions&user=Imranhaider&feedformat=atomArchWiki - User contributions [en]2024-03-29T10:47:35ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=ISCSI/LIO&diff=402168ISCSI/LIO2015-09-29T01:05:40Z<p>Imranhaider: /* Set Credentials */</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
[[zh-CN:ISCSI Target]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Initiator}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
With [[Wikipedia:iSCSI|iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''target''' and the importing entity is the '''[[iSCSI Initiator|initiator]]'''. There are different modules available to set up the target:<br />
* The [http://stgt.berlios.de/ SCSI Target Framework (STGT/TGT)] was the standard before linux 2.6.38.<br />
* The current standard is the [http://linux-iscsi.org/ LIO target].<br />
* The [http://iscsitarget.sourceforge.net/ iSCSI Enterprise Target (IET)] is an old implementation and [http://scst.sourceforge.net/ SCSI Target Subsystem (SCST)] is the successor of IET and was a possible candidate for kernel inclusion before the decision fell for LIO.<br />
<br />
== Setup with LIO Target ==<br />
LIO target is included in the kernel since 2.6.38. However, the iSCSI target fabric is included since linux 3.1.<br />
<br />
The important kernel modules are ''target_core_mod'' and ''iscsi_target_mod'', which should be in the kernel and loaded automatically.<br />
<br />
It is highly recommended to use the free branch versions of the packages: {{AUR|targetcli-fb}}, {{AUR|python-rtslib-fb}} and {{AUR|python-configshell-fb}}. The original {{AUR|targetcli}}{{Broken package link|{{aur-mirror|targetcli}}}} is also available but has a different way of saving the configuration using the deprecated ''lio-utils'' and depends on ''epydoc''.<br />
<br />
A systemd {{ic|target.service}} is included in {{AUR|python-rtslib-fb}} when you use the free branch and a {{ic|/etc/rc.d/target}} in {{AUR|lio-utils}}{{Broken package link|{{aur-mirror|lio-utils}}}} when you use the original ''targetcli'' or ''lio-utils'' directly.<br />
<br />
You start LIO target with {{bc|# systemctl start target}}<br />
This will load necessary modules, mount the configfs and load previously saved iscsi target configuration.<br />
<br />
With {{bc|# targetcli status}} you can show some information about the running configuration (only with the free branch).<br />
<br />
You might want to enable the lio target on boot with {{bc|# systemctl enable target}}<br />
<br />
You can use '''targetcli''' to create the whole configuration or you can alternatively use the '''lio utils''' tcm_* and lio_* directly (deprecated).<br />
<br />
=== Using targetcli ===<br />
The external manual is only available in the ''free branch''. [https://github.com/agrover/targetd targetd] is not in AUR yet, but this depends on the free branch.<br />
<br />
The config shell creates most names and numbers for you automatically, but you can also provide your own settings.<br />
At any point in the shell you can type {{ic|help}} in order to see what commands you can issue here.<br />
{{Tip|You can use tab-completion in this shell}}<br />
{{Tip|You can type {{ic|cd}} in this shell to view & select paths}}<br />
<br />
After starting the target (see above) you enter the configuration shell with {{bc|# targetcli}}<br />
In this shell you include a block device (here: {{ic|/dev/disk/by-id/md-name-nas:iscsi}}) to use with<br />
{{bc|/> cd backstores/block<br>/backstores/block> create md_block0 /dev/disk/by-id/md-name-nas:iscsi}}<br />
{{Note|You can use any block device, also raid and lvm devices. You can also use files when you go to fileio instead of block.}}<br />
<br />
You then create an iSCSI Qualified Name (iqn) and a target portal group (tpg) with {{bc|...> cd /iscsi<br>/iscsi> create}}<br />
{{Note|With appending an iqn of your choice to {{ic|create}} you can keep targetcli from automatically creating an iqn}}<br />
<br />
In order to tell LIO that your block device should get used as ''backstore'' for the target you issue<br />
{{Note|Remember that you can type {{ic|cd}} to select the path of your <iqn>/tpg1}}<br />
{{bc|.../tpg1> cd luns<br>.../tpg1/luns> create /backstores/block/md_block0}}<br />
<br />
Then you need to create a ''portal'', making a daemon listen for incoming connections:<br />
{{bc|.../luns/lun0> cd ../../portals<br>.../portals> create}}<br />
Targetcli will tell you the IP and port where LIO is listening for incoming connections (defaults to 0.0.0.0 (all)).<br />
You will need at least the IP for the clients. The port should be the standard port 3260.<br />
<br />
In order for a client/[[iSCSI Initiator|initiator]] to connect you need to include the iqn of the initiator in the target configuration:<br />
{{bc|...> cd ../../acls<br>.../acls> create iqn.2005-03.org.open-iscsi:SERIAL}}<br />
Instead of {{ic|iqn.2005-03.org.open-iscsi:SERIAL}} you use the iqn of an initiator.<br />
It can normally be found in {{ic|/etc/iscsi/initiatorname.iscsi}}.<br />
You have to do this for every initiator that needs to connect.<br />
Targetcli will automatically map the created lun to the newly created acl.<br />
{{Note|You can change the mapped luns and whether the access should be rw or ro. See {{ic|help create}} at this point in the targetcli shell.}}<br />
<br />
The last thing you have to do in targetcli when everything works is saving the configuration with:<br />
...> cd /<br />
/> saveconfig<br />
The will the configuration in {{ic|/etc/target/saveconfig.json}}.<br />
You can now safely start and stop {{ic|target.service}} without losing your configuration.<br />
{{Tip|You can give a filename as a parameter to {{ic|saveconfig}} and also clear a configuration with {{ic|clearconfig}}}}<br />
<br />
==== Authentication ====<br />
Authentication per CHAP is enabled per default for your targets.<br />
You can either setup passwords or disable this authentication.<br />
<br />
===== Disable Authentication =====<br />
Navigate targetcli to your target (i.e. /iscsi/iqn.../tpg1) and<br />
.../tpg1> set attribute authentication=0<br />
{{Warning|With this setting everybody that knows the iqn of one of your clients (initiators) can access the target. This is for testing or home purposes only.}}<br />
===== Set Credentials =====<br />
Navigate to a certain acl of your target (i.e. /iscsi/iqn.../tpg1/acls/iqn.../) and<br />
...> get auth<br />
will show you the current authentication credentials.<br />
...> set auth userid=<username in target><br />
...> set auth password=<password in target><br />
...> set auth mutual_userid=<username in initiator> (optional)<br />
...> set auth mutual_password=<password in initiator> (optional)<br />
<br />
The first two fields are the username and password of the target. The initiator will use this to log into the target. The last two fields (prefixed with "mutual_") are the username and password of the initiators (note that all initiators will have the same username and password). These two are optional parameters and it ensures that initiators will only accept connections from permitted targets.<br />
<br />
=== Using (plain) LIO utils ===<br />
You have to install {{AUR|lio-utils}}{{Broken package link|{{aur-mirror|lio-utils}}}} from [[AUR]] and the dependencies (python2).<br />
<br />
=== Tips & Tricks ===<br />
* With {{ic|targetcli sessions}} you can list the current open sessions. This command is included in the {{AUR|targetcli-fb}} package, but not in ''lio-utils'' or the original ''targetcli''.<br />
<br />
=== Upstream Documentation ===<br />
* [http://www.linux-iscsi.org/wiki/Targetcli targetcli]<br />
* [http://www.linux-iscsi.org/wiki/Lio-utils_HOWTO LIO utils]<br />
* You can also use {{ic|man targetcli}} when you installed the ''free branch'' version {{AUR|targetcli-fb}}.<br />
<br />
== Setup with SCSI Target Framework (STGT/TGT) ==<br />
You will need the Package {{AUR|tgt}} from [[AUR]].<br />
<br />
See: [[TGT iSCSI Target]]<br />
<br />
== Setup with iSCSI Enterprise Target (IET) ==<br />
You will need {{AUR|iscsitarget-kernel}}{{Broken package link|{{aur-mirror|iscsitarget-kernel}}}} and {{AUR|iscsitarget-usr}}{{Broken package link|{{aur-mirror|iscsitarget-usr}}}} from [[AUR]].<br />
<br />
=== Create the Target === <br />
Modify /etc/iet/ietd.conf accordingly<br />
<br />
==== Hard Drive Target ====<br />
Target iqn.2010-06.ServerName:desc<br />
Lun 0 Path=/dev/sdX,Type=blockio<br />
<br />
==== File based Target ====<br />
Use "dd" to create a file of the required size, this example is 10GB.<br />
<br />
dd if=/dev/zero of=/root/os.img bs=1G count=10<br />
<br />
Target iqn.2010-06.ServerName:desc<br />
Lun 0 Path=/root/os.img,Type=fileio<br />
<br />
=== Start server services ===<br />
{{Out of date|Mentions rc.d scripts and rc.conf.}}<br />
rc.d start iscsi-target<br />
<br />
Also you can "iscsi-target" to DAEMONS in /etc/rc.conf so that it starts up during boot.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.<br />
* [[Persistent block device naming]] in order to use the correct block device for a target</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=402060Open-iSCSI2015-09-28T03:45:23Z<p>Imranhaider: /* Start the Service */</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
[[zh-CN:ISCSI initiator]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
== Overview ==<br />
The following diagram shows how the Components work together. A more detailed version can be found here: [http://www.open-iscsi.org/docs/open-iscsi-0.jpg Open-iSCSI modules]<br />
{{bc|<nowiki><br />
+-------------------------------------------------------+ <br />
| Targets & Sessions configuration Database (DBM based) | <br />
+-------------------------------------------------------+ <br />
<br />
+--------------------------+ +----------------------------------+ <br />
| iscsiadm | | iscsid: iSCSI daemon | <br />
| | | | <br />
| * Command line tool |<--->| * Implements Session management | <br />
| * Manages database of | | * Communicates with iscsiadm | <br />
| sessions and targets | | and iscsi kernel modules | <br />
+--------------------------+ +---------------+------------------+ <br />
| <br />
User space | <br />
- - - - - - - - - - - - - - - - - - - - - - - - - | - - - - - - - - - -<br />
Kernel v <br />
+-----------------------------------------------------------+ <br />
| kernel modules: scsi_transport_iscsi, iscsi_tcp, libiscsi | <br />
+-----------------------------------------------------------+ <br />
</nowiki>}}<br />
<br />
From the Open-iSCSI [http://www.open-iscsi.org/docs/README README]:<br />
<br />
Persistent configuration is implemented as a DBM database, which contains two tables:<br />
* Discovery table (/etc/iscsi/send_targets)<br />
* Node table (/etc/iscsi/nodes)<br />
<br />
== Configuration ==<br />
=== Start the Service ===<br />
{{ic|iscsid}} is managed by a systemd Unit.<br />
<br />
Start {{ic|open-iscsi.service}} [[systemd#Using units|using systemd]]. <br />
<br />
If the SCSI target requires authentication by the initiator, the configuration file /etc/iscsi/iscsid.conf may need<br />
to be updated.<br />
<br />
The following parameters are used for authenticating a login session of an initiator to a target and for the target<br />
to establish a session back to the initiator<br />
<br />
node.session.auth.authmethod = CHAP<br />
node.session.auth.username = <username in target><br />
node.session.auth.password = <password in target><br />
node.session.auth.username_in = <username in initiator><br />
node.session.auth.password_in = <password in initiator><br />
<br />
The following parameters are used for authenticating a discovery session of an initiator to a target and for the<br />
target to establish a session back to the initiator.<br />
<br />
discovery.sendtargets.auth.authmethod = CHAP<br />
discovery.sendtargets.auth.username = <username in target><br />
discovery.sendtargets.auth.password = <password in target><br />
discovery.sendtargets.auth.username_in = <username in initiator><br />
discovery.sendtargets.auth.password_in = <password in initiator><br />
<br />
{{Warning|No two passwords may be the same. This means that you need four unique passwords in the configuration above. }}<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips & Troubleshooting ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
Many of the {{ic|iscsiadm}} operations require that the iSCSI daemon {{ic|iscsid}} is running. To verify that this is the case, <br />
[[systemd#Using units|check the status]] of the {{ic|open-iscsi.service}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=GitLab&diff=330467GitLab2014-08-16T01:17:50Z<p>Imranhaider: set access control on database.yml</p>
<hr />
<div>[[Category:Version Control System]]<br />
{{Related articles start}}<br />
{{Related|Gitolite}}<br />
{{Related|Ruby on Rails}}<br />
{{Related articles end}}<br />
<br />
[http://gitlab.org/ Gitlab] is a free git repository management application based on [[Ruby on Rails]]. It is distributed under the MIT License and its source code can be found on [https://github.com/gitlabhq/gitlabhq Github]. It is a very active project with a monthly release cycle and ideal for businesses that want to keep their code private. Consider it as a self hosted Github but open source. You can try a demo [http://demo.gitlabhq.com/ here].<br />
<br />
== Installation ==<br />
{{Note|If you want to use rvm be sure to check out [[Gitlab#Running GitLab with rvm]] before starting with the installation}}<br />
<br />
{{note|This guide covers installing and configuring GitLab without HTTPS/SSL at first, just to get GitLab up and running. After getting GitLab up and running, see [[#Advanced Configuration]] to set up SSL.}}<br />
<br />
Installing {{AUR|gitlab}} from the [[AUR]] instead of manually has the added benefit that lots of steps have been taken care of for you (e.g. permissions and ownership for files, etc). <br />
<br />
Make sure you perform a system upgrade ({{ic|pacman -Syu}}) before installing gitlab from AUR and that you have installed the {{ic|base-devel}} group, or you may face problems installing gitlab because [https://wiki.archlinux.org/index.php/Makepkg#Usage base-devel packages are not required to be listed as dependencies in PKGBUILD files].<br />
<br />
Also before installing the {{AUR|gitlab}} package from the [[AUR]], you need to choose a database backend if you're planning to host GitLab it on the same machine as the database:<br />
<br />
* Use [[pacman|Pacman]] to install {{Pkg|mariadb}} and {{Pkg|libmariadbclient}} from the [[official repositories]] and start the [[daemon]]<br />
* or install {{Pkg|postgresql}} and {{Pkg|libpqxx}}. Read [[PostgreSQL#Installing_PostgreSQL]] to set it up and start the [[daemon]]. <br />
<br />
In order to receive mail notifications, make sure to install a mail server. By default, Archlinux does not ship with one. The recommended mail server is [[postfix]], but you can use others such as [[SSMTP]], [[msmtp]], [[sendmail]], [https://wiki.archlinux.org/index.php/Category:Mail_Server etc].<br />
<br />
== Configuration ==<br />
<br />
=== Notes Before Configuring ===<br />
The gitlab package from AUR organizes GitLab's files in a manner that more closely follows standard linux conventions rather than installing everything in {{ic|/home/git}} as you are told to do by [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab's official install guide]. <br />
<br />
<br />
After you've installed gitlab from AUR, the config file {{ic|/etc/webapps/gitlab/shell.yml}} corresponds to the file {{ic|/home/git/gitlab-shell/config.yml}} that is mentioned in [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md#4-gitlab-shell GitLab's official install guide when installing gitlab-shell]. The config file {{ic|/etc/webapps/gitlab/gitlab.yml}} corresponds to the file {{ic|/home/git/gitlab/config/gitlab.yml}} that is mentioned in [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md#configure-it GitLab's official install guide when configuring GitLab].<br />
<br />
<br />
Another key difference between gitlab from AUR and the GitLab install guide is that GitLab from AUR uses the {{ic|gitlab}} user with {{ic|/var/lib/gitlab}} as the home folder instead of the {{ic|git}} user with {{ic|/home/git}} as the home folder. This keeps the {{ic|/home}} area clean so it contains only real user homes.<br />
<br />
{{tip|If you are familiar with the [[Arch Build System]] you can edit the PKGBUILD and relevant files to change gitlab's home directory to a place of your liking.}}<br />
<br />
===Basic configuration===<br />
Open up {{ic|/etc/webapps/gitlab/shell.yml}} and set {{ic|gitlab_url:}} to the url where you intend to host GitLab (note the 'http://' and trailing slash). For example, if you will host GitLab at 'yourdomain.com', then it'd look like this:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/shell.yml|<br />
# GitLab user. git by default<br />
user: gitlab<br />
<br />
# Url to gitlab instance. Used for api calls. Should end with a slash.<br />
gitlab_url: "<nowiki>http://yourdomain.com/</nowiki>" # <<-- right here<br />
<br />
http_settings:<br />
# user: someone<br />
# password: somepass<br />
...<br />
}}<br />
<br />
<br />
Open up {{ic|/etc/webapps/gitlab/gitlab.yml}} and edit where needed. In the {{ic|gitlab:}} section set {{ic|host:}} (replacing {{ic|localhost}}) to 'yourdomain.com', your fully qualified domin name (no 'http://' or trailing slash). {{ic|port:}} can be confusing. This is not the port that the gitlab server (unicorn) runs on; it's the port that users will initially access through in their browser. Basically, if you intend for users to visit 'yourdomain.com' in their browser, without appending a port number to the domain name, leave {{ic|port:}} as {{ic|80}}. If you intend your users to type something like 'yourdomain.com:3425' into their browsers, then you'd set {{ic|port:}} to {{ic|3425}} (you'll also have to configure your server (apache, nginx, etc) to listen on that port). Those are the minimal changes needed for a working GitLab install. The adventurous may read on in the comment and customize as needed. For example:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/gitlab.yml|<br />
...<br />
## GitLab settings<br />
gitlab:<br />
## Web server settings<br />
host: yourdomain.com<br />
port: 80<br />
https: false<br />
...<br />
}}<br />
<br />
=== Further configuration ===<br />
<br />
==== Database backend ====<br />
A Database backend will be required before Gitlab can be run. Currently GitLab supports [[MariaDB]] and [[PostgreSQL]]. By default, GitLab assumes you will use MySQL. Extra work is needed if you plan to use PostgreSQL.<br />
<br />
{{note|Don't forget to replace {{ic|your_username_here}} and {{ic|your_password_here}} with your chosen values in the following examples.}}<br />
<br />
==== MariaDB ====<br />
To set up MySQL (MariaDB) you need to create a database called {{ic|gitlabhq_production}} along with a user who has full priviledges to the database. You might do it via command line as in the following example.<br />
<br />
{{bc|mysql -u root -p}}<br />
<br />
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production`;<br />
mysql> CREATE USER 'your_username_here'@'localhost' IDENTIFIED BY 'your_password_here';<br />
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'your_username_here'@'localhost';<br />
mysql> \q<br />
<br />
Now try connecting to the new database with the new user to verify you did it correctly:<br />
<br />
{{bc|mysql -u your_username_here -p -D gitlabhq_production}}<br />
<br />
Next you'll need to open up {{ic|/etc/webapps/gitlab/database.yml}} and set {{ic|username:}} and {{ic|password:}} for the {{ic|gitlabhq_production}} database to {{ic|your_username_here}} and {{ic|your_password_here}}, respectively. You need not worry about the info for the {{ic|gitlabhq_development}} and {{ic|gitlan_test}} databases, as those are not required for our purposes (unless you're feeling adventurous at your own risk). For example:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/database.yml|<br />
#<br />
# PRODUCTION<br />
#<br />
production:<br />
adapter: mysql2<br />
encoding: utf8<br />
reconnect: false<br />
database: gitlabhq_production<br />
pool: 10<br />
username: your_username_here<br />
password: "your_password_here"<br />
# host: localhost<br />
# socket: /tmp/mysql.sock<br />
...<br />
}}<br />
<br />
That's all for MySQL configuration. You just need to make sure it's not readable by the average user. Execute {{bc|chmod 600 /etc/webapps/gitlab/database.yml}} and then {{bc|chown gitlab:gitlab /etc/webapps/gitlab/database.yml}} to make sure only the processes running under the {{ic|gitlab}} user can access it.<br />
<br />
For more info and other ways to create/manage MySQL databases, see the [https://mariadb.org/docs/ MariaDB documentation], the [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab official (generic) install guide], and [[phpMyAdmin]].<br />
<br />
==== PostgreSQL ====<br />
Login to PostgreSQL and create the {{ic|gitlabhq_production}} database with along with it's user. Remember to change {{ic|your_username_here}} and {{ic|your_password_here}} to the real values:<br />
<br />
{{bc|psql -d template1}}<br />
<br />
template1=# CREATE USER your_username_here WITH PASSWORD 'your_password_here';<br />
template1=# CREATE DATABASE gitlabhq_production OWNER your_username_here;<br />
template1=# \q<br />
<br />
Try connecting to the new database with the new user to verify it works:<br />
<br />
{{bc|psql -d gitlabhq_production}}<br />
<br />
Copy the PostgreSQL template file before configuring it (overwriting the default MySQL configuration file):<br />
<br />
# cp /usr/share/doc/gitlab/database.yml.postgresql /etc/webapps/gitlab/database.yml<br />
<br />
Open up the new {{ic|/etc/webapps/gitlab/database.yml}} and set the values for {{ic|username:}} and {{ic|password:}}. For example:<br />
<br />
{{hc|Snippet from the new /etc/webapps/gitlab/database.yml|<br />
#<br />
# PRODUCTION<br />
#<br />
production:<br />
adapter: postgresql<br />
encoding: unicode<br />
database: gitlabhq_production<br />
pool: 10<br />
username: your_username_here<br />
password: "your_password_here"<br />
# host: localhost<br />
# port: 5432 <br />
# socket: /tmp/postgresql.sock<br />
...<br />
}}<br />
<br />
For our purposes (unless you know what you're doing), you don't need to worry about configuring the other databases listed in {{ic|/etc/webapps/gitlab/database.yml}}. We only need to set up the production database to get GitLab working.<br />
<br />
Finally, open up {{ic|/usr/lib/systemd/system/gitlab.target}} change all instances of {{ic|mysql.service}} to {{ic|postgresql.service}}. For example:<br />
<br />
{{Accuracy|See [[systemd#Editing provided unit files]] for the correct way.}}<br />
<br />
{{hc|Snippet from /usr/lib/systemd/system/gitlab.target|<br />
...<br />
[Unit]<nowiki><br />
Description=GitLab - Self Hosted Git Management<br />
Requires=redis.service postgresql.service<br />
After=redis.service postgresql.service syslog.target network.target<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki><br />
}}<br />
<br />
<br />
==== Firewall ====<br />
<br />
If you want to give direct access to your Gitlab isntallation through a [[iptables]] firewall you have to the following ACCEPT rule. Change "your_gitlab_port" to your chosen port from above (here we give access to all clients within 192.168.1.0/24 network):<br />
<br />
# iptables -A tcp_inbound -p TCP -s 192.168.1.0/24 --destination-port your_gitlab_port -j ACCEPT <br />
<br />
If you are behind a router, don't forget to forward this port to the running Gitlab server host, too.<br />
<br />
==== Satellites access ====<br />
<br />
Satellites access should be "drwxr-x---":<br />
<br />
# chmod 750 /var/lib/gitlab/satellites<br />
<br />
==== Initialize Gitlab database ====<br />
<br />
Start the Redis server before we create the database:<br />
<br />
# systemctl start redis<br />
# systemctl enable redis<br />
<br />
Then, initialize the database and activate advanced features: <br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab bundle exec rake gitlab:setup RAILS_ENV=production<br />
<br />
Finally, Compile assets.(If you didn't do it,you won't receive data on user/sign_in pages)<br />
<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab -H bundle exec rake assets:precompile RAILS_ENV=production<br />
<br />
==== Configure Git User ====<br />
<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab -H git config --global user.name "GitLab"<br />
# sudo -u gitlab -H git config --global user.email "example@example.com"<br />
<br />
This must match the {{ic|user}} and {{ic|email_from}} defined in {{ic|/usr/share/webapps/gitlab/config/gitlab.yml}}<br />
<br />
==== Adjust modifier bits ====<br />
(The gitlab check won't pass if the user and group ownership isn't configured properly)<br />
<br />
# chmod -R ug+rwX,o-rwx /path/to/repos/<br />
# chmod -R ug-s /path/to/repos<br />
# find /path/to/repos/ -type d -print0 | xargs -O chmod g+s<br />
<br />
== Start and test GitLab ==<br />
<br />
With the following commands we check if the steps we followed so far are configured properly. <br />
<br />
$ cd /usr/share/webapps/gitlab<br />
$ sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production<br />
$ sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production<br />
<br />
{{note|These gitlab:env:info and gitlab:check commands will show a fatal error related to git. This is OK.}}<br />
<br />
{{hc|Example output of sudo -u gitlab bundle exec rake gitlab:env:info <nowiki>RAILS_ENV=production</nowiki>|<br />
fatal: Not a git repository (or any of the parent directories): .git<br />
<br />
System information<br />
System: Arch Linux<br />
Current User: git<br />
Using RVM: yes<br />
RVM Version: 1.20.3<br />
Ruby Version: 2.0.0p0<br />
Gem Version: 2.0.0<br />
Bundler Version:1.3.5<br />
Rake Version: 10.0.4<br />
<br />
GitLab information<br />
Version: 5.2.0.pre<br />
Revision: <br />
Directory: /home/git/gitlab<br />
DB Adapter: mysql2<br />
URL: http://gitlab.arch<br />
HTTP Clone URL: http://gitlab.arch/some-project.git<br />
SSH Clone URL: git@gitlab.arch:some-project.git<br />
Using LDAP: no<br />
Using Omniauth: no<br />
<br />
GitLab Shell<br />
Version: 1.4.0<br />
Repositories: /home/git/repositories/<br />
Hooks: /home/git/gitlab-shell/hooks/<br />
Git: /usr/bin/git<br />
}}<br />
<br />
{{Note| {{ic|gitlab:check}} will complain about missing initscripts. Don't worry, we will use ArchLinux's [[systemd]] to manage server start during boot (which GitLab does not recognize).}}<br />
<br />
{{hc|Example output of sudo -u gitlab bundle exec rake gitlab:check <nowiki>RAILS_ENV=production</nowiki>|<br />
<nowiki>fatal: Not a git repository (or any of the parent directories): .git<br />
Checking Environment ...<br />
<br />
Git configured for gitlab user? ... yes<br />
Has python2? ... yes<br />
python2 is supported version? ... yes<br />
<br />
Checking Environment ... Finished<br />
<br />
Checking GitLab Shell ...<br />
<br />
GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)<br />
Repo base directory exists? ... yes<br />
Repo base directory is a symlink? ... no<br />
Repo base owned by gitlab:gitlab? ... yes<br />
Repo base access is drwxrws---? ... yes<br />
update hook up-to-date? ... yes<br />
update hooks in repos are links: ... can't check, you have no projects<br />
Running /srv/gitlab/gitlab-shell/bin/check<br />
Check GitLab API access: OK<br />
Check directories and files:<br />
/srv/gitlab/repositories: OK<br />
/srv/gitlab/.ssh/authorized_keys: OK<br />
Test redis-cli executable: redis-cli 2.8.4<br />
Send ping to redis server: PONG<br />
gitlab-shell self-check successful<br />
<br />
Checking GitLab Shell ... Finished<br />
<br />
Checking Sidekiq ...<br />
<br />
Running? ... yes<br />
Number of Sidekiq processes ... 1<br />
<br />
Checking Sidekiq ... Finished<br />
<br />
Checking LDAP ...<br />
<br />
LDAP is disabled in config/gitlab.yml<br />
<br />
Checking LDAP ... Finished<br />
<br />
Checking GitLab ...<br />
<br />
Database config exists? ... yes<br />
Database is SQLite ... no<br />
All migrations up? ... fatal: Not a git repository (or any of the parent directories): .git<br />
yes<br />
GitLab config exists? ... yes<br />
GitLab config outdated? ... no<br />
Log directory writable? ... yes<br />
Tmp directory writable? ... yes<br />
Init script exists? ... no<br />
Try fixing it:<br />
Install the init script<br />
For more information see:<br />
doc/install/installation.md in section "Install Init Script"<br />
Please fix the error above and rerun the checks.<br />
Init script up-to-date? ... can't check because of previous errors<br />
projects have namespace: ... can't check, you have no projects<br />
Projects have satellites? ... can't check, you have no projects<br />
Redis version >= 2.0.0? ... yes<br />
Your git bin path is "/usr/bin/git"<br />
Git version >= 1.7.10 ? ... yes (1.8.5)<br />
<br />
Checking GitLab ... Finished<br />
</nowiki><br />
}}<br />
<br />
Make systemd see your new daemon unit files:<br />
<br />
$ systemctl daemon-reload<br />
<br />
After starting the database backend (in this case MySQL), we can start Gitlab with its webserver (Unicorn):<br />
<br />
$ systemctl start redis mysqld gitlab-sidekiq gitlab-unicorn<br />
<br />
Replace {{ic|mysqld}} with {{ic|postgresql}} in the above command if you're using PostgreSQL.<br />
<br />
To automatically launch GitLab at startup, run:<br />
<br />
$ systemctl enable gitlab.target gitlab-sidekiq gitlab-unicorn<br />
<br />
Now test your Gitlab instance by visiting http://localhost:8080 or http://yourdomain.com and login with the default credentials:<br />
username: {{ic|admin@local.host}}<br />
password: {{ic|5iveL!fe}}<br />
<br />
{{note|1=If your browser runs not on the machine where gitlab is running, modify your unicorn.rb in order to be able to test your setup without the use of a proxy. The corresponding line looks like this:<br />
<pre>listen "127.0.0.1:8080, :tcp_nopush => true</pre><br />
you should replace that with:<br />
<pre>listen "examle.yourhost.com:8080, :tcp_nopush => true</pre><br />
}}<br />
<br />
GitLab should now be up and running.<br />
<br />
== Advanced Configuration ==<br />
<br />
=== HTTPS/SSL ===<br />
<br />
==== Change GitLab configs ====<br />
Modify {{ic|/etc/webapps/gitlab/shell.yml}} so the url to your GitLab site starts with {{ic|https://}}.<br />
Modify {{ic|/etc/webapps/gitlab/gitlab.yml}} so that {{ic|https:}} setting is set to {{ic|true}}.<br />
<br />
==== Configure HTTPS server of choice====<br />
<br />
===== Apache =====<br />
{{stub|info needed}}<br />
<br />
===== Node.js =====<br />
You can easily set up an http proxy on port 443 to proxy traffic to the GitLab application on port 8080 using http-master for Node.js. After you've creates your domain's OpenSSL keys and have gotten you CA certificate (or self signed it), then go to https://github.com/CodeCharmLtd/http-master to learn how easy it is to proxy requests to GitLab using HTTPS. http-master is built on top of [https://github.com/nodejitsu/node-http-proxy node-http-proxy].<br />
<br />
===Web server configuration===<br />
If you want to integrate Gitlab into a running web server instead of using its build-in http server Unicorn, then follow these instructions.<br />
<br />
====Nginx and unicorn====<br />
<br />
[[pacman|Install]] {{Pkg|nginx}} from the [[official repositories]].<br />
<br />
Nginx gitlab configuration needs to be copied to nginx configuration directories.<br />
<br />
If you installed GitLab from AUR, do:<br />
<br />
# cp /usr/share/webapps/gitlab/lib/support/nginx/gitlab /etc/nginx/sites-available<br />
<br />
Then edit /usr/share/webapps/gitlab/lib/support/nginx/gitlab and change all path starting from /home/git/gitlab to /usr/share/webapps/gitlab (there are two occurences).<br />
<br />
If you did not use AUR, you need to copy {{ic|/lib/support/nginx/gitlab}} to {{ic|/etc/nginx/sites-available/}}.<br />
<br />
Run these commands to setup nginx:<br />
<br />
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab<br />
<br />
Edit {{ic|/etc/nginx/sites-enabled/gitlab}} and change YOUR_SERVER_IP and YOUR_SERVER_FQDN to the IP address and fully-qualified domain name of the host serving Gitlab.<br />
<br />
Make sure the following line exists at the end of the {{ic|http}} block in {{ic|/etc/nginx/nginx.conf}}:<br />
<br />
# include sites-enabled/*;<br />
<br />
Restart gitlab.target, resque.service and nginx.<br />
<br />
====Apache and unicorn====<br />
<br />
[[pacman|Install]] {{Pkg|apache}} from the [[official repositories]]. <br />
<br />
=====Configure Unicorn=====<br />
<br />
{{Note|If the default path is not {{ic|/home/git}} for your installation, change the below path accordingly}}<br />
<br />
As the official installation guide instructs, copy the unicorn configuration file:<br />
# sudo -u git -H cp /home/git/gitlab/config/unicorn.rb.example /home/git/gitlab/config/unicorn.rb<br />
<br />
Now edit {{ic|config/unicorn.rb}} and add a listening port by uncommenting the following line:<br />
listen "127.0.0.1:8080"<br />
<br />
{{Tip| You can set a custom port if you want. Just remember to also include it in Apache's virtual host. See below.}}<br />
<br />
=====Create a virtual host for Gitlab=====<br />
<br />
Create a configuration file for Gitlab’s virtual host and insert the lines below adjusted accordingly. For the ssl section see [[LAMP#SSL]]. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the BalanceMember line.<br />
<br />
You can use these [https://gitlab.com/gitlab-org/gitlab-recipes/blob/079f70dd2c091434a8dd04ed5b1a0d0e937cd361/web-server/apache/gitlab-ssl-apache2.4.conf examples] to get you started.<br />
<br />
=====Enable host and start unicorn=====<br />
<br />
Enable your Gitlab virtual host and reload [[Apache]]:<br />
{{hc|/etc/httpd/conf/httpd.conf| Include /etc/httpd/conf/extra/gitlab.conf}}<br />
<br />
Finally start unicorn:<br />
<br />
# systemctl start gitlab-unicorn<br />
<br />
=== Redis ===<br />
Using a Redis setup different from default (e.g. different address, port, unix socket) requires the environment variable ''REDIS_URL'' to be set accordingly for unicorn. This can be achieved by extending the systemd service file. Create a file ''/etc/systemd/system/gitlab-unicorn.service.d/redis.conf'' that injects the ''REDIS_URL'' environment variable:<br />
[Service]<br />
Environment=REDIS_URL=unix:///run/gitlab/redis.sock<br />
<br />
==Useful Tips==<br />
<br />
===Fix Rake Warning===<br />
When running rake tasks for the gitlab project, this error will occur: {{ic|fatal: Not a git repository (or any of the parent directories): .git}}. This is a bug in bundler, and it can be safely ignored. However, if you want to git rid of the error, the following method can be used:<br />
<br />
{{bc|1=<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab git init<br />
# sudo -u gitlab git commit -m "initial commit" --allow-empty<br />
}}<br />
<br />
===Hook into /var===<br />
{{bc|1=<br />
# mkdir -m700 /var/log/gitlab /var/tmp/gitlab<br />
# chown gitlab:gitlab /var/log/gitlab /var/tmp/gitlab<br />
# sudo -u gitlab -i<br />
# cd ~/gitlab<br />
# d=log; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
# d=tmp; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
}}<br />
<br />
===Hidden options===<br />
Go to Gitlab's home directory:<br />
# cd /usr/share/webapps/gitlab<br />
<br />
and run:<br />
{{hc|<nowiki># rake -T | grep gitlab</nowiki>|<nowiki><br />
rake gitlab:app:check # GITLAB | Check the configuration of the GitLab Rails app<br />
rake gitlab:backup:create # GITLAB | Create a backup of the GitLab system<br />
rake gitlab:backup:restore # GITLAB | Restore a previously created backup<br />
rake gitlab:check # GITLAB | Check the configuration of GitLab and its environment<br />
rake gitlab:cleanup:block_removed_ldap_users # GITLAB | Cleanup | Block users that have been removed in LDAP<br />
rake gitlab:cleanup:dirs # GITLAB | Cleanup | Clean namespaces<br />
rake gitlab:cleanup:repos # GITLAB | Cleanup | Clean repositories<br />
rake gitlab:env:check # GITLAB | Check the configuration of the environment<br />
rake gitlab:env:info # GITLAB | Show information about GitLab and its environment<br />
rake gitlab:generate_docs # GITLAB | Generate sdocs for project<br />
rake gitlab:gitlab_shell:check # GITLAB | Check the configuration of GitLab Shell<br />
rake gitlab:import:all_users_to_all_groups # GITLAB | Add all users to all groups (admin users are added as owners)<br />
rake gitlab:import:all_users_to_all_projects # GITLAB | Add all users to all projects (admin users are added as masters)<br />
rake gitlab:import:repos # GITLAB | Import bare repositories from gitlab_shell -> repos_path into GitLab project instance<br />
rake gitlab:import:user_to_groups[email] # GITLAB | Add a specific user to all groups (as a developer)<br />
rake gitlab:import:user_to_projects[email] # GITLAB | Add a specific user to all projects (as a developer)<br />
rake gitlab:satellites:create # GITLAB | Create satellite repos<br />
rake gitlab:setup # GITLAB | Setup production application<br />
rake gitlab:shell:build_missing_projects # GITLAB | Build missing projects<br />
rake gitlab:shell:install[tag,repo] # GITLAB | Install or upgrade gitlab-shell<br />
rake gitlab:shell:setup # GITLAB | Setup gitlab-shell<br />
rake gitlab:sidekiq:check # GITLAB | Check the configuration of Sidekiq<br />
rake gitlab:test # GITLAB | Run all tests<br />
rake gitlab:web_hook:add # GITLAB | Adds a web hook to the projects<br />
rake gitlab:web_hook:list # GITLAB | List web hooks<br />
rake gitlab:web_hook:rm # GITLAB | Remove a web hook from the projects<br />
rake setup # GITLAB | Setup gitlab db<br />
</nowiki>}}<br />
<br />
===Backup and restore===<br />
<br />
Create a backup of the gitlab system:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create<br />
<br />
Restore the previously created backup file {{ic|/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar}}:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740<br />
<br />
{{Note| Backup folder is set in {{ic|config/gitlab.yml}}. GitLab backup and restore is documented [https://github.com/gitlabhq/gitlabhq/blob/master/doc/raketasks/backup_restore.md here].}}<br />
<br />
===Migrate from sqlite to mysql===<br />
<br />
Get latest code as described in [[#Update_Gitlab]].<br />
Save data.<br />
# cd /home/gitlab/gitlab<br />
# sudo -u gitlab bundle exec rake db:data:dump RAILS_ENV=production<br />
<br />
Follow [[#Mysql]] instructions and then setup the database.<br />
# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production<br />
<br />
Finally restore old data.<br />
# sudo -u gitlab bundle exec rake db:data:load RAILS_ENV=production<br />
<br />
===Running GitLab with rvm===<br />
<br />
To run gitlab with rvm first you have to set up an rvm:<br />
<br />
curl -L https://get.rvm.io | bash -s stable --ruby=1.9.3<br />
<br />
{{Note|Version 1.9.3 is currently recommended to avoid some compatibility issues.}}<br />
<br />
For the complete installation you will want to be the final user (e.g. {{ic|git}}) so make sure to switch to this user and activate your rvm:<br />
<br />
su - git<br />
source "$HOME/.rvm/scripts/rvm"<br />
<br />
Then continue with the installation instructions from above. However, the systemd scripts will not work this way, because the environment for the rvm is not activated. The recommendation here is to create to separate shell scripts for {{ic|puma}} and {{ic|sidekiq}} to activate the environment and then start the service:<br />
<br />
{{hc|gitlab.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
RAILS_ENV=production bundle exec puma -C "/home/git/gitlab/config/puma.rb"</nowiki><br />
}}<br />
<br />
{{hc|sidekiq.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
case $1 in<br />
start)<br />
bundle exec rake sidekiq:start RAILS_ENV=production<br />
;;<br />
stop)<br />
bundle exec rake sidekiq:stop RAILS_ENV=production<br />
;;<br />
*)<br />
echo "Usage $0 {start|stop}"<br />
esac<br />
</nowiki>}}<br />
<br />
Then modify the above systemd files so they use these scripts. Modify the given lines:<br />
<br />
{{hc|gitlab.service|<nowiki><br />
ExecStart=/home/git/bin/gitlab.sh<br />
</nowiki>}}<br />
{{hc|sidekiq.service|<nowiki><br />
ExecStart=/home/git/bin/sidekiq.sh start<br />
ExecStop=/home/git/bin/sidekiq.sh stop<br />
</nowiki>}}<br />
<br />
==Troubleshooting==<br />
<br />
Sometimes things may not work as expected. Be sure to visit the [https://github.com/gitlabhq/gitlab-public-wiki/wiki/Trouble-Shooting-Guide Trouble Shooting Guide].<br />
<br />
=== HTTPS is not green (gravatar not using https) ===<br />
Redis caches gravatar images, so if you've visited your GitLab with http, then enabled https, gravatar will load up the non-secure images. You can clear the cache by doing<br />
<br />
cd /usr/share/webapps/gitlab; bundle exec rake cache:clear<br />
<br />
as the gitlab user.<br />
<br />
==See also==<br />
*[https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md Official Documentation]<br />
*[https://gitlab.com/gitlab-org/gitlab-recipes Gitlab recipes with further documentation on running it with several webservers]</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=GitLab&diff=329744GitLab2014-08-10T16:45:52Z<p>Imranhaider: nginx.conf needs to include sites-enabled</p>
<hr />
<div>[[Category:Version Control System]]<br />
{{Related articles start}}<br />
{{Related|Gitolite}}<br />
{{Related|Ruby on Rails}}<br />
{{Related articles end}}<br />
<br />
[http://gitlab.org/ Gitlab] is a free git repository management application based on [[Ruby on Rails]]. It is distributed under the MIT License and its source code can be found on [https://github.com/gitlabhq/gitlabhq Github]. It is a very active project with a monthly release cycle and ideal for businesses that want to keep their code private. Consider it as a self hosted Github but open source. You can try a demo [http://demo.gitlabhq.com/ here].<br />
<br />
== Installation ==<br />
{{Note|If you want to use rvm be sure to check out [[Gitlab#Running GitLab with rvm]] before starting with the installation}}<br />
<br />
{{note|This guide covers installing and configuring GitLab without HTTPS/SSL at first, just to get GitLab up and running. After getting GitLab up and running, see [[#Advanced Configuration]] to set up SSL.}}<br />
<br />
Installing {{AUR|gitlab}} from the [[AUR]] instead of manually has the added benefit that lots of steps have been taken care of for you (e.g. permissions and ownership for files, etc). <br />
<br />
Make sure you perform a system upgrade ({{ic|pacman -Syu}}) before installing gitlab from AUR and that you have installed the {{ic|base-devel}} group, or you may face problems installing gitlab because [https://wiki.archlinux.org/index.php/Makepkg#Usage base-devel packages are not required to be listed as dependencies in PKGBUILD files].<br />
<br />
Also before installing the {{AUR|gitlab}} package from the [[AUR]], you need to choose a database backend if you're planning to host GitLab it on the same machine as the database:<br />
<br />
* Use [[pacman|Pacman]] to install {{Pkg|mariadb}} and {{Pkg|libmariadbclient}} from the [[official repositories]] and start the [[daemon]]<br />
* or install {{Pkg|postgresql}} and {{Pkg|libpqxx}}. Read [[PostgreSQL#Installing_PostgreSQL]] to set it up and start the [[daemon]]. <br />
<br />
In order to receive mail notifications, make sure to install a mail server. By default, Archlinux does not ship with one. The recommended mail server is [[postfix]], but you can use others such as [[SSMTP]], [[msmtp]], [[sendmail]], [https://wiki.archlinux.org/index.php/Category:Mail_Server etc].<br />
<br />
== Configuration ==<br />
<br />
=== Notes Before Configuring ===<br />
The gitlab package from AUR organizes GitLab's files in a manner that more closely follows standard linux conventions rather than installing everything in {{ic|/home/git}} as you are told to do by [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab's official install guide]. <br />
<br />
<br />
After you've installed gitlab from AUR, the config file {{ic|/etc/webapps/gitlab/shell.yml}} corresponds to the file {{ic|/home/git/gitlab-shell/config.yml}} that is mentioned in [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md#4-gitlab-shell GitLab's official install guide when installing gitlab-shell]. The config file {{ic|/etc/webapps/gitlab/gitlab.yml}} corresponds to the file {{ic|/home/git/gitlab/config/gitlab.yml}} that is mentioned in [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md#configure-it GitLab's official install guide when configuring GitLab].<br />
<br />
<br />
Another key difference between gitlab from AUR and the GitLab install guide is that GitLab from AUR uses the {{ic|gitlab}} user with {{ic|/var/lib/gitlab}} as the home folder instead of the {{ic|git}} user with {{ic|/home/git}} as the home folder. This keeps the {{ic|/home}} area clean so it contains only real user homes.<br />
<br />
{{tip|If you are familiar with the [[Arch Build System]] you can edit the PKGBUILD and relevant files to change gitlab's home directory to a place of your liking.}}<br />
<br />
===Basic configuration===<br />
Open up {{ic|/etc/webapps/gitlab/shell.yml}} and set {{ic|gitlab_url:}} to the url where you intend to host GitLab (note the 'http://' and trailing slash). For example, if you will host GitLab at 'yourdomain.com', then it'd look like this:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/shell.yml|<br />
# GitLab user. git by default<br />
user: gitlab<br />
<br />
# Url to gitlab instance. Used for api calls. Should end with a slash.<br />
gitlab_url: "<nowiki>http://yourdomain.com/</nowiki>" # <<-- right here<br />
<br />
http_settings:<br />
# user: someone<br />
# password: somepass<br />
...<br />
}}<br />
<br />
<br />
Open up {{ic|/etc/webapps/gitlab/gitlab.yml}} and edit where needed. In the {{ic|gitlab:}} section set {{ic|host:}} (replacing {{ic|localhost}}) to 'yourdomain.com', your fully qualified domin name (no 'http://' or trailing slash). {{ic|port:}} can be confusing. This is not the port that the gitlab server (unicorn) runs on; it's the port that users will initially access through in their browser. Basically, if you intend for users to visit 'yourdomain.com' in their browser, without appending a port number to the domain name, leave {{ic|port:}} as {{ic|80}}. If you intend your users to type something like 'yourdomain.com:3425' into their browsers, then you'd set {{ic|port:}} to {{ic|3425}} (you'll also have to configure your server (apache, nginx, etc) to listen on that port). Those are the minimal changes needed for a working GitLab install. The adventurous may read on in the comment and customize as needed. For example:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/gitlab.yml|<br />
...<br />
## GitLab settings<br />
gitlab:<br />
## Web server settings<br />
host: yourdomain.com<br />
port: 80<br />
https: false<br />
...<br />
}}<br />
<br />
=== Further configuration ===<br />
<br />
==== Database backend ====<br />
A Database backend will be required before Gitlab can be run. Currently GitLab supports [[MariaDB]] and [[PostgreSQL]]. By default, GitLab assumes you will use MySQL. Extra work is needed if you plan to use PostgreSQL.<br />
<br />
{{note|Don't forget to replace {{ic|your_username_here}} and {{ic|your_password_here}} with your chosen values in the following examples.}}<br />
<br />
==== MariaDB ====<br />
To set up MySQL (MariaDB) you need to create a database called {{ic|gitlabhq_production}} along with a user who has full priviledges to the database. You might do it via command line as in the following example.<br />
<br />
{{bc|mysql -u root -p}}<br />
<br />
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production`;<br />
mysql> CREATE USER 'your_username_here'@'localhost' IDENTIFIED BY 'your_password_here';<br />
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'your_username_here'@'localhost';<br />
mysql> \q<br />
<br />
Now try connecting to the new database with the new user to verify you did it correctly:<br />
<br />
{{bc|mysql -u your_username_here -p -D gitlabhq_production}}<br />
<br />
Next you'll need to open up {{ic|/etc/webapps/gitlab/database.yml}} and set {{ic|username:}} and {{ic|password:}} for the {{ic|gitlabhq_production}} database to {{ic|your_username_here}} and {{ic|your_password_here}}, respectively. You need not worry about the info for the {{ic|gitlabhq_development}} and {{ic|gitlan_test}} databases, as those are not required for our purposes (unless you're feeling adventurous at your own risk). For example:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/database.yml|<br />
#<br />
# PRODUCTION<br />
#<br />
production:<br />
adapter: mysql2<br />
encoding: utf8<br />
reconnect: false<br />
database: gitlabhq_production<br />
pool: 10<br />
username: your_username_here<br />
password: "your_password_here"<br />
# host: localhost<br />
# socket: /tmp/mysql.sock<br />
...<br />
}}<br />
<br />
That's all for MySQL configuration.<br />
<br />
For more info and other ways to create/manage MySQL databases, see the [https://mariadb.org/docs/ MariaDB documentation], the [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab official (generic) install guide], and [[phpMyAdmin]].<br />
<br />
==== PostgreSQL ====<br />
Login to PostgreSQL and create the {{ic|gitlabhq_production}} database with along with it's user. Remember to change {{ic|your_username_here}} and {{ic|your_password_here}} to the real values:<br />
<br />
{{bc|psql -d template1}}<br />
<br />
template1=# CREATE USER your_username_here WITH PASSWORD 'your_password_here';<br />
template1=# CREATE DATABASE gitlabhq_production OWNER your_username_here;<br />
template1=# \q<br />
<br />
Try connecting to the new database with the new user to verify it works:<br />
<br />
{{bc|psql -d gitlabhq_production}}<br />
<br />
Copy the PostgreSQL template file before configuring it (overwriting the default MySQL configuration file):<br />
<br />
# cp /usr/share/doc/gitlab/database.yml.postgresql /etc/webapps/gitlab/database.yml<br />
<br />
Open up the new {{ic|/etc/webapps/gitlab/database.yml}} and set the values for {{ic|username:}} and {{ic|password:}}. For example:<br />
<br />
{{hc|Snippet from the new /etc/webapps/gitlab/database.yml|<br />
#<br />
# PRODUCTION<br />
#<br />
production:<br />
adapter: postgresql<br />
encoding: unicode<br />
database: gitlabhq_production<br />
pool: 10<br />
username: your_username_here<br />
password: "your_password_here"<br />
# host: localhost<br />
# port: 5432 <br />
# socket: /tmp/postgresql.sock<br />
...<br />
}}<br />
<br />
For our purposes (unless you know what you're doing), you don't need to worry about configuring the other databases listed in {{ic|/etc/webapps/gitlab/database.yml}}. We only need to set up the production database to get GitLab working.<br />
<br />
Finally, open up {{ic|/usr/lib/systemd/system/gitlab.target}} change all instances of {{ic|mysql.service}} to {{ic|postgresql.service}}. For example:<br />
<br />
{{Accuracy|See [[systemd#Editing provided unit files]] for the correct way.}}<br />
<br />
{{hc|Snippet from /usr/lib/systemd/system/gitlab.target|<br />
...<br />
[Unit]<nowiki><br />
Description=GitLab - Self Hosted Git Management<br />
Requires=redis.service postgresql.service<br />
After=redis.service postgresql.service syslog.target network.target<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki><br />
}}<br />
<br />
<br />
==== Firewall ====<br />
<br />
If you want to give direct access to your Gitlab isntallation through a [[iptables]] firewall you have to the following ACCEPT rule. Change "your_gitlab_port" to your chosen port from above (here we give access to all clients within 192.168.1.0/24 network):<br />
<br />
# iptables -A tcp_inbound -p TCP -s 192.168.1.0/24 --destination-port your_gitlab_port -j ACCEPT <br />
<br />
If you are behind a router, don't forget to forward this port to the running Gitlab server host, too.<br />
<br />
==== Satellites access ====<br />
<br />
Satellites access should be "drwxr-x---":<br />
<br />
# chmod 750 /var/lib/gitlab/satellites<br />
<br />
==== Initialize Gitlab database ====<br />
<br />
Start the Redis server before we create the database:<br />
<br />
# systemctl start redis<br />
# systemctl enable redis<br />
<br />
Then, initialize the database and activate advanced features: <br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab bundle exec rake gitlab:setup RAILS_ENV=production<br />
<br />
Finally, Compile assets.(If you didn't do it,you won't receive data on user/sign_in pages)<br />
<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab -H bundle exec rake assets:precompile RAILS_ENV=production<br />
<br />
==== Configure Git User ====<br />
<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab -H git config --global user.name "GitLab"<br />
# sudo -u gitlab -H git config --global user.email "example@example.com"<br />
<br />
This must match the {{ic|user}} and {{ic|email_from}} defined in {{ic|/usr/share/webapps/gitlab/config/gitlab.yml}}<br />
<br />
==== Adjust modifier bits ====<br />
(The gitlab check won't pass if the user and group ownership isn't configured properly)<br />
<br />
# chmod -R ug+rwX,o-rwx /path/to/repos/<br />
# chmod -R ug-s /path/to/repos<br />
# find /path/to/repos/ -type d -print0 | xargs -O chmod g+s<br />
<br />
== Start and test GitLab ==<br />
<br />
With the following commands we check if the steps we followed so far are configured properly. <br />
<br />
$ cd /usr/share/webapps/gitlab<br />
$ sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production<br />
$ sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production<br />
<br />
{{note|These gitlab:env:info and gitlab:check commands will show a fatal error related to git. This is OK.}}<br />
<br />
{{hc|Example output of sudo -u gitlab bundle exec rake gitlab:env:info <nowiki>RAILS_ENV=production</nowiki>|<br />
fatal: Not a git repository (or any of the parent directories): .git<br />
<br />
System information<br />
System: Arch Linux<br />
Current User: git<br />
Using RVM: yes<br />
RVM Version: 1.20.3<br />
Ruby Version: 2.0.0p0<br />
Gem Version: 2.0.0<br />
Bundler Version:1.3.5<br />
Rake Version: 10.0.4<br />
<br />
GitLab information<br />
Version: 5.2.0.pre<br />
Revision: <br />
Directory: /home/git/gitlab<br />
DB Adapter: mysql2<br />
URL: http://gitlab.arch<br />
HTTP Clone URL: http://gitlab.arch/some-project.git<br />
SSH Clone URL: git@gitlab.arch:some-project.git<br />
Using LDAP: no<br />
Using Omniauth: no<br />
<br />
GitLab Shell<br />
Version: 1.4.0<br />
Repositories: /home/git/repositories/<br />
Hooks: /home/git/gitlab-shell/hooks/<br />
Git: /usr/bin/git<br />
}}<br />
<br />
{{Note| {{ic|gitlab:check}} will complain about missing initscripts. Don't worry, we will use ArchLinux's [[systemd]] to manage server start during boot (which GitLab does not recognize).}}<br />
<br />
{{hc|Example output of sudo -u gitlab bundle exec rake gitlab:check <nowiki>RAILS_ENV=production</nowiki>|<br />
<nowiki>fatal: Not a git repository (or any of the parent directories): .git<br />
Checking Environment ...<br />
<br />
Git configured for gitlab user? ... yes<br />
Has python2? ... yes<br />
python2 is supported version? ... yes<br />
<br />
Checking Environment ... Finished<br />
<br />
Checking GitLab Shell ...<br />
<br />
GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)<br />
Repo base directory exists? ... yes<br />
Repo base directory is a symlink? ... no<br />
Repo base owned by gitlab:gitlab? ... yes<br />
Repo base access is drwxrws---? ... yes<br />
update hook up-to-date? ... yes<br />
update hooks in repos are links: ... can't check, you have no projects<br />
Running /srv/gitlab/gitlab-shell/bin/check<br />
Check GitLab API access: OK<br />
Check directories and files:<br />
/srv/gitlab/repositories: OK<br />
/srv/gitlab/.ssh/authorized_keys: OK<br />
Test redis-cli executable: redis-cli 2.8.4<br />
Send ping to redis server: PONG<br />
gitlab-shell self-check successful<br />
<br />
Checking GitLab Shell ... Finished<br />
<br />
Checking Sidekiq ...<br />
<br />
Running? ... yes<br />
Number of Sidekiq processes ... 1<br />
<br />
Checking Sidekiq ... Finished<br />
<br />
Checking LDAP ...<br />
<br />
LDAP is disabled in config/gitlab.yml<br />
<br />
Checking LDAP ... Finished<br />
<br />
Checking GitLab ...<br />
<br />
Database config exists? ... yes<br />
Database is SQLite ... no<br />
All migrations up? ... fatal: Not a git repository (or any of the parent directories): .git<br />
yes<br />
GitLab config exists? ... yes<br />
GitLab config outdated? ... no<br />
Log directory writable? ... yes<br />
Tmp directory writable? ... yes<br />
Init script exists? ... no<br />
Try fixing it:<br />
Install the init script<br />
For more information see:<br />
doc/install/installation.md in section "Install Init Script"<br />
Please fix the error above and rerun the checks.<br />
Init script up-to-date? ... can't check because of previous errors<br />
projects have namespace: ... can't check, you have no projects<br />
Projects have satellites? ... can't check, you have no projects<br />
Redis version >= 2.0.0? ... yes<br />
Your git bin path is "/usr/bin/git"<br />
Git version >= 1.7.10 ? ... yes (1.8.5)<br />
<br />
Checking GitLab ... Finished<br />
</nowiki><br />
}}<br />
<br />
Make systemd see your new daemon unit files:<br />
<br />
$ systemctl daemon-reload<br />
<br />
After starting the database backend (in this case MySQL), we can start Gitlab with its webserver (Unicorn):<br />
<br />
$ systemctl start redis mysqld gitlab-sidekiq gitlab-unicorn<br />
<br />
Replace {{ic|mysqld}} with {{ic|postgresql}} in the above command if you're using PostgreSQL.<br />
<br />
To automatically launch GitLab at startup, run:<br />
<br />
$ systemctl enable gitlab.target gitlab-sidekiq gitlab-unicorn<br />
<br />
Now test your Gitlab instance by visiting http://localhost:8080 or http://yourdomain.com and login with the default credentials:<br />
username: {{ic|admin@local.host}}<br />
password: {{ic|5iveL!fe}}<br />
<br />
{{note|1=If your browser runs not on the machine where gitlab is running, modify your unicorn.rb in order to be able to test your setup without the use of a proxy. The corresponding line looks like this:<br />
<pre>listen "127.0.0.1:8080, :tcp_nopush => true</pre><br />
you should replace that with:<br />
<pre>listen "examle.yourhost.com:8080, :tcp_nopush => true</pre><br />
}}<br />
<br />
GitLab should now be up and running.<br />
<br />
== Advanced Configuration ==<br />
<br />
=== HTTPS/SSL ===<br />
<br />
==== Change GitLab configs ====<br />
Modify {{ic|/etc/webapps/gitlab/shell.yml}} so the url to your GitLab site starts with {{ic|https://}}.<br />
Modify {{ic|/etc/webapps/gitlab/gitlab.yml}} so that {{ic|https:}} setting is set to {{ic|true}}.<br />
<br />
==== Configure HTTPS server of choice====<br />
<br />
===== Apache =====<br />
{{stub|info needed}}<br />
<br />
===== Node.js =====<br />
You can easily set up an http proxy on port 443 to proxy traffic to the GitLab application on port 8080 using http-master for Node.js. After you've creates your domain's OpenSSL keys and have gotten you CA certificate (or self signed it), then go to https://github.com/CodeCharmLtd/http-master to learn how easy it is to proxy requests to GitLab using HTTPS. http-master is built on top of [https://github.com/nodejitsu/node-http-proxy node-http-proxy].<br />
<br />
===Web server configuration===<br />
If you want to integrate Gitlab into a running web server instead of using its build-in http server Unicorn, then follow these instructions.<br />
<br />
====Nginx and unicorn====<br />
<br />
[[pacman|Install]] {{Pkg|nginx}} from the [[official repositories]].<br />
<br />
Nginx gitlab configuration needs to be copied to nginx configuration directories.<br />
<br />
If you installed GitLab from AUR, do:<br />
<br />
# cp /usr/share/webapps/gitlab/lib/support/nginx/gitlab /etc/nginx/sites-available<br />
<br />
Then edit /usr/share/webapps/gitlab/lib/support/nginx/gitlab and change all path starting from /home/git/gitlab to /usr/share/webapps/gitlab (there are two occurences).<br />
<br />
If you did not use AUR, you need to copy {{ic|/lib/support/nginx/gitlab}} to {{ic|/etc/nginx/sites-available/}}.<br />
<br />
Run these commands to setup nginx:<br />
<br />
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab<br />
<br />
Edit {{ic|/etc/nginx/sites-enabled/gitlab}} and change YOUR_SERVER_IP and YOUR_SERVER_FQDN to the IP address and fully-qualified domain name of the host serving Gitlab.<br />
<br />
Make sure the following line exists at the end of the {{ic|http}} block in {{ic|/etc/nginx/nginx.conf}}:<br />
<br />
# include sites-enabled/*;<br />
<br />
Restart gitlab.target, resque.service and nginx.<br />
<br />
====Apache and unicorn====<br />
<br />
[[pacman|Install]] {{Pkg|apache}} from the [[official repositories]]. <br />
<br />
=====Configure Unicorn=====<br />
<br />
{{Note|If the default path is not {{ic|/home/git}} for your installation, change the below path accordingly}}<br />
<br />
As the official installation guide instructs, copy the unicorn configuration file:<br />
# sudo -u git -H cp /home/git/gitlab/config/unicorn.rb.example /home/git/gitlab/config/unicorn.rb<br />
<br />
Now edit {{ic|config/unicorn.rb}} and add a listening port by uncommenting the following line:<br />
listen "127.0.0.1:8080"<br />
<br />
{{Tip| You can set a custom port if you want. Just remember to also include it in Apache's virtual host. See below.}}<br />
<br />
=====Create a virtual host for Gitlab=====<br />
<br />
Create a configuration file for Gitlab’s virtual host and insert the lines below adjusted accordingly. For the ssl section see [[LAMP#SSL]]. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the BalanceMember line.<br />
<br />
You can use these [https://gitlab.com/gitlab-org/gitlab-recipes/blob/079f70dd2c091434a8dd04ed5b1a0d0e937cd361/web-server/apache/gitlab-ssl-apache2.4.conf examples] to get you started.<br />
<br />
=====Enable host and start unicorn=====<br />
<br />
Enable your Gitlab virtual host and reload [[Apache]]:<br />
{{hc|/etc/httpd/conf/httpd.conf| Include /etc/httpd/conf/extra/gitlab.conf}}<br />
<br />
Finally start unicorn:<br />
<br />
# systemctl start gitlab-unicorn<br />
<br />
=== Redis ===<br />
Using a Redis setup different from default (e.g. different address, port, unix socket) requires the environment variable ''REDIS_URL'' to be set accordingly for unicorn. This can be achieved by extending the systemd service file. Create a file ''/etc/systemd/system/gitlab-unicorn.service.d/redis.conf'' that injects the ''REDIS_URL'' environment variable:<br />
[Service]<br />
Environment=REDIS_URL=unix:///run/gitlab/redis.sock<br />
<br />
==Useful Tips==<br />
<br />
===Fix Rake Warning===<br />
When running rake tasks for the gitlab project, this error will occur: {{ic|fatal: Not a git repository (or any of the parent directories): .git}}. This is a bug in bundler, and it can be safely ignored. However, if you want to git rid of the error, the following method can be used:<br />
<br />
{{bc|1=<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab git init<br />
# sudo -u gitlab git commit -m "initial commit" --allow-empty<br />
}}<br />
<br />
===Hook into /var===<br />
{{bc|1=<br />
# mkdir -m700 /var/log/gitlab /var/tmp/gitlab<br />
# chown gitlab:gitlab /var/log/gitlab /var/tmp/gitlab<br />
# sudo -u gitlab -i<br />
# cd ~/gitlab<br />
# d=log; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
# d=tmp; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
}}<br />
<br />
===Hidden options===<br />
Go to Gitlab's home directory:<br />
# cd /usr/share/webapps/gitlab<br />
<br />
and run:<br />
{{hc|<nowiki># rake -T | grep gitlab</nowiki>|<nowiki><br />
rake gitlab:app:check # GITLAB | Check the configuration of the GitLab Rails app<br />
rake gitlab:backup:create # GITLAB | Create a backup of the GitLab system<br />
rake gitlab:backup:restore # GITLAB | Restore a previously created backup<br />
rake gitlab:check # GITLAB | Check the configuration of GitLab and its environment<br />
rake gitlab:cleanup:block_removed_ldap_users # GITLAB | Cleanup | Block users that have been removed in LDAP<br />
rake gitlab:cleanup:dirs # GITLAB | Cleanup | Clean namespaces<br />
rake gitlab:cleanup:repos # GITLAB | Cleanup | Clean repositories<br />
rake gitlab:env:check # GITLAB | Check the configuration of the environment<br />
rake gitlab:env:info # GITLAB | Show information about GitLab and its environment<br />
rake gitlab:generate_docs # GITLAB | Generate sdocs for project<br />
rake gitlab:gitlab_shell:check # GITLAB | Check the configuration of GitLab Shell<br />
rake gitlab:import:all_users_to_all_groups # GITLAB | Add all users to all groups (admin users are added as owners)<br />
rake gitlab:import:all_users_to_all_projects # GITLAB | Add all users to all projects (admin users are added as masters)<br />
rake gitlab:import:repos # GITLAB | Import bare repositories from gitlab_shell -> repos_path into GitLab project instance<br />
rake gitlab:import:user_to_groups[email] # GITLAB | Add a specific user to all groups (as a developer)<br />
rake gitlab:import:user_to_projects[email] # GITLAB | Add a specific user to all projects (as a developer)<br />
rake gitlab:satellites:create # GITLAB | Create satellite repos<br />
rake gitlab:setup # GITLAB | Setup production application<br />
rake gitlab:shell:build_missing_projects # GITLAB | Build missing projects<br />
rake gitlab:shell:install[tag,repo] # GITLAB | Install or upgrade gitlab-shell<br />
rake gitlab:shell:setup # GITLAB | Setup gitlab-shell<br />
rake gitlab:sidekiq:check # GITLAB | Check the configuration of Sidekiq<br />
rake gitlab:test # GITLAB | Run all tests<br />
rake gitlab:web_hook:add # GITLAB | Adds a web hook to the projects<br />
rake gitlab:web_hook:list # GITLAB | List web hooks<br />
rake gitlab:web_hook:rm # GITLAB | Remove a web hook from the projects<br />
rake setup # GITLAB | Setup gitlab db<br />
</nowiki>}}<br />
<br />
===Backup and restore===<br />
<br />
Create a backup of the gitlab system:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create<br />
<br />
Restore the previously created backup file {{ic|/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar}}:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740<br />
<br />
{{Note| Backup folder is set in {{ic|config/gitlab.yml}}. GitLab backup and restore is documented [https://github.com/gitlabhq/gitlabhq/blob/master/doc/raketasks/backup_restore.md here].}}<br />
<br />
===Migrate from sqlite to mysql===<br />
<br />
Get latest code as described in [[#Update_Gitlab]].<br />
Save data.<br />
# cd /home/gitlab/gitlab<br />
# sudo -u gitlab bundle exec rake db:data:dump RAILS_ENV=production<br />
<br />
Follow [[#Mysql]] instructions and then setup the database.<br />
# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production<br />
<br />
Finally restore old data.<br />
# sudo -u gitlab bundle exec rake db:data:load RAILS_ENV=production<br />
<br />
===Running GitLab with rvm===<br />
<br />
To run gitlab with rvm first you have to set up an rvm:<br />
<br />
curl -L https://get.rvm.io | bash -s stable --ruby=1.9.3<br />
<br />
{{Note|Version 1.9.3 is currently recommended to avoid some compatibility issues.}}<br />
<br />
For the complete installation you will want to be the final user (e.g. {{ic|git}}) so make sure to switch to this user and activate your rvm:<br />
<br />
su - git<br />
source "$HOME/.rvm/scripts/rvm"<br />
<br />
Then continue with the installation instructions from above. However, the systemd scripts will not work this way, because the environment for the rvm is not activated. The recommendation here is to create to separate shell scripts for {{ic|puma}} and {{ic|sidekiq}} to activate the environment and then start the service:<br />
<br />
{{hc|gitlab.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
RAILS_ENV=production bundle exec puma -C "/home/git/gitlab/config/puma.rb"</nowiki><br />
}}<br />
<br />
{{hc|sidekiq.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
case $1 in<br />
start)<br />
bundle exec rake sidekiq:start RAILS_ENV=production<br />
;;<br />
stop)<br />
bundle exec rake sidekiq:stop RAILS_ENV=production<br />
;;<br />
*)<br />
echo "Usage $0 {start|stop}"<br />
esac<br />
</nowiki>}}<br />
<br />
Then modify the above systemd files so they use these scripts. Modify the given lines:<br />
<br />
{{hc|gitlab.service|<nowiki><br />
ExecStart=/home/git/bin/gitlab.sh<br />
</nowiki>}}<br />
{{hc|sidekiq.service|<nowiki><br />
ExecStart=/home/git/bin/sidekiq.sh start<br />
ExecStop=/home/git/bin/sidekiq.sh stop<br />
</nowiki>}}<br />
<br />
==Troubleshooting==<br />
<br />
Sometimes things may not work as expected. Be sure to visit the [https://github.com/gitlabhq/gitlab-public-wiki/wiki/Trouble-Shooting-Guide Trouble Shooting Guide].<br />
<br />
=== HTTPS is not green (gravatar not using https) ===<br />
Redis caches gravatar images, so if you've visited your GitLab with http, then enabled https, gravatar will load up the non-secure images. You can clear the cache by doing<br />
<br />
cd /usr/share/webapps/gitlab; bundle exec rake cache:clear<br />
<br />
as the gitlab user.<br />
<br />
==See also==<br />
*[https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md Official Documentation]<br />
*[https://gitlab.com/gitlab-org/gitlab-recipes Gitlab recipes with further documentation on running it with several webservers]</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=GitLab&diff=329743GitLab2014-08-10T16:43:18Z<p>Imranhaider: Fix typo</p>
<hr />
<div>[[Category:Version Control System]]<br />
{{Related articles start}}<br />
{{Related|Gitolite}}<br />
{{Related|Ruby on Rails}}<br />
{{Related articles end}}<br />
<br />
[http://gitlab.org/ Gitlab] is a free git repository management application based on [[Ruby on Rails]]. It is distributed under the MIT License and its source code can be found on [https://github.com/gitlabhq/gitlabhq Github]. It is a very active project with a monthly release cycle and ideal for businesses that want to keep their code private. Consider it as a self hosted Github but open source. You can try a demo [http://demo.gitlabhq.com/ here].<br />
<br />
== Installation ==<br />
{{Note|If you want to use rvm be sure to check out [[Gitlab#Running GitLab with rvm]] before starting with the installation}}<br />
<br />
{{note|This guide covers installing and configuring GitLab without HTTPS/SSL at first, just to get GitLab up and running. After getting GitLab up and running, see [[#Advanced Configuration]] to set up SSL.}}<br />
<br />
Installing {{AUR|gitlab}} from the [[AUR]] instead of manually has the added benefit that lots of steps have been taken care of for you (e.g. permissions and ownership for files, etc). <br />
<br />
Make sure you perform a system upgrade ({{ic|pacman -Syu}}) before installing gitlab from AUR and that you have installed the {{ic|base-devel}} group, or you may face problems installing gitlab because [https://wiki.archlinux.org/index.php/Makepkg#Usage base-devel packages are not required to be listed as dependencies in PKGBUILD files].<br />
<br />
Also before installing the {{AUR|gitlab}} package from the [[AUR]], you need to choose a database backend if you're planning to host GitLab it on the same machine as the database:<br />
<br />
* Use [[pacman|Pacman]] to install {{Pkg|mariadb}} and {{Pkg|libmariadbclient}} from the [[official repositories]] and start the [[daemon]]<br />
* or install {{Pkg|postgresql}} and {{Pkg|libpqxx}}. Read [[PostgreSQL#Installing_PostgreSQL]] to set it up and start the [[daemon]]. <br />
<br />
In order to receive mail notifications, make sure to install a mail server. By default, Archlinux does not ship with one. The recommended mail server is [[postfix]], but you can use others such as [[SSMTP]], [[msmtp]], [[sendmail]], [https://wiki.archlinux.org/index.php/Category:Mail_Server etc].<br />
<br />
== Configuration ==<br />
<br />
=== Notes Before Configuring ===<br />
The gitlab package from AUR organizes GitLab's files in a manner that more closely follows standard linux conventions rather than installing everything in {{ic|/home/git}} as you are told to do by [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab's official install guide]. <br />
<br />
<br />
After you've installed gitlab from AUR, the config file {{ic|/etc/webapps/gitlab/shell.yml}} corresponds to the file {{ic|/home/git/gitlab-shell/config.yml}} that is mentioned in [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md#4-gitlab-shell GitLab's official install guide when installing gitlab-shell]. The config file {{ic|/etc/webapps/gitlab/gitlab.yml}} corresponds to the file {{ic|/home/git/gitlab/config/gitlab.yml}} that is mentioned in [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md#configure-it GitLab's official install guide when configuring GitLab].<br />
<br />
<br />
Another key difference between gitlab from AUR and the GitLab install guide is that GitLab from AUR uses the {{ic|gitlab}} user with {{ic|/var/lib/gitlab}} as the home folder instead of the {{ic|git}} user with {{ic|/home/git}} as the home folder. This keeps the {{ic|/home}} area clean so it contains only real user homes.<br />
<br />
{{tip|If you are familiar with the [[Arch Build System]] you can edit the PKGBUILD and relevant files to change gitlab's home directory to a place of your liking.}}<br />
<br />
===Basic configuration===<br />
Open up {{ic|/etc/webapps/gitlab/shell.yml}} and set {{ic|gitlab_url:}} to the url where you intend to host GitLab (note the 'http://' and trailing slash). For example, if you will host GitLab at 'yourdomain.com', then it'd look like this:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/shell.yml|<br />
# GitLab user. git by default<br />
user: gitlab<br />
<br />
# Url to gitlab instance. Used for api calls. Should end with a slash.<br />
gitlab_url: "<nowiki>http://yourdomain.com/</nowiki>" # <<-- right here<br />
<br />
http_settings:<br />
# user: someone<br />
# password: somepass<br />
...<br />
}}<br />
<br />
<br />
Open up {{ic|/etc/webapps/gitlab/gitlab.yml}} and edit where needed. In the {{ic|gitlab:}} section set {{ic|host:}} (replacing {{ic|localhost}}) to 'yourdomain.com', your fully qualified domin name (no 'http://' or trailing slash). {{ic|port:}} can be confusing. This is not the port that the gitlab server (unicorn) runs on; it's the port that users will initially access through in their browser. Basically, if you intend for users to visit 'yourdomain.com' in their browser, without appending a port number to the domain name, leave {{ic|port:}} as {{ic|80}}. If you intend your users to type something like 'yourdomain.com:3425' into their browsers, then you'd set {{ic|port:}} to {{ic|3425}} (you'll also have to configure your server (apache, nginx, etc) to listen on that port). Those are the minimal changes needed for a working GitLab install. The adventurous may read on in the comment and customize as needed. For example:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/gitlab.yml|<br />
...<br />
## GitLab settings<br />
gitlab:<br />
## Web server settings<br />
host: yourdomain.com<br />
port: 80<br />
https: false<br />
...<br />
}}<br />
<br />
=== Further configuration ===<br />
<br />
==== Database backend ====<br />
A Database backend will be required before Gitlab can be run. Currently GitLab supports [[MariaDB]] and [[PostgreSQL]]. By default, GitLab assumes you will use MySQL. Extra work is needed if you plan to use PostgreSQL.<br />
<br />
{{note|Don't forget to replace {{ic|your_username_here}} and {{ic|your_password_here}} with your chosen values in the following examples.}}<br />
<br />
==== MariaDB ====<br />
To set up MySQL (MariaDB) you need to create a database called {{ic|gitlabhq_production}} along with a user who has full priviledges to the database. You might do it via command line as in the following example.<br />
<br />
{{bc|mysql -u root -p}}<br />
<br />
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production`;<br />
mysql> CREATE USER 'your_username_here'@'localhost' IDENTIFIED BY 'your_password_here';<br />
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'your_username_here'@'localhost';<br />
mysql> \q<br />
<br />
Now try connecting to the new database with the new user to verify you did it correctly:<br />
<br />
{{bc|mysql -u your_username_here -p -D gitlabhq_production}}<br />
<br />
Next you'll need to open up {{ic|/etc/webapps/gitlab/database.yml}} and set {{ic|username:}} and {{ic|password:}} for the {{ic|gitlabhq_production}} database to {{ic|your_username_here}} and {{ic|your_password_here}}, respectively. You need not worry about the info for the {{ic|gitlabhq_development}} and {{ic|gitlan_test}} databases, as those are not required for our purposes (unless you're feeling adventurous at your own risk). For example:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/database.yml|<br />
#<br />
# PRODUCTION<br />
#<br />
production:<br />
adapter: mysql2<br />
encoding: utf8<br />
reconnect: false<br />
database: gitlabhq_production<br />
pool: 10<br />
username: your_username_here<br />
password: "your_password_here"<br />
# host: localhost<br />
# socket: /tmp/mysql.sock<br />
...<br />
}}<br />
<br />
That's all for MySQL configuration.<br />
<br />
For more info and other ways to create/manage MySQL databases, see the [https://mariadb.org/docs/ MariaDB documentation], the [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab official (generic) install guide], and [[phpMyAdmin]].<br />
<br />
==== PostgreSQL ====<br />
Login to PostgreSQL and create the {{ic|gitlabhq_production}} database with along with it's user. Remember to change {{ic|your_username_here}} and {{ic|your_password_here}} to the real values:<br />
<br />
{{bc|psql -d template1}}<br />
<br />
template1=# CREATE USER your_username_here WITH PASSWORD 'your_password_here';<br />
template1=# CREATE DATABASE gitlabhq_production OWNER your_username_here;<br />
template1=# \q<br />
<br />
Try connecting to the new database with the new user to verify it works:<br />
<br />
{{bc|psql -d gitlabhq_production}}<br />
<br />
Copy the PostgreSQL template file before configuring it (overwriting the default MySQL configuration file):<br />
<br />
# cp /usr/share/doc/gitlab/database.yml.postgresql /etc/webapps/gitlab/database.yml<br />
<br />
Open up the new {{ic|/etc/webapps/gitlab/database.yml}} and set the values for {{ic|username:}} and {{ic|password:}}. For example:<br />
<br />
{{hc|Snippet from the new /etc/webapps/gitlab/database.yml|<br />
#<br />
# PRODUCTION<br />
#<br />
production:<br />
adapter: postgresql<br />
encoding: unicode<br />
database: gitlabhq_production<br />
pool: 10<br />
username: your_username_here<br />
password: "your_password_here"<br />
# host: localhost<br />
# port: 5432 <br />
# socket: /tmp/postgresql.sock<br />
...<br />
}}<br />
<br />
For our purposes (unless you know what you're doing), you don't need to worry about configuring the other databases listed in {{ic|/etc/webapps/gitlab/database.yml}}. We only need to set up the production database to get GitLab working.<br />
<br />
Finally, open up {{ic|/usr/lib/systemd/system/gitlab.target}} change all instances of {{ic|mysql.service}} to {{ic|postgresql.service}}. For example:<br />
<br />
{{Accuracy|See [[systemd#Editing provided unit files]] for the correct way.}}<br />
<br />
{{hc|Snippet from /usr/lib/systemd/system/gitlab.target|<br />
...<br />
[Unit]<nowiki><br />
Description=GitLab - Self Hosted Git Management<br />
Requires=redis.service postgresql.service<br />
After=redis.service postgresql.service syslog.target network.target<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki><br />
}}<br />
<br />
<br />
==== Firewall ====<br />
<br />
If you want to give direct access to your Gitlab isntallation through a [[iptables]] firewall you have to the following ACCEPT rule. Change "your_gitlab_port" to your chosen port from above (here we give access to all clients within 192.168.1.0/24 network):<br />
<br />
# iptables -A tcp_inbound -p TCP -s 192.168.1.0/24 --destination-port your_gitlab_port -j ACCEPT <br />
<br />
If you are behind a router, don't forget to forward this port to the running Gitlab server host, too.<br />
<br />
==== Satellites access ====<br />
<br />
Satellites access should be "drwxr-x---":<br />
<br />
# chmod 750 /var/lib/gitlab/satellites<br />
<br />
==== Initialize Gitlab database ====<br />
<br />
Start the Redis server before we create the database:<br />
<br />
# systemctl start redis<br />
# systemctl enable redis<br />
<br />
Then, initialize the database and activate advanced features: <br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab bundle exec rake gitlab:setup RAILS_ENV=production<br />
<br />
Finally, Compile assets.(If you didn't do it,you won't receive data on user/sign_in pages)<br />
<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab -H bundle exec rake assets:precompile RAILS_ENV=production<br />
<br />
==== Configure Git User ====<br />
<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab -H git config --global user.name "GitLab"<br />
# sudo -u gitlab -H git config --global user.email "example@example.com"<br />
<br />
This must match the {{ic|user}} and {{ic|email_from}} defined in {{ic|/usr/share/webapps/gitlab/config/gitlab.yml}}<br />
<br />
==== Adjust modifier bits ====<br />
(The gitlab check won't pass if the user and group ownership isn't configured properly)<br />
<br />
# chmod -R ug+rwX,o-rwx /path/to/repos/<br />
# chmod -R ug-s /path/to/repos<br />
# find /path/to/repos/ -type d -print0 | xargs -O chmod g+s<br />
<br />
== Start and test GitLab ==<br />
<br />
With the following commands we check if the steps we followed so far are configured properly. <br />
<br />
$ cd /usr/share/webapps/gitlab<br />
$ sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production<br />
$ sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production<br />
<br />
{{note|These gitlab:env:info and gitlab:check commands will show a fatal error related to git. This is OK.}}<br />
<br />
{{hc|Example output of sudo -u gitlab bundle exec rake gitlab:env:info <nowiki>RAILS_ENV=production</nowiki>|<br />
fatal: Not a git repository (or any of the parent directories): .git<br />
<br />
System information<br />
System: Arch Linux<br />
Current User: git<br />
Using RVM: yes<br />
RVM Version: 1.20.3<br />
Ruby Version: 2.0.0p0<br />
Gem Version: 2.0.0<br />
Bundler Version:1.3.5<br />
Rake Version: 10.0.4<br />
<br />
GitLab information<br />
Version: 5.2.0.pre<br />
Revision: <br />
Directory: /home/git/gitlab<br />
DB Adapter: mysql2<br />
URL: http://gitlab.arch<br />
HTTP Clone URL: http://gitlab.arch/some-project.git<br />
SSH Clone URL: git@gitlab.arch:some-project.git<br />
Using LDAP: no<br />
Using Omniauth: no<br />
<br />
GitLab Shell<br />
Version: 1.4.0<br />
Repositories: /home/git/repositories/<br />
Hooks: /home/git/gitlab-shell/hooks/<br />
Git: /usr/bin/git<br />
}}<br />
<br />
{{Note| {{ic|gitlab:check}} will complain about missing initscripts. Don't worry, we will use ArchLinux's [[systemd]] to manage server start during boot (which GitLab does not recognize).}}<br />
<br />
{{hc|Example output of sudo -u gitlab bundle exec rake gitlab:check <nowiki>RAILS_ENV=production</nowiki>|<br />
<nowiki>fatal: Not a git repository (or any of the parent directories): .git<br />
Checking Environment ...<br />
<br />
Git configured for gitlab user? ... yes<br />
Has python2? ... yes<br />
python2 is supported version? ... yes<br />
<br />
Checking Environment ... Finished<br />
<br />
Checking GitLab Shell ...<br />
<br />
GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)<br />
Repo base directory exists? ... yes<br />
Repo base directory is a symlink? ... no<br />
Repo base owned by gitlab:gitlab? ... yes<br />
Repo base access is drwxrws---? ... yes<br />
update hook up-to-date? ... yes<br />
update hooks in repos are links: ... can't check, you have no projects<br />
Running /srv/gitlab/gitlab-shell/bin/check<br />
Check GitLab API access: OK<br />
Check directories and files:<br />
/srv/gitlab/repositories: OK<br />
/srv/gitlab/.ssh/authorized_keys: OK<br />
Test redis-cli executable: redis-cli 2.8.4<br />
Send ping to redis server: PONG<br />
gitlab-shell self-check successful<br />
<br />
Checking GitLab Shell ... Finished<br />
<br />
Checking Sidekiq ...<br />
<br />
Running? ... yes<br />
Number of Sidekiq processes ... 1<br />
<br />
Checking Sidekiq ... Finished<br />
<br />
Checking LDAP ...<br />
<br />
LDAP is disabled in config/gitlab.yml<br />
<br />
Checking LDAP ... Finished<br />
<br />
Checking GitLab ...<br />
<br />
Database config exists? ... yes<br />
Database is SQLite ... no<br />
All migrations up? ... fatal: Not a git repository (or any of the parent directories): .git<br />
yes<br />
GitLab config exists? ... yes<br />
GitLab config outdated? ... no<br />
Log directory writable? ... yes<br />
Tmp directory writable? ... yes<br />
Init script exists? ... no<br />
Try fixing it:<br />
Install the init script<br />
For more information see:<br />
doc/install/installation.md in section "Install Init Script"<br />
Please fix the error above and rerun the checks.<br />
Init script up-to-date? ... can't check because of previous errors<br />
projects have namespace: ... can't check, you have no projects<br />
Projects have satellites? ... can't check, you have no projects<br />
Redis version >= 2.0.0? ... yes<br />
Your git bin path is "/usr/bin/git"<br />
Git version >= 1.7.10 ? ... yes (1.8.5)<br />
<br />
Checking GitLab ... Finished<br />
</nowiki><br />
}}<br />
<br />
Make systemd see your new daemon unit files:<br />
<br />
$ systemctl daemon-reload<br />
<br />
After starting the database backend (in this case MySQL), we can start Gitlab with its webserver (Unicorn):<br />
<br />
$ systemctl start redis mysqld gitlab-sidekiq gitlab-unicorn<br />
<br />
Replace {{ic|mysqld}} with {{ic|postgresql}} in the above command if you're using PostgreSQL.<br />
<br />
To automatically launch GitLab at startup, run:<br />
<br />
$ systemctl enable gitlab.target gitlab-sidekiq gitlab-unicorn<br />
<br />
Now test your Gitlab instance by visiting http://localhost:8080 or http://yourdomain.com and login with the default credentials:<br />
username: {{ic|admin@local.host}}<br />
password: {{ic|5iveL!fe}}<br />
<br />
{{note|1=If your browser runs not on the machine where gitlab is running, modify your unicorn.rb in order to be able to test your setup without the use of a proxy. The corresponding line looks like this:<br />
<pre>listen "127.0.0.1:8080, :tcp_nopush => true</pre><br />
you should replace that with:<br />
<pre>listen "examle.yourhost.com:8080, :tcp_nopush => true</pre><br />
}}<br />
<br />
GitLab should now be up and running.<br />
<br />
== Advanced Configuration ==<br />
<br />
=== HTTPS/SSL ===<br />
<br />
==== Change GitLab configs ====<br />
Modify {{ic|/etc/webapps/gitlab/shell.yml}} so the url to your GitLab site starts with {{ic|https://}}.<br />
Modify {{ic|/etc/webapps/gitlab/gitlab.yml}} so that {{ic|https:}} setting is set to {{ic|true}}.<br />
<br />
==== Configure HTTPS server of choice====<br />
<br />
===== Apache =====<br />
{{stub|info needed}}<br />
<br />
===== Node.js =====<br />
You can easily set up an http proxy on port 443 to proxy traffic to the GitLab application on port 8080 using http-master for Node.js. After you've creates your domain's OpenSSL keys and have gotten you CA certificate (or self signed it), then go to https://github.com/CodeCharmLtd/http-master to learn how easy it is to proxy requests to GitLab using HTTPS. http-master is built on top of [https://github.com/nodejitsu/node-http-proxy node-http-proxy].<br />
<br />
===Web server configuration===<br />
If you want to integrate Gitlab into a running web server instead of using its build-in http server Unicorn, then follow these instructions.<br />
<br />
====Nginx and unicorn====<br />
<br />
[[pacman|Install]] {{Pkg|nginx}} from the [[official repositories]].<br />
<br />
Nginx gitlab configuration needs to be copied to nginx configuration directories.<br />
<br />
If you installed GitLab from AUR, do:<br />
<br />
# cp /usr/share/webapps/gitlab/lib/support/nginx/gitlab /etc/nginx/sites-available<br />
<br />
Then edit /usr/share/webapps/gitlab/lib/support/nginx/gitlab and change all path starting from /home/git/gitlab to /usr/share/webapps/gitlab (there are two occurences).<br />
<br />
If you did not use AUR, you need to copy {{ic|/lib/support/nginx/gitlab}} to {{ic|/etc/nginx/sites-available/}}.<br />
<br />
Run these commands to setup nginx:<br />
<br />
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab<br />
<br />
Edit {{ic|/etc/nginx/sites-enabled/gitlab}} and change YOUR_SERVER_IP and YOUR_SERVER_FQDN to the IP address and fully-qualified domain name of the host serving Gitlab.<br />
<br />
Restart gitlab.target, resque.service and nginx.<br />
<br />
====Apache and unicorn====<br />
<br />
[[pacman|Install]] {{Pkg|apache}} from the [[official repositories]]. <br />
<br />
=====Configure Unicorn=====<br />
<br />
{{Note|If the default path is not {{ic|/home/git}} for your installation, change the below path accordingly}}<br />
<br />
As the official installation guide instructs, copy the unicorn configuration file:<br />
# sudo -u git -H cp /home/git/gitlab/config/unicorn.rb.example /home/git/gitlab/config/unicorn.rb<br />
<br />
Now edit {{ic|config/unicorn.rb}} and add a listening port by uncommenting the following line:<br />
listen "127.0.0.1:8080"<br />
<br />
{{Tip| You can set a custom port if you want. Just remember to also include it in Apache's virtual host. See below.}}<br />
<br />
=====Create a virtual host for Gitlab=====<br />
<br />
Create a configuration file for Gitlab’s virtual host and insert the lines below adjusted accordingly. For the ssl section see [[LAMP#SSL]]. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the BalanceMember line.<br />
<br />
You can use these [https://gitlab.com/gitlab-org/gitlab-recipes/blob/079f70dd2c091434a8dd04ed5b1a0d0e937cd361/web-server/apache/gitlab-ssl-apache2.4.conf examples] to get you started.<br />
<br />
=====Enable host and start unicorn=====<br />
<br />
Enable your Gitlab virtual host and reload [[Apache]]:<br />
{{hc|/etc/httpd/conf/httpd.conf| Include /etc/httpd/conf/extra/gitlab.conf}}<br />
<br />
Finally start unicorn:<br />
<br />
# systemctl start gitlab-unicorn<br />
<br />
=== Redis ===<br />
Using a Redis setup different from default (e.g. different address, port, unix socket) requires the environment variable ''REDIS_URL'' to be set accordingly for unicorn. This can be achieved by extending the systemd service file. Create a file ''/etc/systemd/system/gitlab-unicorn.service.d/redis.conf'' that injects the ''REDIS_URL'' environment variable:<br />
[Service]<br />
Environment=REDIS_URL=unix:///run/gitlab/redis.sock<br />
<br />
==Useful Tips==<br />
<br />
===Fix Rake Warning===<br />
When running rake tasks for the gitlab project, this error will occur: {{ic|fatal: Not a git repository (or any of the parent directories): .git}}. This is a bug in bundler, and it can be safely ignored. However, if you want to git rid of the error, the following method can be used:<br />
<br />
{{bc|1=<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab git init<br />
# sudo -u gitlab git commit -m "initial commit" --allow-empty<br />
}}<br />
<br />
===Hook into /var===<br />
{{bc|1=<br />
# mkdir -m700 /var/log/gitlab /var/tmp/gitlab<br />
# chown gitlab:gitlab /var/log/gitlab /var/tmp/gitlab<br />
# sudo -u gitlab -i<br />
# cd ~/gitlab<br />
# d=log; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
# d=tmp; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
}}<br />
<br />
===Hidden options===<br />
Go to Gitlab's home directory:<br />
# cd /usr/share/webapps/gitlab<br />
<br />
and run:<br />
{{hc|<nowiki># rake -T | grep gitlab</nowiki>|<nowiki><br />
rake gitlab:app:check # GITLAB | Check the configuration of the GitLab Rails app<br />
rake gitlab:backup:create # GITLAB | Create a backup of the GitLab system<br />
rake gitlab:backup:restore # GITLAB | Restore a previously created backup<br />
rake gitlab:check # GITLAB | Check the configuration of GitLab and its environment<br />
rake gitlab:cleanup:block_removed_ldap_users # GITLAB | Cleanup | Block users that have been removed in LDAP<br />
rake gitlab:cleanup:dirs # GITLAB | Cleanup | Clean namespaces<br />
rake gitlab:cleanup:repos # GITLAB | Cleanup | Clean repositories<br />
rake gitlab:env:check # GITLAB | Check the configuration of the environment<br />
rake gitlab:env:info # GITLAB | Show information about GitLab and its environment<br />
rake gitlab:generate_docs # GITLAB | Generate sdocs for project<br />
rake gitlab:gitlab_shell:check # GITLAB | Check the configuration of GitLab Shell<br />
rake gitlab:import:all_users_to_all_groups # GITLAB | Add all users to all groups (admin users are added as owners)<br />
rake gitlab:import:all_users_to_all_projects # GITLAB | Add all users to all projects (admin users are added as masters)<br />
rake gitlab:import:repos # GITLAB | Import bare repositories from gitlab_shell -> repos_path into GitLab project instance<br />
rake gitlab:import:user_to_groups[email] # GITLAB | Add a specific user to all groups (as a developer)<br />
rake gitlab:import:user_to_projects[email] # GITLAB | Add a specific user to all projects (as a developer)<br />
rake gitlab:satellites:create # GITLAB | Create satellite repos<br />
rake gitlab:setup # GITLAB | Setup production application<br />
rake gitlab:shell:build_missing_projects # GITLAB | Build missing projects<br />
rake gitlab:shell:install[tag,repo] # GITLAB | Install or upgrade gitlab-shell<br />
rake gitlab:shell:setup # GITLAB | Setup gitlab-shell<br />
rake gitlab:sidekiq:check # GITLAB | Check the configuration of Sidekiq<br />
rake gitlab:test # GITLAB | Run all tests<br />
rake gitlab:web_hook:add # GITLAB | Adds a web hook to the projects<br />
rake gitlab:web_hook:list # GITLAB | List web hooks<br />
rake gitlab:web_hook:rm # GITLAB | Remove a web hook from the projects<br />
rake setup # GITLAB | Setup gitlab db<br />
</nowiki>}}<br />
<br />
===Backup and restore===<br />
<br />
Create a backup of the gitlab system:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create<br />
<br />
Restore the previously created backup file {{ic|/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar}}:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740<br />
<br />
{{Note| Backup folder is set in {{ic|config/gitlab.yml}}. GitLab backup and restore is documented [https://github.com/gitlabhq/gitlabhq/blob/master/doc/raketasks/backup_restore.md here].}}<br />
<br />
===Migrate from sqlite to mysql===<br />
<br />
Get latest code as described in [[#Update_Gitlab]].<br />
Save data.<br />
# cd /home/gitlab/gitlab<br />
# sudo -u gitlab bundle exec rake db:data:dump RAILS_ENV=production<br />
<br />
Follow [[#Mysql]] instructions and then setup the database.<br />
# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production<br />
<br />
Finally restore old data.<br />
# sudo -u gitlab bundle exec rake db:data:load RAILS_ENV=production<br />
<br />
===Running GitLab with rvm===<br />
<br />
To run gitlab with rvm first you have to set up an rvm:<br />
<br />
curl -L https://get.rvm.io | bash -s stable --ruby=1.9.3<br />
<br />
{{Note|Version 1.9.3 is currently recommended to avoid some compatibility issues.}}<br />
<br />
For the complete installation you will want to be the final user (e.g. {{ic|git}}) so make sure to switch to this user and activate your rvm:<br />
<br />
su - git<br />
source "$HOME/.rvm/scripts/rvm"<br />
<br />
Then continue with the installation instructions from above. However, the systemd scripts will not work this way, because the environment for the rvm is not activated. The recommendation here is to create to separate shell scripts for {{ic|puma}} and {{ic|sidekiq}} to activate the environment and then start the service:<br />
<br />
{{hc|gitlab.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
RAILS_ENV=production bundle exec puma -C "/home/git/gitlab/config/puma.rb"</nowiki><br />
}}<br />
<br />
{{hc|sidekiq.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
case $1 in<br />
start)<br />
bundle exec rake sidekiq:start RAILS_ENV=production<br />
;;<br />
stop)<br />
bundle exec rake sidekiq:stop RAILS_ENV=production<br />
;;<br />
*)<br />
echo "Usage $0 {start|stop}"<br />
esac<br />
</nowiki>}}<br />
<br />
Then modify the above systemd files so they use these scripts. Modify the given lines:<br />
<br />
{{hc|gitlab.service|<nowiki><br />
ExecStart=/home/git/bin/gitlab.sh<br />
</nowiki>}}<br />
{{hc|sidekiq.service|<nowiki><br />
ExecStart=/home/git/bin/sidekiq.sh start<br />
ExecStop=/home/git/bin/sidekiq.sh stop<br />
</nowiki>}}<br />
<br />
==Troubleshooting==<br />
<br />
Sometimes things may not work as expected. Be sure to visit the [https://github.com/gitlabhq/gitlab-public-wiki/wiki/Trouble-Shooting-Guide Trouble Shooting Guide].<br />
<br />
=== HTTPS is not green (gravatar not using https) ===<br />
Redis caches gravatar images, so if you've visited your GitLab with http, then enabled https, gravatar will load up the non-secure images. You can clear the cache by doing<br />
<br />
cd /usr/share/webapps/gitlab; bundle exec rake cache:clear<br />
<br />
as the gitlab user.<br />
<br />
==See also==<br />
*[https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md Official Documentation]<br />
*[https://gitlab.com/gitlab-org/gitlab-recipes Gitlab recipes with further documentation on running it with several webservers]</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=GitLab&diff=329742GitLab2014-08-10T16:42:26Z<p>Imranhaider: mention how the admin can change the 'from' address of gitlab emails</p>
<hr />
<div>[[Category:Version Control System]]<br />
{{Related articles start}}<br />
{{Related|Gitolite}}<br />
{{Related|Ruby on Rails}}<br />
{{Related articles end}}<br />
<br />
[http://gitlab.org/ Gitlab] is a free git repository management application based on [[Ruby on Rails]]. It is distributed under the MIT License and its source code can be found on [https://github.com/gitlabhq/gitlabhq Github]. It is a very active project with a monthly release cycle and ideal for businesses that want to keep their code private. Consider it as a self hosted Github but open source. You can try a demo [http://demo.gitlabhq.com/ here].<br />
<br />
== Installation ==<br />
{{Note|If you want to use rvm be sure to check out [[Gitlab#Running GitLab with rvm]] before starting with the installation}}<br />
<br />
{{note|This guide covers installing and configuring GitLab without HTTPS/SSL at first, just to get GitLab up and running. After getting GitLab up and running, see [[#Advanced Configuration]] to set up SSL.}}<br />
<br />
Installing {{AUR|gitlab}} from the [[AUR]] instead of manually has the added benefit that lots of steps have been taken care of for you (e.g. permissions and ownership for files, etc). <br />
<br />
Make sure you perform a system upgrade ({{ic|pacman -Syu}}) before installing gitlab from AUR and that you have installed the {{ic|base-devel}} group, or you may face problems installing gitlab because [https://wiki.archlinux.org/index.php/Makepkg#Usage base-devel packages are not required to be listed as dependencies in PKGBUILD files].<br />
<br />
Also before installing the {{AUR|gitlab}} package from the [[AUR]], you need to choose a database backend if you're planning to host GitLab it on the same machine as the database:<br />
<br />
* Use [[pacman|Pacman]] to install {{Pkg|mariadb}} and {{Pkg|libmariadbclient}} from the [[official repositories]] and start the [[daemon]]<br />
* or install {{Pkg|postgresql}} and {{Pkg|libpqxx}}. Read [[PostgreSQL#Installing_PostgreSQL]] to set it up and start the [[daemon]]. <br />
<br />
In order to receive mail notifications, make sure to install a mail server. By default, Archlinux does not ship with one. The recommended mail server is [[postfix]], but you can use others such as [[SSMTP]], [[msmtp]], [[sendmail]], [https://wiki.archlinux.org/index.php/Category:Mail_Server etc].<br />
<br />
== Configuration ==<br />
<br />
=== Notes Before Configuring ===<br />
The gitlab package from AUR organizes GitLab's files in a manner that more closely follows standard linux conventions rather than installing everything in {{ic|/home/git}} as you are told to do by [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab's official install guide]. <br />
<br />
<br />
After you've installed gitlab from AUR, the config file {{ic|/etc/webapps/gitlab/shell.yml}} corresponds to the file {{ic|/home/git/gitlab-shell/config.yml}} that is mentioned in [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md#4-gitlab-shell GitLab's official install guide when installing gitlab-shell]. The config file {{ic|/etc/webapps/gitlab/gitlab.yml}} corresponds to the file {{ic|/home/git/gitlab/config/gitlab.yml}} that is mentioned in [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md#configure-it GitLab's official install guide when configuring GitLab].<br />
<br />
<br />
Another key difference between gitlab from AUR and the GitLab install guide is that GitLab from AUR uses the {{ic|gitlab}} user with {{ic|/var/lib/gitlab}} as the home folder instead of the {{ic|git}} user with {{ic|/home/git}} as the home folder. This keeps the {{ic|/home}} area clean so it contains only real user homes.<br />
<br />
{{tip|If you are familiar with the [[Arch Build System]] you can edit the PKGBUILD and relevant files to change gitlab's home directory to a place of your liking.}}<br />
<br />
===Basic configuration===<br />
Open up {{ic|/etc/webapps/gitlab/shell.yml}} and set {{ic|gitlab_url:}} to the url where you intend to host GitLab (note the 'http://' and trailing slash). For example, if you will host GitLab at 'yourdomain.com', then it'd look like this:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/shell.yml|<br />
# GitLab user. git by default<br />
user: gitlab<br />
<br />
# Url to gitlab instance. Used for api calls. Should end with a slash.<br />
gitlab_url: "<nowiki>http://yourdomain.com/</nowiki>" # <<-- right here<br />
<br />
http_settings:<br />
# user: someone<br />
# password: somepass<br />
...<br />
}}<br />
<br />
<br />
Open up {{ic|/etc/webapps/gitlab/gitlab.yml}} and edit where needed. In the {{ic|gitlab:}} section set {{ic|host:}} (replacing {{ic|localhost}}) to 'yourdomain.com', your fully qualified domin name (no 'http://' or trailing slash). {{ic|port:}} can be confusing. This is not the port that the gitlab server (unicorn) runs on; it's the port that users will initially access through in their browser. Basically, if you intend for users to visit 'yourdomain.com' in their browser, without appending a port number to the domain name, leave {{ic|port:}} as {{ic|80}}. If you intend your users to type something like 'yourdomain.com:3425' into their browsers, then you'd set {{ic|port:}} to {{ic|3425}} (you'll also have to configure your server (apache, nginx, etc) to listen on that port). Those are the minimal changes needed for a working GitLab install. The adventurous may read on in the comment and customize as needed. For example:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/gitlab.yml|<br />
...<br />
## GitLab settings<br />
gitlab:<br />
## Web server settings<br />
host: yourdomain.com<br />
port: 80<br />
https: false<br />
...<br />
}}<br />
<br />
=== Further configuration ===<br />
<br />
==== Database backend ====<br />
A Database backend will be required before Gitlab can be run. Currently GitLab supports [[MariaDB]] and [[PostgreSQL]]. By default, GitLab assumes you will use MySQL. Extra work is needed if you plan to use PostgreSQL.<br />
<br />
{{note|Don't forget to replace {{ic|your_username_here}} and {{ic|your_password_here}} with your chosen values in the following examples.}}<br />
<br />
==== MariaDB ====<br />
To set up MySQL (MariaDB) you need to create a database called {{ic|gitlabhq_production}} along with a user who has full priviledges to the database. You might do it via command line as in the following example.<br />
<br />
{{bc|mysql -u root -p}}<br />
<br />
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production`;<br />
mysql> CREATE USER 'your_username_here'@'localhost' IDENTIFIED BY 'your_password_here';<br />
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'your_username_here'@'localhost';<br />
mysql> \q<br />
<br />
Now try connecting to the new database with the new user to verify you did it correctly:<br />
<br />
{{bc|mysql -u your_username_here -p -D gitlabhq_production}}<br />
<br />
Next you'll need to open up {{ic|/etc/webapps/gitlab/database.yml}} and set {{ic|username:}} and {{ic|password:}} for the {{ic|gitlabhq_production}} database to {{ic|your_username_here}} and {{ic|your_password_here}}, respectively. You need not worry about the info for the {{ic|gitlabhq_development}} and {{ic|gitlan_test}} databases, as those are not required for our purposes (unless you're feeling adventurous at your own risk). For example:<br />
<br />
{{hc|Snippet from /etc/webapps/gitlab/database.yml|<br />
#<br />
# PRODUCTION<br />
#<br />
production:<br />
adapter: mysql2<br />
encoding: utf8<br />
reconnect: false<br />
database: gitlabhq_production<br />
pool: 10<br />
username: your_username_here<br />
password: "your_password_here"<br />
# host: localhost<br />
# socket: /tmp/mysql.sock<br />
...<br />
}}<br />
<br />
That's all for MySQL configuration.<br />
<br />
For more info and other ways to create/manage MySQL databases, see the [https://mariadb.org/docs/ MariaDB documentation], the [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab official (generic) install guide], and [[phpMyAdmin]].<br />
<br />
==== PostgreSQL ====<br />
Login to PostgreSQL and create the {{ic|gitlabhq_production}} database with along with it's user. Remember to change {{ic|your_username_here}} and {{ic|your_password_here}} to the real values:<br />
<br />
{{bc|psql -d template1}}<br />
<br />
template1=# CREATE USER your_username_here WITH PASSWORD 'your_password_here';<br />
template1=# CREATE DATABASE gitlabhq_production OWNER your_username_here;<br />
template1=# \q<br />
<br />
Try connecting to the new database with the new user to verify it works:<br />
<br />
{{bc|psql -d gitlabhq_production}}<br />
<br />
Copy the PostgreSQL template file before configuring it (overwriting the default MySQL configuration file):<br />
<br />
# cp /usr/share/doc/gitlab/database.yml.postgresql /etc/webapps/gitlab/database.yml<br />
<br />
Open up the new {{ic|/etc/webapps/gitlab/database.yml}} and set the values for {{ic|username:}} and {{ic|password:}}. For example:<br />
<br />
{{hc|Snippet from the new /etc/webapps/gitlab/database.yml|<br />
#<br />
# PRODUCTION<br />
#<br />
production:<br />
adapter: postgresql<br />
encoding: unicode<br />
database: gitlabhq_production<br />
pool: 10<br />
username: your_username_here<br />
password: "your_password_here"<br />
# host: localhost<br />
# port: 5432 <br />
# socket: /tmp/postgresql.sock<br />
...<br />
}}<br />
<br />
For our purposes (unless you know what you're doing), you don't need to worry about configuring the other databases listed in {{ic|/etc/webapps/gitlab/database.yml}}. We only need to set up the production database to get GitLab working.<br />
<br />
Finally, open up {{ic|/usr/lib/systemd/system/gitlab.target}} change all instances of {{ic|mysql.service}} to {{ic|postgresql.service}}. For example:<br />
<br />
{{Accuracy|See [[systemd#Editing provided unit files]] for the correct way.}}<br />
<br />
{{hc|Snippet from /usr/lib/systemd/system/gitlab.target|<br />
...<br />
[Unit]<nowiki><br />
Description=GitLab - Self Hosted Git Management<br />
Requires=redis.service postgresql.service<br />
After=redis.service postgresql.service syslog.target network.target<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki><br />
}}<br />
<br />
<br />
==== Firewall ====<br />
<br />
If you want to give direct access to your Gitlab isntallation through a [[iptables]] firewall you have to the following ACCEPT rule. Change "your_gitlab_port" to your chosen port from above (here we give access to all clients within 192.168.1.0/24 network):<br />
<br />
# iptables -A tcp_inbound -p TCP -s 192.168.1.0/24 --destination-port your_gitlab_port -j ACCEPT <br />
<br />
If you are behind a router, don't forget to forward this port to the running Gitlab server host, too.<br />
<br />
==== Satellites access ====<br />
<br />
Satellites access should be "drwxr-x---":<br />
<br />
# chmod 750 /var/lib/gitlab/satellites<br />
<br />
==== Initialize Gitlab database ====<br />
<br />
Start the Redis server before we create the database:<br />
<br />
# systemctl start redis<br />
# systemctl enable redis<br />
<br />
Then, initialize the database and activate advanced features: <br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab bundle exec rake gitlab:setup RAILS_ENV=production<br />
<br />
Finally, Compile assets.(If you didn't do it,you won't receive data on user/sign_in pages)<br />
<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab -H bundle exec rake assets:precompile RAILS_ENV=production<br />
<br />
==== Configure Git User ====<br />
<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab -H git config --global user.name "GitLab"<br />
# sudo -u gitlab -H git config --global user.email "example@example.com"<br />
<br />
This must match the {{ic|user}} and {{ic|email_from}} defined in {{ic|/usr/share/webapps/gitlab/config/gitlab.yml}}<br />
<br />
==== Adjust modifier bits ====<br />
(The gitlab check won't pass if the user and group ownership isn't configured properly)<br />
<br />
# chmod -R ug+rwX,o-rwx /path/to/repos/<br />
# chmod -R ug-s /path/to/repos<br />
# find /path/to/repos/ -type d -print0 | xargs -O chmod g+s<br />
<br />
== Start and test GitLab ==<br />
<br />
With the following commands we check if the steps we followed so far are configured properly. <br />
<br />
$ cd /usr/share/webapps/gitlab<br />
$ sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production<br />
$ sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production<br />
<br />
{{note|These gitlab:env:info and gitlab:check commands will show a fatal error related to git. This is OK.}}<br />
<br />
{{hc|Example output of sudo -u gitlab bundle exec rake gitlab:env:info <nowiki>RAILS_ENV=production</nowiki>|<br />
fatal: Not a git repository (or any of the parent directories): .git<br />
<br />
System information<br />
System: Arch Linux<br />
Current User: git<br />
Using RVM: yes<br />
RVM Version: 1.20.3<br />
Ruby Version: 2.0.0p0<br />
Gem Version: 2.0.0<br />
Bundler Version:1.3.5<br />
Rake Version: 10.0.4<br />
<br />
GitLab information<br />
Version: 5.2.0.pre<br />
Revision: <br />
Directory: /home/git/gitlab<br />
DB Adapter: mysql2<br />
URL: http://gitlab.arch<br />
HTTP Clone URL: http://gitlab.arch/some-project.git<br />
SSH Clone URL: git@gitlab.arch:some-project.git<br />
Using LDAP: no<br />
Using Omniauth: no<br />
<br />
GitLab Shell<br />
Version: 1.4.0<br />
Repositories: /home/git/repositories/<br />
Hooks: /home/git/gitlab-shell/hooks/<br />
Git: /usr/bin/git<br />
}}<br />
<br />
{{Note| {{ic|gitlab:check}} will complain about missing initscripts. Don't worry, we will use ArchLinux's [[systemd]] to manage server start during boot (which GitLab does not recognize).}}<br />
<br />
{{hc|Example output of sudo -u gitlab bundle exec rake gitlab:check <nowiki>RAILS_ENV=production</nowiki>|<br />
<nowiki>fatal: Not a git repository (or any of the parent directories): .git<br />
Checking Environment ...<br />
<br />
Git configured for gitlab user? ... yes<br />
Has python2? ... yes<br />
python2 is supported version? ... yes<br />
<br />
Checking Environment ... Finished<br />
<br />
Checking GitLab Shell ...<br />
<br />
GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)<br />
Repo base directory exists? ... yes<br />
Repo base directory is a symlink? ... no<br />
Repo base owned by gitlab:gitlab? ... yes<br />
Repo base access is drwxrws---? ... yes<br />
update hook up-to-date? ... yes<br />
update hooks in repos are links: ... can't check, you have no projects<br />
Running /srv/gitlab/gitlab-shell/bin/check<br />
Check GitLab API access: OK<br />
Check directories and files:<br />
/srv/gitlab/repositories: OK<br />
/srv/gitlab/.ssh/authorized_keys: OK<br />
Test redis-cli executable: redis-cli 2.8.4<br />
Send ping to redis server: PONG<br />
gitlab-shell self-check successful<br />
<br />
Checking GitLab Shell ... Finished<br />
<br />
Checking Sidekiq ...<br />
<br />
Running? ... yes<br />
Number of Sidekiq processes ... 1<br />
<br />
Checking Sidekiq ... Finished<br />
<br />
Checking LDAP ...<br />
<br />
LDAP is disabled in config/gitlab.yml<br />
<br />
Checking LDAP ... Finished<br />
<br />
Checking GitLab ...<br />
<br />
Database config exists? ... yes<br />
Database is SQLite ... no<br />
All migrations up? ... fatal: Not a git repository (or any of the parent directories): .git<br />
yes<br />
GitLab config exists? ... yes<br />
GitLab config outdated? ... no<br />
Log directory writable? ... yes<br />
Tmp directory writable? ... yes<br />
Init script exists? ... no<br />
Try fixing it:<br />
Install the init script<br />
For more information see:<br />
doc/install/installation.md in section "Install Init Script"<br />
Please fix the error above and rerun the checks.<br />
Init script up-to-date? ... can't check because of previous errors<br />
projects have namespace: ... can't check, you have no projects<br />
Projects have satellites? ... can't check, you have no projects<br />
Redis version >= 2.0.0? ... yes<br />
Your git bin path is "/usr/bin/git"<br />
Git version >= 1.7.10 ? ... yes (1.8.5)<br />
<br />
Checking GitLab ... Finished<br />
</nowiki><br />
}}<br />
<br />
Make systemd see your new daemon unit files:<br />
<br />
$ systemctl daemon-reload<br />
<br />
After starting the database backend (in this case MySQL), we can start Gitlab with its webserver (Unicorn):<br />
<br />
$ systemctl start redis mysqld gitlab-sidekiq gitlab-unicorn<br />
<br />
Replace {{ic|mysqld}} with {{ic|postgresql}} in the above command if you're using PostgreSQL.<br />
<br />
To automatically launch GitLab at startup, run:<br />
<br />
$ systemctl enable gitlab.target gitlab-sidekiq gitlab-unicorn<br />
<br />
Now test your Gitlab instance by visiting http://localhost:8080 or http://yourdomain.com and login with the default credentials:<br />
username: {{ic|admin@local.host}}<br />
password: {{ic|5iveL!fe}}<br />
<br />
{{note|1=If your browser runs not on the machine where gitlab is running, modify your unocorn.rb in order to be able to test your setup without the use of a proxy. The corresponding line looks like this:<br />
<pre>listen "127.0.0.1:8080, :tcp_nopush => true</pre><br />
you should replace that with:<br />
<pre>listen "examle.yourhost.com:8080, :tcp_nopush => true</pre><br />
}}<br />
<br />
GitLab should now be up and running.<br />
<br />
== Advanced Configuration ==<br />
<br />
=== HTTPS/SSL ===<br />
<br />
==== Change GitLab configs ====<br />
Modify {{ic|/etc/webapps/gitlab/shell.yml}} so the url to your GitLab site starts with {{ic|https://}}.<br />
Modify {{ic|/etc/webapps/gitlab/gitlab.yml}} so that {{ic|https:}} setting is set to {{ic|true}}.<br />
<br />
==== Configure HTTPS server of choice====<br />
<br />
===== Apache =====<br />
{{stub|info needed}}<br />
<br />
===== Node.js =====<br />
You can easily set up an http proxy on port 443 to proxy traffic to the GitLab application on port 8080 using http-master for Node.js. After you've creates your domain's OpenSSL keys and have gotten you CA certificate (or self signed it), then go to https://github.com/CodeCharmLtd/http-master to learn how easy it is to proxy requests to GitLab using HTTPS. http-master is built on top of [https://github.com/nodejitsu/node-http-proxy node-http-proxy].<br />
<br />
===Web server configuration===<br />
If you want to integrate Gitlab into a running web server instead of using its build-in http server Unicorn, then follow these instructions.<br />
<br />
====Nginx and unicorn====<br />
<br />
[[pacman|Install]] {{Pkg|nginx}} from the [[official repositories]].<br />
<br />
Nginx gitlab configuration needs to be copied to nginx configuration directories.<br />
<br />
If you installed GitLab from AUR, do:<br />
<br />
# cp /usr/share/webapps/gitlab/lib/support/nginx/gitlab /etc/nginx/sites-available<br />
<br />
Then edit /usr/share/webapps/gitlab/lib/support/nginx/gitlab and change all path starting from /home/git/gitlab to /usr/share/webapps/gitlab (there are two occurences).<br />
<br />
If you did not use AUR, you need to copy {{ic|/lib/support/nginx/gitlab}} to {{ic|/etc/nginx/sites-available/}}.<br />
<br />
Run these commands to setup nginx:<br />
<br />
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab<br />
<br />
Edit {{ic|/etc/nginx/sites-enabled/gitlab}} and change YOUR_SERVER_IP and YOUR_SERVER_FQDN to the IP address and fully-qualified domain name of the host serving Gitlab.<br />
<br />
Restart gitlab.target, resque.service and nginx.<br />
<br />
====Apache and unicorn====<br />
<br />
[[pacman|Install]] {{Pkg|apache}} from the [[official repositories]]. <br />
<br />
=====Configure Unicorn=====<br />
<br />
{{Note|If the default path is not {{ic|/home/git}} for your installation, change the below path accordingly}}<br />
<br />
As the official installation guide instructs, copy the unicorn configuration file:<br />
# sudo -u git -H cp /home/git/gitlab/config/unicorn.rb.example /home/git/gitlab/config/unicorn.rb<br />
<br />
Now edit {{ic|config/unicorn.rb}} and add a listening port by uncommenting the following line:<br />
listen "127.0.0.1:8080"<br />
<br />
{{Tip| You can set a custom port if you want. Just remember to also include it in Apache's virtual host. See below.}}<br />
<br />
=====Create a virtual host for Gitlab=====<br />
<br />
Create a configuration file for Gitlab’s virtual host and insert the lines below adjusted accordingly. For the ssl section see [[LAMP#SSL]]. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the BalanceMember line.<br />
<br />
You can use these [https://gitlab.com/gitlab-org/gitlab-recipes/blob/079f70dd2c091434a8dd04ed5b1a0d0e937cd361/web-server/apache/gitlab-ssl-apache2.4.conf examples] to get you started.<br />
<br />
=====Enable host and start unicorn=====<br />
<br />
Enable your Gitlab virtual host and reload [[Apache]]:<br />
{{hc|/etc/httpd/conf/httpd.conf| Include /etc/httpd/conf/extra/gitlab.conf}}<br />
<br />
Finally start unicorn:<br />
<br />
# systemctl start gitlab-unicorn<br />
<br />
=== Redis ===<br />
Using a Redis setup different from default (e.g. different address, port, unix socket) requires the environment variable ''REDIS_URL'' to be set accordingly for unicorn. This can be achieved by extending the systemd service file. Create a file ''/etc/systemd/system/gitlab-unicorn.service.d/redis.conf'' that injects the ''REDIS_URL'' environment variable:<br />
[Service]<br />
Environment=REDIS_URL=unix:///run/gitlab/redis.sock<br />
<br />
==Useful Tips==<br />
<br />
===Fix Rake Warning===<br />
When running rake tasks for the gitlab project, this error will occur: {{ic|fatal: Not a git repository (or any of the parent directories): .git}}. This is a bug in bundler, and it can be safely ignored. However, if you want to git rid of the error, the following method can be used:<br />
<br />
{{bc|1=<br />
# cd /usr/share/webapps/gitlab<br />
# sudo -u gitlab git init<br />
# sudo -u gitlab git commit -m "initial commit" --allow-empty<br />
}}<br />
<br />
===Hook into /var===<br />
{{bc|1=<br />
# mkdir -m700 /var/log/gitlab /var/tmp/gitlab<br />
# chown gitlab:gitlab /var/log/gitlab /var/tmp/gitlab<br />
# sudo -u gitlab -i<br />
# cd ~/gitlab<br />
# d=log; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
# d=tmp; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d<br />
}}<br />
<br />
===Hidden options===<br />
Go to Gitlab's home directory:<br />
# cd /usr/share/webapps/gitlab<br />
<br />
and run:<br />
{{hc|<nowiki># rake -T | grep gitlab</nowiki>|<nowiki><br />
rake gitlab:app:check # GITLAB | Check the configuration of the GitLab Rails app<br />
rake gitlab:backup:create # GITLAB | Create a backup of the GitLab system<br />
rake gitlab:backup:restore # GITLAB | Restore a previously created backup<br />
rake gitlab:check # GITLAB | Check the configuration of GitLab and its environment<br />
rake gitlab:cleanup:block_removed_ldap_users # GITLAB | Cleanup | Block users that have been removed in LDAP<br />
rake gitlab:cleanup:dirs # GITLAB | Cleanup | Clean namespaces<br />
rake gitlab:cleanup:repos # GITLAB | Cleanup | Clean repositories<br />
rake gitlab:env:check # GITLAB | Check the configuration of the environment<br />
rake gitlab:env:info # GITLAB | Show information about GitLab and its environment<br />
rake gitlab:generate_docs # GITLAB | Generate sdocs for project<br />
rake gitlab:gitlab_shell:check # GITLAB | Check the configuration of GitLab Shell<br />
rake gitlab:import:all_users_to_all_groups # GITLAB | Add all users to all groups (admin users are added as owners)<br />
rake gitlab:import:all_users_to_all_projects # GITLAB | Add all users to all projects (admin users are added as masters)<br />
rake gitlab:import:repos # GITLAB | Import bare repositories from gitlab_shell -> repos_path into GitLab project instance<br />
rake gitlab:import:user_to_groups[email] # GITLAB | Add a specific user to all groups (as a developer)<br />
rake gitlab:import:user_to_projects[email] # GITLAB | Add a specific user to all projects (as a developer)<br />
rake gitlab:satellites:create # GITLAB | Create satellite repos<br />
rake gitlab:setup # GITLAB | Setup production application<br />
rake gitlab:shell:build_missing_projects # GITLAB | Build missing projects<br />
rake gitlab:shell:install[tag,repo] # GITLAB | Install or upgrade gitlab-shell<br />
rake gitlab:shell:setup # GITLAB | Setup gitlab-shell<br />
rake gitlab:sidekiq:check # GITLAB | Check the configuration of Sidekiq<br />
rake gitlab:test # GITLAB | Run all tests<br />
rake gitlab:web_hook:add # GITLAB | Adds a web hook to the projects<br />
rake gitlab:web_hook:list # GITLAB | List web hooks<br />
rake gitlab:web_hook:rm # GITLAB | Remove a web hook from the projects<br />
rake setup # GITLAB | Setup gitlab db<br />
</nowiki>}}<br />
<br />
===Backup and restore===<br />
<br />
Create a backup of the gitlab system:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create<br />
<br />
Restore the previously created backup file {{ic|/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar}}:<br />
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740<br />
<br />
{{Note| Backup folder is set in {{ic|config/gitlab.yml}}. GitLab backup and restore is documented [https://github.com/gitlabhq/gitlabhq/blob/master/doc/raketasks/backup_restore.md here].}}<br />
<br />
===Migrate from sqlite to mysql===<br />
<br />
Get latest code as described in [[#Update_Gitlab]].<br />
Save data.<br />
# cd /home/gitlab/gitlab<br />
# sudo -u gitlab bundle exec rake db:data:dump RAILS_ENV=production<br />
<br />
Follow [[#Mysql]] instructions and then setup the database.<br />
# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production<br />
<br />
Finally restore old data.<br />
# sudo -u gitlab bundle exec rake db:data:load RAILS_ENV=production<br />
<br />
===Running GitLab with rvm===<br />
<br />
To run gitlab with rvm first you have to set up an rvm:<br />
<br />
curl -L https://get.rvm.io | bash -s stable --ruby=1.9.3<br />
<br />
{{Note|Version 1.9.3 is currently recommended to avoid some compatibility issues.}}<br />
<br />
For the complete installation you will want to be the final user (e.g. {{ic|git}}) so make sure to switch to this user and activate your rvm:<br />
<br />
su - git<br />
source "$HOME/.rvm/scripts/rvm"<br />
<br />
Then continue with the installation instructions from above. However, the systemd scripts will not work this way, because the environment for the rvm is not activated. The recommendation here is to create to separate shell scripts for {{ic|puma}} and {{ic|sidekiq}} to activate the environment and then start the service:<br />
<br />
{{hc|gitlab.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
RAILS_ENV=production bundle exec puma -C "/home/git/gitlab/config/puma.rb"</nowiki><br />
}}<br />
<br />
{{hc|sidekiq.sh|<nowiki><br />
#!/bin/sh<br />
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`<br />
case $1 in<br />
start)<br />
bundle exec rake sidekiq:start RAILS_ENV=production<br />
;;<br />
stop)<br />
bundle exec rake sidekiq:stop RAILS_ENV=production<br />
;;<br />
*)<br />
echo "Usage $0 {start|stop}"<br />
esac<br />
</nowiki>}}<br />
<br />
Then modify the above systemd files so they use these scripts. Modify the given lines:<br />
<br />
{{hc|gitlab.service|<nowiki><br />
ExecStart=/home/git/bin/gitlab.sh<br />
</nowiki>}}<br />
{{hc|sidekiq.service|<nowiki><br />
ExecStart=/home/git/bin/sidekiq.sh start<br />
ExecStop=/home/git/bin/sidekiq.sh stop<br />
</nowiki>}}<br />
<br />
==Troubleshooting==<br />
<br />
Sometimes things may not work as expected. Be sure to visit the [https://github.com/gitlabhq/gitlab-public-wiki/wiki/Trouble-Shooting-Guide Trouble Shooting Guide].<br />
<br />
=== HTTPS is not green (gravatar not using https) ===<br />
Redis caches gravatar images, so if you've visited your GitLab with http, then enabled https, gravatar will load up the non-secure images. You can clear the cache by doing<br />
<br />
cd /usr/share/webapps/gitlab; bundle exec rake cache:clear<br />
<br />
as the gitlab user.<br />
<br />
==See also==<br />
*[https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md Official Documentation]<br />
*[https://gitlab.com/gitlab-org/gitlab-recipes Gitlab recipes with further documentation on running it with several webservers]</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=Squid&diff=307723Squid2014-03-31T02:57:15Z<p>Imranhaider: /* iptables */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Proxy servers]]<br />
[[ru:Squid]]<br />
[[zh-CN:Squid]]<br />
{{poor writing}}<br />
<br />
From the squid [http://www.squid-cache.org website]:<br />
<br />
:''Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. It reduces bandwidth and improves response times by caching and reusing frequently-requested web pages. Squid has extensive access controls and makes a great server accelerator. It runs on Unix and Windows and is licensed under the GNU GPL.''<br />
<br />
While squid works wonderfully in large corporations and schools, it can also benefit the home user too. However, if you're looking for a more lightweight single-user proxy, you should try [[Polipo]].<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] {{Pkg|squid}} available in the [[Official repositories]].<br />
<br />
== Configuration ==<br />
<br />
By default, the cache directories will be created in {{ic|/var/cache/squid}}, and the appropriate permissions set up for those directories. However, for greater control, we need to delve into {{Ic|/etc/squid/squid.conf}}.<br />
<br />
Everything is well commented, but if you want to strip the comments out you should run:<br />
<br />
sed -i "/^#/d;/^ *$/d" /etc/squid/squid.conf<br />
<br />
The following options might be of some use to you. If you do not have the option present in your configuration file, add it!<br />
<br />
* {{Ic|http_port}} - Sets the port that Squid binds to on your local machine. You can have Squid bind to multiple ports by specifying multiple http_port lines. By default, Squid binds to port 3128.<br />
http_port 3128<br />
http_port 3129<br />
* {{Ic|http_access}} - This is an access control list for who is allowed to use the proxy. By default only localhost is allowed to access the proxy. For testing purposes, you may want to change the option {{Ic|http_access deny all}} to {{Ic|http_access allow all}}, which will allow anyone to connect to your proxy. If you wanted to just allow access to your subnet, you can do:<br />
acl ip_acl src 192.168.1.0/24<br />
http_access allow ip_acl<br />
http_access deny all<br />
*{{Ic|cache_mgr}} - This is the email address of the cache manager.<br />
cache_mgr squid.admin@example.com<br />
*{{Ic|shutdown_lifetime}} - Specifies how long Squid should wait when its service is asked to stop. If you're running squid on your desktop PC, you may want to set this to something short.<br />
shutdown_lifetime 10 seconds<br />
*{{Ic|cache_mem}} - This is how much memory you want Squid to use to keep objects in memory rather than writing them to disk. Squid's total memory usage will exceed this! By default this is 8MB, so you might want to increase it if you have lots of RAM available.<br />
cache_mem 64 MB<br />
*{{Ic|visible_hostname}} - hostname that will be shown in status/error messages<br />
visible_hostname cerberus<br />
*{{Ic|cache_peer}} - If you want your Squid to go through another proxy server, rather than directly out to the Internet, you need to specify it here.<br />
*{{Ic|login}} - Use this option if the parent proxy requires authentication.<br />
*{{Ic|never_direct}} - Tells the cache to never go direct to the internet to retrieve a page. You will want this if you have set the option above.<br />
cache_peer 10.1.1.100 parent 8080 0 no-query default login=user:password<br />
never_direct allow all<br />
*{{Ic|maximum_object_size}} - The largest size of a cached object. By default this is small (256KB I think), so if you have a lot of disk space you will want to increase the size of it to something reasonable.<br />
maximum_object_size 10 MB<br />
{{Note|After defining a new cache_dir it maybe necessary to initialize the caches directory structure with this command: <code>squid -zN</code> -z for Create missing swap directories and -N for No daemon mode. }}<br />
*{{Ic|cache_dir}} - This is your cache directory, where all the cached files are stored. There are many options here, but the format should generally go like:<br />
cache_dir <storage type> <directory> <size in MB> 16 256<br />
So, in the case of a school's internet proxy:<br />
cache_dir diskd /cache0 200000 16 256<br />
If you change the cache directory from defaults, you must set the correct permissions on the cache directory before starting Squid, else it won't be able to create its cache directories and will fail to start.<br />
<br />
== Accessing services on local hostnames ==<br />
<br />
If you plan to access web servers on the LAN using hostnames that are not fully-defined (e.g. {{ic|http://mywebapp}}), you may need to enable the {{ic|dns_defnames}} option. Without this option, Squid will make a DNS request for the hostname verbatim ({{ic|mywebapp}}), which may fail, depending on your LAN's DNS setup. With the option enabled, Squid will append any domain configured in {{ic|/etc/resolv.conf}} when making the request (e.g. {{ic|mywebapp.company.local}}).<br />
<br />
{{bc|<br />
dns_defnames on<br />
}}<br />
<br />
== Starting ==<br />
<br />
Once you have finished your configuration, you should check that your configuration file is correct:<br />
# squid -k check<br />
Then create your cache directories:<br />
# squid -z<br />
Then you can start Squid!<br />
# systemctl start squid<br />
<br />
To start squid on boot use this command:<br />
# systemctl enable squid<br />
<br />
== Content Filtering ==<br />
<br />
If you're looking for a content filtering solution to work with Squid, you should check out the very powerful [[DansGuardian]].<br />
<br />
== Frontend ==<br />
<br />
If you'd like a web-based frontend for managing Squid, [[Webmin]] is your best bet.<br />
<br />
== Ad blocking with adzapper ==<br />
<br />
Adzapper is a plugin for Squid. It catches ads of all sorts (even Flash animations) and replaces them with an image of your choice, so the layout of the page isn't altered very much. <br />
<br />
=== Installation ===<br />
Adzapper is no longer in the community repository, but it can be found in the [[AUR]].<br />
<br />
=== Configuration ===<br />
echo "redirect_program /usr/bin/adzapper.wrapper" >> /etc/squid/squid.conf<br />
<br />
(squid 2.6.STABLE13-1)<br />
<br />
echo "url_rewrite_program /usr/bin/adzapper.wrapper" >> /etc/squid/squid.conf<br />
echo "url_rewrite_children 10" >> /etc/squid/squid.conf<br />
<br />
If you want, you can configure adzapper to your liking. The configuration out of the box works wonderfully well though.<br />
nano /etc/adzapper/adzapper.conf<br />
<br />
== Anti-virus layer ==<br />
<br />
Adding Anti-virus capabilities to Squid is done using the HAVP program to interface it with ClamAV.<br />
<br />
=== Installing dependencies ===<br />
<br />
Follow [[ClamAV]] to install ClamAV on your system. When it is installed, install {{AUR|havp}} from [[AUR]].<br />
<br />
=== Configuration ===<br />
<br />
Once HAVP is installed, create a user group for the HAVP instance:<br />
useradd havp<br />
<br />
Change the owner of the antivirus logs and temporary file-testing directories to havp :<br />
chown -R havp:havp /var/run/havp<br />
chown -R havp:havp /var/log/havp<br />
<br />
Add the mandatory lock option to your filesystem (needed by HAVP) : In your /etc/fstab, modify :<br />
[...] / ext3 defaults 1 1<br />
to :<br />
[...] / ext3 defaults,mand 1 1<br />
<br />
Then reload your filesystem :<br />
mount -o remount /<br />
<br />
Add this info in your /etc/squid/squid.conf :<br />
cache_peer 127.0.0.1 parent 8080 0 no-query no-digest no-netdb-exchange default<br />
cache_peer_access 127.0.0.1 allow all<br />
<br />
Make sure your port in your /etc/havp/havp.config matches the cache_peer port in /etc/squid/squid.conf.<br />
<br />
=== Testing ===<br />
Reload your squid and start HAVP:<br />
systemctl restart squid<br />
systemctl start havp<br />
<br />
Don't forget to add HAVP to your rc.conf if your want it to launch on boot :<br />
systemctl enable squid<br />
systemctl enable havp<br />
<br />
You can try the antivirus capabilities with a test virus (not a real virus) available [http://www.eicar.org/anti_virus_test_file.htm here].<br />
<br />
== Transparent web proxy ==<br />
Transparency happens by redirecting all www requests eth0 picks up, to Squid. You'll need to indicate Squid that it is running like a transparent web proxy by adding the {{Ic|intercept}} (for squid 3.2) parameter to the {{Ic|http_port}} option:<br />
http_port 3128 '''intercept'''<br />
<br />
=== iptables ===<br />
From a terminal with root privileges, run: <br />
# gid=`id -g proxy`<br />
# iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner --gid-owner $gid -j ACCEPT<br />
# iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination SQUIDIP:3128<br />
# iptables-save > /etc/iptables/iptables.rules<br />
<br />
Then start Iptables:<br />
# systemctl start iptables.service<br />
<br />
Replace SQUIDIP with the public IP(s) which squid may use for its listening port and outbound connections.<br />
<br />
{{Note|If you are using a content filtering solution, you should put the port for it, not the Squid port, and you need to remove the {{Ic|intercept}} option in the http_port line.}}<br />
<br />
=== Shorewall ===<br />
Edit /etc/shorewall/rules and add<br />
REDIRECT loc 3128 tcp www # redirect to Squid on port 3128<br />
ACCEPT $FW net tcp www # allow Squid to fetch the www content<br />
<br />
systemctl restart shorewall<br />
<br />
== HTTP Authentication ==<br />
<br />
Squid can be configured to require a user and password in order to use it. We will use [[wikipedia:Digest_access_authentication|digest http auth]]<br />
<br />
First create a users file with {{Ic|htdigest -c /etc/squid/users MyRealm username}}. Enter a password when prompted.<br />
<br />
Then add these lines to your {{Ic|squid.conf}}:<br />
<br />
auth_param digest program /usr/lib/squid/digest_file_auth -c /etc/squid/users<br />
auth_param digest children 5<br />
auth_param digest realm MyRealm<br />
<br />
acl users proxy_auth REQUIRED<br />
http_access allow users<br />
<br />
And restart squid. Now you will be prompted to enter a username and password when accessing the proxy.<br />
<br />
You can add more users with {{Ic|htdigest /etc/squid/users MyRealm newuser}}. You probably would like to install Apache package, which contains {{Ic|htdigest}} tool.<br />
<br />
{{Note|Be aware that {{Ic|http_access}} rules cascade, so you need to set them in the desired order.}}<br />
<br />
=== NTLM ===<br />
<br />
{{Warning|NTLM is deprecated and has security problems.}}<br />
<br />
Set up [[samba]] and winbindd and test it with<br />
ntlm_auth --username=DOMAIN\\user<br />
<br />
Grant r-x access to /var/cache/samba/winbindd_privileged/ directory for squid user/group<br />
<br />
Then add something like this to squid.conf:<br />
<br />
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp<br />
auth_param ntlm children 5<br />
auth_param ntlm max_challenge_reuses 0<br />
auth_param ntlm max_challenge_lifetime 2 minutes<br />
auth_param ntlm keep_alive off<br />
<br />
acl ntlm_users proxy_auth REQUIRED<br />
http_access allow ntlm_users<br />
http_access deny all<br />
<br />
== Additional Resources ==<br />
* [http://gotux.net/arch-linux/squid-proxy-server/ Elite Proxy Config Example]</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Reports&diff=306784ArchWiki talk:Reports2014-03-23T20:22:19Z<p>Imranhaider: /* Chromium development */</p>
<hr />
<div>In this page you can list:<br />
* Edits that a contributor made to the wiki without a proper explanation (that is what the Summary field is for) and whose validity you lack the knowledge to judge by yourself. In this case, please add a link to the edit in question with a brief explanation why you think it should be investigated. Consider contacting the contributor to ask for an explanation, which is often an effective way to solve these issues. Please report the eventual answer (if any) below the initial report. You can also link to a discussion already started in the talk page of the edited article.<br />
* Links to discussions started in talk pages requesting to add, delete, or modify some content in the respective articles which you do not have sufficient knowledge to answer definitively by yourself.<br />
<br />
Please sign your edits and feel free to comment on others' reports. Discussions will be deleted 3 days after closing.<br />
<br />
See [[ArchWiki:Spam]] to report vandalism.<br />
<br />
__TOC__<br />
==New templates==<br />
Just a heads-up, if you're OK with them [https://wiki.archlinux.org/index.php?title=Template:Yes&diff=174109&oldid=0] [https://wiki.archlinux.org/index.php?title=Template:No&diff=174107&oldid=0] , please close the report :-) -- [[User:Karol|Karol]] 07:42, 14 December 2011 (EST)<br />
:If we start applying them consistently in all the tables, probably adding a proper rule in [[Help:Style]], then I'm ok with them, since coloring cells in tables is not very straightforward even with wiki syntax.<br />
:Note their Chinese counterparts have been created too: [[Template:是]] and [[Template:否]]. Since those templates' code is very flexible, I suggest replacing them with only 2 templates, [[Template:Y]] and [[Template:N]], which would produce "Yes" and "No" by default, but whose first optional argument would allow them to display any other string, including translations, without the need to have localized versions of each template.<br />
:Going even a bit further, since some tables use additional colors, we may base the templates' names on their color instead of their meaning, so that we would have [[Template:G]], [[Template:R]], [[Template:Y]], [[Template:B]], and if necessary also [[Template:P]] and [[Template:O]] (purple and orange, just to complete the secondary colors). These templates should require the first argument, but I think they would be easy to use anyway, for sure much easier than the current | style="color:...." | blabla.<br />
:Waiting for opinions. -- [[User:Kynikos|Kynikos]] 09:19, 15 December 2011 (EST)<br />
:This template group would also give us an excuse to delete [[The Status Table Series]] and related templates, since they have a too narrow field of application and practically just create nested tables in the end, thus giving almost no real advantage. -- [[User:Kynikos|Kynikos]] 13:13, 24 December 2011 (EST)<br />
::I support this idea. Similar to the [[Template:Box]] '''COLOUR''' templates, a series of table cell coloured templates would ensure consistency across articles. -- [[User:Pointone|pointone]] 16:46, 19 January 2012 (EST)<br />
:::So good :) However I don't consider this an urgent task, I'm linking this discussion from a new entry among my numerous template ideas in my [[User:Kynikos/Tasks|todo list]]. Of course if you or someone else want to implement it, just go for it. Just reminding that the implementation should be accompanied by some related style rules.<br />
:::Also note that among my template-related ideas there's one about the Box COLOR series that seems to go in the opposite direction than the cell color templates, but I think that the colors for the Note, Warning and Tip templates should be reserved for them, and not be usable in other ways.<br />
:::-- [[User:Kynikos|Kynikos]] 06:47, 20 January 2012 (EST)<br />
<br />
== Jumbo frames' "Real World Examples" section ==<br />
<br />
[[Jumbo_Frames#Real_World_Examples]] <-- This section doesn't seem fitting on our wiki. This section just seems to be an advertisement for jumbo frames, and I think it should be removed. And I should also note that the methodology is a bit unreliable, in my opinion. To truly test ''just'' the difference that jumbo frames makes, one should make a RAM disk so hard disk performance is completely removed from the equation. And if we really want to sell people on switching to jumbo frames, I would rather we simply provide a one-liner plus a link to a technical white paper, IEEE conference paper, etc.<br />
Does anyone else agree? <br><br />
-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 21:59, 4 June 2012 (UTC)<br />
<br />
:Well, I don't know if we can really consider that section as an advertisement, however it's true that benchmarking sections are not really Arch-specific, and would probably better fit a blog or some other kind of website, which could be linked from the article. A similar article is [[SSD Benchmarking]], for example.<br />
:On the other hand it looks like an original work and I would hesitate a bit before simply deleting it, maybe moving the "Using Jumbo Frames on Arch Linux" section more to the top could be a start. [[User:Graysky]] seems to have added that section in 2009, he may be interested in discussing also about the reliability of the methodology, but I would do that in [[Talk:Jumbo Frames]] (possibly adding e.g. [[Template:Accuracy]] to the article), since this talk page is more used for discussing recent changes reports :)<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:26, 5 June 2012 (UTC)<br />
<br />
::Another alternative would be moving it to a sub-page, and having a link to it somewhere in the article.<br />
::-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 15:14, 7 June 2012 (UTC)<br />
<br />
:I just found this discussion. I do not feel that the examples I posted represent an advertisement in any way. They do represent a concrete example of leveraging the topic of the page on which they are written. They are a bit dated however. I agree with the RAM disk suggestion. If I get dome time over the weekend, I might update on more modern hardware under more controlled conditions.<br />
:-- [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 01:39, 12 October 2012 (UTC)<br />
<br />
== Pacnew_and_Pacsave_Files report ==<br />
Original quick report:<br />
:[https://wiki.archlinux.org/index.php?title=Pacnew_and_Pacsave_Files&curid=3629&diff=294370&oldid=286538]: what was wrong with the old script that was replaced?<br />
<br />
I think [https://wiki.archlinux.org/index.php?title=Pacnew_and_Pacsave_Files&curid=3629&diff=294370&oldid=286538 the edit in question] added just some error-checking and dependency-checking. As pacnew and pacidff files are often edited as root or with sudo, the script does additional check for that. I don't think it's a questionable edit. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 18:08, 1 February 2014 (UTC)<br />
<br />
:Honestly the only parts of the new script that I like are the diffed variable that makes it easier to change it to the preferred merge tool, and the pacsave alert at the end. About the rest, I think that always checking for the availability of the required programs (~1/3 of the script) is complete overkill for such a little script: it's uselessly run every time while it could be much more ''Simply'' left to the user, who is supposed to know what applications (s)he has installed; I think mentioning the required packages in the section intro would be more appropriate. Then there's the problem of replacing gksudo with plain sudo, which IIRC at least until some time ago was a discouraged practice. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:08, 2 February 2014 (UTC)<br />
<br />
== "Issue" -> "problem" updates ==<br />
<br />
I don't know what to think about [[User:Notasynonym]], every [[Special:Contributions/Notasynonym|contribution]] of this user (fortunately they are not ''that'' many) is just a replacement of "issue" with "problem" (and modifications for plural). Are those valid edits? I find it rather uncomfortable... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:40, 11 February 2014 (UTC)<br />
<br />
:I'm not a native English speaker, my only guess is that he's doing it because "problem" is a more specific word, while "issue" can have other meanings. Maybe we can ask him? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:27, 12 February 2014 (UTC)<br />
<br />
::The name of the account suggests that the propaganda is ''"issue" and "problem" are not synonyms'', which I just can't accept - even Github has [https://github.com/blog/411-github-issue-tracker issue pages]. I think that in IT it cannot be confused with the [http://dictionary.reference.com/browse/issue other meanings]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:14, 12 February 2014 (UTC)<br />
<br />
:::I've invited him to join this discussion. However I'd appreciate if also a third-party native English speaker shared his/her feelings about this <s>issue</s>... <s>problem</s>... matter! -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:58, 13 February 2014 (UTC)<br />
<br />
::::I'm a native English speaker. "issue" and "problem" are only synonyms in certain contexts. As a general rule of thumb, every "problem" is an "issue", but not every "issue" is a "problem".<br />
::::Using [[User:Lahwaacz]]'s GitHub example, GitHub chose the proper word for their system because GitHub's issue tracker is for reporting bugs, requesting new features, logging pull requests, asking general questions, etc. Of those, only bug reports are both "problems" ''and'' "issues"; the rest are simply "issues".<br />
::::I skimmed over a couple of [[User:Notasynonym]] edit's. Of those I checked, they seem okay because the instances where he changed "issue" to "problem" are in the context of bugs or troubleshooting problems. I would have a major problem (hehe) with anyone blindly doing a search-and-replace of "issue" to "problem", but it does not appear that he is doing this.<br />
::::Hope this helps!<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:27, 14 February 2014 (UTC)<br />
<br />
:::::Thanks Jstjohn, I too think that those edits are acceptable. When patrolling them, I didn't pay attention to [[User:Notasynonym]]'s username, which is probably the main reason that has made Lahwaacz suspicious: using "propaganda" usernames is indeed common practice among trolls, and still I don't understand why this user is using a separate account for this kind of edits, as if he thought himself they could generate criticism. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 00:51, 15 February 2014 (UTC)<br />
<br />
== Chromium development ==<br />
<br />
Original report:<br />
<br />
:[https://wiki.archlinux.org/index.php?title=Chromium_development&oldid=299458 Chromium development] -- 2014-02-25&nbsp;00:14:52 -- content -- Needs to be categorized, the installation and setup instructions need some straightening up.<br />
<br />
I am not even sure what is the purpose of that page - there is {{AUR|chromium-devel}} (linked from [[Chromium]]), which makes things much simpler (assuming it works). Also note that the page describes several bad practises: editing {{ic|/usr/bin/python}} with custom script to force python3, exporting necessary variables directly from {{ic|.bashrc}} etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:49, 8 March 2014 (UTC)<br />
<br />
:It's probably better to invite [[User:Imranhaider|the author]] to explain here, or move this discussion to [[Talk:Chromium development]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:12, 9 March 2014 (UTC)<br />
<br />
::The purpose of this page is to set up a development environment where someone can edit and run a modified version of chromium. {{AUR|chromium-devel}} is good for building and installing chromium from source but it's not an ideal way for you to do development work on it.<br />
::There is no mention of editing {{ic|/usr/bin/python}} in the page. There is a reference to adding {{ic|~/bin/python}} to blacklist certain python scripts from running python3. It does not modify the original binary in any way.<br />
::What's wrong with exporting variables from {{ic|.bashrc}}? -- ([[User talk:Imranhaider|Imran]] 23:01, 22 March 2014 (UTC)<br />
<br />
::: Read [http://linuxtidbits.wordpress.com/2012/02/15/bashrc/#comment-7211 the comment by Tom Hallam]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 23:59, 22 March 2014 (UTC)<br />
<br />
:::You ''can'' do development using {{AUR|chromium-dev}} ({{AUR|chromium-devel}} does not exist, my mistake...): pass {{ic|-e}} flag to [[makepkg]] to keep the existing {{ic|$srcdir}} (keeping your development work, applied patches etc.). See {{ic|makepkg(8)}} for other useful flags. You don't have to install the package, just ''cd'' into the build dir and run the compiled binaries (this is what you suggest in [[Chromium development]] anyway).<br />
:::If this is not convenient, you should extract the {{ic|build()}} function from the {{AUR|chromium-dev}}'s PKGBUILD into a separate script and run that for building chromium. Especially, you should use the build flags from {{AUR|chromium-dev}} (and keep the custom build script in sync with PKGBUILD), they avoid some bugs.<br />
:::For the completely manual way, there is http://code.google.com/p/chromium/wiki/LinuxBuildInstructions - IMO no need to duplicate it on Arch Wiki. While it is a good step-by-step guide, for regular use most devs will probably write their custom build script to keep their working environment clean and building process fast.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:12, 23 March 2014 (UTC)<br />
<br />
::::That's interesting. I didn't know you can tell [[makepkg]] to keep the source tree. Good to know. http://code.google.com/p/chromium/wiki/LinuxBuildInstructions is good but in some places of the instructions, it assumes that you are using Ubuntu. I don't think we need this page anymore as it's already possible to use [[makepkg]]. I couldn't find a way to delete the wiki page. Can you delete it and/or tell me how I can delete it? Thanks -- ([[User talk:Imranhaider|Imran]] 20:22, 23 March 2014 (UTC)</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Reports&diff=306664ArchWiki talk:Reports2014-03-22T23:02:43Z<p>Imranhaider: /* Chromium development */</p>
<hr />
<div>In this page you can list:<br />
* Edits that a contributor made to the wiki without a proper explanation (that is what the Summary field is for) and whose validity you lack the knowledge to judge by yourself. In this case, please add a link to the edit in question with a brief explanation why you think it should be investigated. Consider contacting the contributor to ask for an explanation, which is often an effective way to solve these issues. Please report the eventual answer (if any) below the initial report. You can also link to a discussion already started in the talk page of the edited article.<br />
* Links to discussions started in talk pages requesting to add, delete, or modify some content in the respective articles which you do not have sufficient knowledge to answer definitively by yourself.<br />
<br />
Please sign your edits and feel free to comment on others' reports. Discussions will be deleted 3 days after closing.<br />
<br />
See [[ArchWiki:Spam]] to report vandalism.<br />
<br />
__TOC__<br />
==New templates==<br />
Just a heads-up, if you're OK with them [https://wiki.archlinux.org/index.php?title=Template:Yes&diff=174109&oldid=0] [https://wiki.archlinux.org/index.php?title=Template:No&diff=174107&oldid=0] , please close the report :-) -- [[User:Karol|Karol]] 07:42, 14 December 2011 (EST)<br />
:If we start applying them consistently in all the tables, probably adding a proper rule in [[Help:Style]], then I'm ok with them, since coloring cells in tables is not very straightforward even with wiki syntax.<br />
:Note their Chinese counterparts have been created too: [[Template:是]] and [[Template:否]]. Since those templates' code is very flexible, I suggest replacing them with only 2 templates, [[Template:Y]] and [[Template:N]], which would produce "Yes" and "No" by default, but whose first optional argument would allow them to display any other string, including translations, without the need to have localized versions of each template.<br />
:Going even a bit further, since some tables use additional colors, we may base the templates' names on their color instead of their meaning, so that we would have [[Template:G]], [[Template:R]], [[Template:Y]], [[Template:B]], and if necessary also [[Template:P]] and [[Template:O]] (purple and orange, just to complete the secondary colors). These templates should require the first argument, but I think they would be easy to use anyway, for sure much easier than the current | style="color:...." | blabla.<br />
:Waiting for opinions. -- [[User:Kynikos|Kynikos]] 09:19, 15 December 2011 (EST)<br />
:This template group would also give us an excuse to delete [[The Status Table Series]] and related templates, since they have a too narrow field of application and practically just create nested tables in the end, thus giving almost no real advantage. -- [[User:Kynikos|Kynikos]] 13:13, 24 December 2011 (EST)<br />
::I support this idea. Similar to the [[Template:Box]] '''COLOUR''' templates, a series of table cell coloured templates would ensure consistency across articles. -- [[User:Pointone|pointone]] 16:46, 19 January 2012 (EST)<br />
:::So good :) However I don't consider this an urgent task, I'm linking this discussion from a new entry among my numerous template ideas in my [[User:Kynikos/Tasks|todo list]]. Of course if you or someone else want to implement it, just go for it. Just reminding that the implementation should be accompanied by some related style rules.<br />
:::Also note that among my template-related ideas there's one about the Box COLOR series that seems to go in the opposite direction than the cell color templates, but I think that the colors for the Note, Warning and Tip templates should be reserved for them, and not be usable in other ways.<br />
:::-- [[User:Kynikos|Kynikos]] 06:47, 20 January 2012 (EST)<br />
<br />
== Jumbo frames' "Real World Examples" section ==<br />
<br />
[[Jumbo_Frames#Real_World_Examples]] <-- This section doesn't seem fitting on our wiki. This section just seems to be an advertisement for jumbo frames, and I think it should be removed. And I should also note that the methodology is a bit unreliable, in my opinion. To truly test ''just'' the difference that jumbo frames makes, one should make a RAM disk so hard disk performance is completely removed from the equation. And if we really want to sell people on switching to jumbo frames, I would rather we simply provide a one-liner plus a link to a technical white paper, IEEE conference paper, etc.<br />
Does anyone else agree? <br><br />
-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 21:59, 4 June 2012 (UTC)<br />
<br />
:Well, I don't know if we can really consider that section as an advertisement, however it's true that benchmarking sections are not really Arch-specific, and would probably better fit a blog or some other kind of website, which could be linked from the article. A similar article is [[SSD Benchmarking]], for example.<br />
:On the other hand it looks like an original work and I would hesitate a bit before simply deleting it, maybe moving the "Using Jumbo Frames on Arch Linux" section more to the top could be a start. [[User:Graysky]] seems to have added that section in 2009, he may be interested in discussing also about the reliability of the methodology, but I would do that in [[Talk:Jumbo Frames]] (possibly adding e.g. [[Template:Accuracy]] to the article), since this talk page is more used for discussing recent changes reports :)<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:26, 5 June 2012 (UTC)<br />
<br />
::Another alternative would be moving it to a sub-page, and having a link to it somewhere in the article.<br />
::-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 15:14, 7 June 2012 (UTC)<br />
<br />
:I just found this discussion. I do not feel that the examples I posted represent an advertisement in any way. They do represent a concrete example of leveraging the topic of the page on which they are written. They are a bit dated however. I agree with the RAM disk suggestion. If I get dome time over the weekend, I might update on more modern hardware under more controlled conditions.<br />
:-- [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 01:39, 12 October 2012 (UTC)<br />
<br />
== Pacnew_and_Pacsave_Files report ==<br />
Original quick report:<br />
:[https://wiki.archlinux.org/index.php?title=Pacnew_and_Pacsave_Files&curid=3629&diff=294370&oldid=286538]: what was wrong with the old script that was replaced?<br />
<br />
I think [https://wiki.archlinux.org/index.php?title=Pacnew_and_Pacsave_Files&curid=3629&diff=294370&oldid=286538 the edit in question] added just some error-checking and dependency-checking. As pacnew and pacidff files are often edited as root or with sudo, the script does additional check for that. I don't think it's a questionable edit. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 18:08, 1 February 2014 (UTC)<br />
<br />
:Honestly the only parts of the new script that I like are the diffed variable that makes it easier to change it to the preferred merge tool, and the pacsave alert at the end. About the rest, I think that always checking for the availability of the required programs (~1/3 of the script) is complete overkill for such a little script: it's uselessly run every time while it could be much more ''Simply'' left to the user, who is supposed to know what applications (s)he has installed; I think mentioning the required packages in the section intro would be more appropriate. Then there's the problem of replacing gksudo with plain sudo, which IIRC at least until some time ago was a discouraged practice. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:08, 2 February 2014 (UTC)<br />
<br />
== "Issue" -> "problem" updates ==<br />
<br />
I don't know what to think about [[User:Notasynonym]], every [[Special:Contributions/Notasynonym|contribution]] of this user (fortunately they are not ''that'' many) is just a replacement of "issue" with "problem" (and modifications for plural). Are those valid edits? I find it rather uncomfortable... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:40, 11 February 2014 (UTC)<br />
<br />
:I'm not a native English speaker, my only guess is that he's doing it because "problem" is a more specific word, while "issue" can have other meanings. Maybe we can ask him? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:27, 12 February 2014 (UTC)<br />
<br />
::The name of the account suggests that the propaganda is ''"issue" and "problem" are not synonyms'', which I just can't accept - even Github has [https://github.com/blog/411-github-issue-tracker issue pages]. I think that in IT it cannot be confused with the [http://dictionary.reference.com/browse/issue other meanings]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:14, 12 February 2014 (UTC)<br />
<br />
:::I've invited him to join this discussion. However I'd appreciate if also a third-party native English speaker shared his/her feelings about this <s>issue</s>... <s>problem</s>... matter! -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:58, 13 February 2014 (UTC)<br />
<br />
::::I'm a native English speaker. "issue" and "problem" are only synonyms in certain contexts. As a general rule of thumb, every "problem" is an "issue", but not every "issue" is a "problem".<br />
::::Using [[User:Lahwaacz]]'s GitHub example, GitHub chose the proper word for their system because GitHub's issue tracker is for reporting bugs, requesting new features, logging pull requests, asking general questions, etc. Of those, only bug reports are both "problems" ''and'' "issues"; the rest are simply "issues".<br />
::::I skimmed over a couple of [[User:Notasynonym]] edit's. Of those I checked, they seem okay because the instances where he changed "issue" to "problem" are in the context of bugs or troubleshooting problems. I would have a major problem (hehe) with anyone blindly doing a search-and-replace of "issue" to "problem", but it does not appear that he is doing this.<br />
::::Hope this helps!<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:27, 14 February 2014 (UTC)<br />
<br />
:::::Thanks Jstjohn, I too think that those edits are acceptable. When patrolling them, I didn't pay attention to [[User:Notasynonym]]'s username, which is probably the main reason that has made Lahwaacz suspicious: using "propaganda" usernames is indeed common practice among trolls, and still I don't understand why this user is using a separate account for this kind of edits, as if he thought himself they could generate criticism. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 00:51, 15 February 2014 (UTC)<br />
<br />
== Chromium development ==<br />
<br />
Original report:<br />
<br />
:[https://wiki.archlinux.org/index.php?title=Chromium_development&oldid=299458 Chromium development] -- 2014-02-25&nbsp;00:14:52 -- content -- Needs to be categorized, the installation and setup instructions need some straightening up.<br />
<br />
I am not even sure what is the purpose of that page - there is {{AUR|chromium-devel}} (linked from [[Chromium]]), which makes things much simpler (assuming it works). Also note that the page describes several bad practises: editing {{ic|/usr/bin/python}} with custom script to force python3, exporting necessary variables directly from {{ic|.bashrc}} etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:49, 8 March 2014 (UTC)<br />
<br />
:It's probably better to invite [[User:Imranhaider|the author]] to explain here, or move this discussion to [[Talk:Chromium development]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:12, 9 March 2014 (UTC)<br />
<br />
::The purpose of this page is to set up a development environment where someone can edit and run a modified version of chromium. {{AUR|chromium-devel}} is good for building and installing chromium from source but it's not an ideal way for you to do development work on it.<br />
<br />
::There is no mention of editing {{ic|/usr/bin/python}} in the page. There is a reference to adding {{ic|~/bin/python}} to blacklist certain python scripts from running python3. It does not modify the original binary in any way.<br />
<br />
::What's wrong with exporting variables from {{ic|.bashrc}}? -- ([[User talk:Imranhaider|Imran]] 23:01, 22 March 2014 (UTC)</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Reports&diff=306663ArchWiki talk:Reports2014-03-22T23:00:21Z<p>Imranhaider: /* Chromium development */</p>
<hr />
<div>In this page you can list:<br />
* Edits that a contributor made to the wiki without a proper explanation (that is what the Summary field is for) and whose validity you lack the knowledge to judge by yourself. In this case, please add a link to the edit in question with a brief explanation why you think it should be investigated. Consider contacting the contributor to ask for an explanation, which is often an effective way to solve these issues. Please report the eventual answer (if any) below the initial report. You can also link to a discussion already started in the talk page of the edited article.<br />
* Links to discussions started in talk pages requesting to add, delete, or modify some content in the respective articles which you do not have sufficient knowledge to answer definitively by yourself.<br />
<br />
Please sign your edits and feel free to comment on others' reports. Discussions will be deleted 3 days after closing.<br />
<br />
See [[ArchWiki:Spam]] to report vandalism.<br />
<br />
__TOC__<br />
==New templates==<br />
Just a heads-up, if you're OK with them [https://wiki.archlinux.org/index.php?title=Template:Yes&diff=174109&oldid=0] [https://wiki.archlinux.org/index.php?title=Template:No&diff=174107&oldid=0] , please close the report :-) -- [[User:Karol|Karol]] 07:42, 14 December 2011 (EST)<br />
:If we start applying them consistently in all the tables, probably adding a proper rule in [[Help:Style]], then I'm ok with them, since coloring cells in tables is not very straightforward even with wiki syntax.<br />
:Note their Chinese counterparts have been created too: [[Template:是]] and [[Template:否]]. Since those templates' code is very flexible, I suggest replacing them with only 2 templates, [[Template:Y]] and [[Template:N]], which would produce "Yes" and "No" by default, but whose first optional argument would allow them to display any other string, including translations, without the need to have localized versions of each template.<br />
:Going even a bit further, since some tables use additional colors, we may base the templates' names on their color instead of their meaning, so that we would have [[Template:G]], [[Template:R]], [[Template:Y]], [[Template:B]], and if necessary also [[Template:P]] and [[Template:O]] (purple and orange, just to complete the secondary colors). These templates should require the first argument, but I think they would be easy to use anyway, for sure much easier than the current | style="color:...." | blabla.<br />
:Waiting for opinions. -- [[User:Kynikos|Kynikos]] 09:19, 15 December 2011 (EST)<br />
:This template group would also give us an excuse to delete [[The Status Table Series]] and related templates, since they have a too narrow field of application and practically just create nested tables in the end, thus giving almost no real advantage. -- [[User:Kynikos|Kynikos]] 13:13, 24 December 2011 (EST)<br />
::I support this idea. Similar to the [[Template:Box]] '''COLOUR''' templates, a series of table cell coloured templates would ensure consistency across articles. -- [[User:Pointone|pointone]] 16:46, 19 January 2012 (EST)<br />
:::So good :) However I don't consider this an urgent task, I'm linking this discussion from a new entry among my numerous template ideas in my [[User:Kynikos/Tasks|todo list]]. Of course if you or someone else want to implement it, just go for it. Just reminding that the implementation should be accompanied by some related style rules.<br />
:::Also note that among my template-related ideas there's one about the Box COLOR series that seems to go in the opposite direction than the cell color templates, but I think that the colors for the Note, Warning and Tip templates should be reserved for them, and not be usable in other ways.<br />
:::-- [[User:Kynikos|Kynikos]] 06:47, 20 January 2012 (EST)<br />
<br />
== Jumbo frames' "Real World Examples" section ==<br />
<br />
[[Jumbo_Frames#Real_World_Examples]] <-- This section doesn't seem fitting on our wiki. This section just seems to be an advertisement for jumbo frames, and I think it should be removed. And I should also note that the methodology is a bit unreliable, in my opinion. To truly test ''just'' the difference that jumbo frames makes, one should make a RAM disk so hard disk performance is completely removed from the equation. And if we really want to sell people on switching to jumbo frames, I would rather we simply provide a one-liner plus a link to a technical white paper, IEEE conference paper, etc.<br />
Does anyone else agree? <br><br />
-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 21:59, 4 June 2012 (UTC)<br />
<br />
:Well, I don't know if we can really consider that section as an advertisement, however it's true that benchmarking sections are not really Arch-specific, and would probably better fit a blog or some other kind of website, which could be linked from the article. A similar article is [[SSD Benchmarking]], for example.<br />
:On the other hand it looks like an original work and I would hesitate a bit before simply deleting it, maybe moving the "Using Jumbo Frames on Arch Linux" section more to the top could be a start. [[User:Graysky]] seems to have added that section in 2009, he may be interested in discussing also about the reliability of the methodology, but I would do that in [[Talk:Jumbo Frames]] (possibly adding e.g. [[Template:Accuracy]] to the article), since this talk page is more used for discussing recent changes reports :)<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:26, 5 June 2012 (UTC)<br />
<br />
::Another alternative would be moving it to a sub-page, and having a link to it somewhere in the article.<br />
::-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 15:14, 7 June 2012 (UTC)<br />
<br />
:I just found this discussion. I do not feel that the examples I posted represent an advertisement in any way. They do represent a concrete example of leveraging the topic of the page on which they are written. They are a bit dated however. I agree with the RAM disk suggestion. If I get dome time over the weekend, I might update on more modern hardware under more controlled conditions.<br />
:-- [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 01:39, 12 October 2012 (UTC)<br />
<br />
== Pacnew_and_Pacsave_Files report ==<br />
Original quick report:<br />
:[https://wiki.archlinux.org/index.php?title=Pacnew_and_Pacsave_Files&curid=3629&diff=294370&oldid=286538]: what was wrong with the old script that was replaced?<br />
<br />
I think [https://wiki.archlinux.org/index.php?title=Pacnew_and_Pacsave_Files&curid=3629&diff=294370&oldid=286538 the edit in question] added just some error-checking and dependency-checking. As pacnew and pacidff files are often edited as root or with sudo, the script does additional check for that. I don't think it's a questionable edit. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 18:08, 1 February 2014 (UTC)<br />
<br />
:Honestly the only parts of the new script that I like are the diffed variable that makes it easier to change it to the preferred merge tool, and the pacsave alert at the end. About the rest, I think that always checking for the availability of the required programs (~1/3 of the script) is complete overkill for such a little script: it's uselessly run every time while it could be much more ''Simply'' left to the user, who is supposed to know what applications (s)he has installed; I think mentioning the required packages in the section intro would be more appropriate. Then there's the problem of replacing gksudo with plain sudo, which IIRC at least until some time ago was a discouraged practice. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:08, 2 February 2014 (UTC)<br />
<br />
== "Issue" -> "problem" updates ==<br />
<br />
I don't know what to think about [[User:Notasynonym]], every [[Special:Contributions/Notasynonym|contribution]] of this user (fortunately they are not ''that'' many) is just a replacement of "issue" with "problem" (and modifications for plural). Are those valid edits? I find it rather uncomfortable... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:40, 11 February 2014 (UTC)<br />
<br />
:I'm not a native English speaker, my only guess is that he's doing it because "problem" is a more specific word, while "issue" can have other meanings. Maybe we can ask him? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:27, 12 February 2014 (UTC)<br />
<br />
::The name of the account suggests that the propaganda is ''"issue" and "problem" are not synonyms'', which I just can't accept - even Github has [https://github.com/blog/411-github-issue-tracker issue pages]. I think that in IT it cannot be confused with the [http://dictionary.reference.com/browse/issue other meanings]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:14, 12 February 2014 (UTC)<br />
<br />
:::I've invited him to join this discussion. However I'd appreciate if also a third-party native English speaker shared his/her feelings about this <s>issue</s>... <s>problem</s>... matter! -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:58, 13 February 2014 (UTC)<br />
<br />
::::I'm a native English speaker. "issue" and "problem" are only synonyms in certain contexts. As a general rule of thumb, every "problem" is an "issue", but not every "issue" is a "problem".<br />
::::Using [[User:Lahwaacz]]'s GitHub example, GitHub chose the proper word for their system because GitHub's issue tracker is for reporting bugs, requesting new features, logging pull requests, asking general questions, etc. Of those, only bug reports are both "problems" ''and'' "issues"; the rest are simply "issues".<br />
::::I skimmed over a couple of [[User:Notasynonym]] edit's. Of those I checked, they seem okay because the instances where he changed "issue" to "problem" are in the context of bugs or troubleshooting problems. I would have a major problem (hehe) with anyone blindly doing a search-and-replace of "issue" to "problem", but it does not appear that he is doing this.<br />
::::Hope this helps!<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:27, 14 February 2014 (UTC)<br />
<br />
:::::Thanks Jstjohn, I too think that those edits are acceptable. When patrolling them, I didn't pay attention to [[User:Notasynonym]]'s username, which is probably the main reason that has made Lahwaacz suspicious: using "propaganda" usernames is indeed common practice among trolls, and still I don't understand why this user is using a separate account for this kind of edits, as if he thought himself they could generate criticism. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 00:51, 15 February 2014 (UTC)<br />
<br />
== Chromium development ==<br />
<br />
Original report:<br />
<br />
:[https://wiki.archlinux.org/index.php?title=Chromium_development&oldid=299458 Chromium development] -- 2014-02-25&nbsp;00:14:52 -- content -- Needs to be categorized, the installation and setup instructions need some straightening up.<br />
<br />
I am not even sure what is the purpose of that page - there is {{AUR|chromium-devel}} (linked from [[Chromium]]), which makes things much simpler (assuming it works). Also note that the page describes several bad practises: editing {{ic|/usr/bin/python}} with custom script to force python3, exporting necessary variables directly from {{ic|.bashrc}} etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:49, 8 March 2014 (UTC)<br />
<br />
:It's probably better to invite [[User:Imranhaider|the author]] to explain here, or move this discussion to [[Talk:Chromium development]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:12, 9 March 2014 (UTC)<br />
<br />
::The purpose of this page is to set up a development environment where someone can edit and run a modified version of chromium. {{AUR|chromium-devel}} is good for building and installing chromium from source but it's not an ideal way for you to do development work on it.<br />
<br />
::There is no mention of editing {{ic|/usr/bin/python}} in the page. There is a reference to adding {{ic|~/bin/python}} to blacklist certain python scripts from running python3. It does not modify the original binary in any way.<br />
<br />
::What's wrong with exporting variables from {{ic|.bashrc}}?</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=Chromium_development&diff=302837Chromium development2014-03-02T04:49:00Z<p>Imranhaider: </p>
<hr />
<div>== Introduction ==<br />
This article assumes that you are building Chromium from source in a 64-bit Arch Linux.<br />
<br />
== Install prerequisite packages ==<br />
~ $ yaourt -Sy --needed python python2 perl gcc gcc-libs bison flex gperf pkgconfig nss alsa-lib gconf glib2 gtk2 nspr ttf-ms-fonts freetype2 cairo dbus libgnome-keyring git vim ccache distcc bash<br />
<br />
== Initial setup ==<br />
=== Setup environment ===<br />
Add the following lines into your {{ic|~/.bashrc}}<br />
<br />
alias cd='cd -P'<br />
<br />
# NaCl (Native Client) requires 32-bit libraries so it won't work in a pure 64-bit Arch Linux<br />
# werror= will prevent the build from stopping when a warning occurs<br />
# Using shared libraries will reduce the LINK time<br />
export GYP_DEFINES="disable_nacl=1 werror= component=shared_library"<br />
<br />
export CCACHE_BASEDIR="${HOME}/src"<br />
export CCACHE_SLOPPINESS="include_file_mtime"<br />
export CHROME_DEVEL_SANDBOX="${HOME}/bin/chrome-devel-sandbox"<br />
export PATH="${HOME}/bin:${PATH}"<br />
<br />
Create {{ic|~/bin/python}} with the following content. Make the file executable with {{ic|chmod +x ~/bin/python}}<br />
This Bash script will blacklist depot_tools and chromium from running {{ic|python3}} and will ensure they use {{ic|python2}} instead.<br />
<br />
#!/bin/bash<br />
script=`readlink -f -- "$1"`<br />
case "$script" in (${HOME}/src/depot_tools/*|${HOME}/src/chromium/*)<br />
exec python2 "$@"<br />
;;<br />
esac<br />
exec python3 "$@"<br />
<br />
=== Install Depot Tools ===<br />
This will clone the depot tools git repository<br />
<br />
~ $ cd src<br />
~/src $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git<br />
<br />
Add the following line to your {{ic|~/.bashrc}}<br />
<br />
export PATH="${PATH}:${HOME}/src/depot_tools"<br />
<br />
== Download chromium code ==<br />
This will use the depot tools to download the chromium project from several repositories. It will take a while so be patient.<br />
<br />
~ $ mkdir src/chromium<br />
~ $ cd src/chromium<br />
~/src/chromium $ fetch --nohooks chromium --nosvn=True<br />
<br />
Edit {{ic|~/src/chromium/.gclient}} and set safesync_url's value to https://chromium-status.appspot.com/git-lkgr<br />
<br />
== Generate ninja build files ==<br />
Ninja is a type of meta-build tool that precomputes all dependencies ahead of time so it doesn't need to process dependencies during the actual build. This allows the developer to rebuild the project much faster because the dependencies are computed only once.<br />
<br />
~ $ cd src/chromium<br />
~/src/chromium $ gclient sync<br />
<br />
== Build ==<br />
=== Build and install chromium sandbox ===<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -C out/Release chrome_sandbox<br />
~/src/chromium/src $ cp out/Release/chrome_sandbox ${HOME}/bin/chrome-devel-sandbox<br />
~/src/chromium/src $ cd ${HOME}/bin<br />
~/bin $ sudo chown root:root chrome-devel-sandbox<br />
~/bin $ sudo chmod 4755 chrome-devel-sandbox<br />
<br />
=== Build Content shell ===<br />
The content shell is a lightweight version of the Chromium browser and it builds much faster than the full browser. It uses all the multithreaded/multiprocess code paths that is used by the Chromium browser so it's a good way to test code changes.<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug content_shell<br />
<br />
=== Build Chromium ===<br />
This will build the full chromium browser<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug chrome<br />
<br />
=== Run Chromium ===<br />
~ $ cd src/chromium/src/out/Debug<br />
~/src/chromium/src/out/Debug $ ./chrome</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=Chromium_development&diff=302836Chromium development2014-03-02T04:47:17Z<p>Imranhaider: fixed typo</p>
<hr />
<div>== Introduction ==<br />
This article assumes that you are building Chromium from source in a 64-bit Arch Linux.<br />
<br />
== Install prerequisite packages ==<br />
~ $ yaourt -Sy --needed python python2 perl gcc gcc-libs bison flex gperf pkgconfig nss alsa-lib gconf glib2 gtk2 nspr ttf-ms-fonts freetype2 cairo dbus libgnome-keyring git vim ccache distcc bash<br />
<br />
== Initial setup ==<br />
=== Setup environment ===<br />
Add the following lines into your {{ic|~/.bashrc}}<br />
<br />
alias cd='cd -P'<br />
<br />
# NaCl (Native Client) requires 32-bit libraries so it won't work in a pure 64-bit Arch Linux<br />
# werror= will prevent the build from stopping when a warning occurs<br />
# Using shared libraries will reduce the LINK time<br />
export GYP_DEFINES="disable_nacl=1 werror= component=shared_library"<br />
<br />
export CCACHE_BASEDIR="${HOME}/src"<br />
export CCACHE_SLOPPINESS="include_file_mtime"<br />
export CHROME_DEVEL_SANDBOX="${HOME}/bin/chrome-devel-sandbox"<br />
export PATH="${HOME}/bin:${PATH}"<br />
<br />
Create {{ic|~/bin/python}} with the following content. Make the file executable with {{ic|chmod +x ~/bin/python}}<br />
This Bash script will blacklist depot_tools and chromium from running {{ic|python3}} and will ensure they use {{ic|python2}} instead.<br />
<br />
#!/bin/bash<br />
script=`readlink -f -- "$1"`<br />
case "$script" in (${HOME}/src/depot_tools/*|${HOME}/src/chromium/*)<br />
exec python2 "$@"<br />
;;<br />
esac<br />
exec python3 "$@"<br />
<br />
=== Install Depot Tools ===<br />
This will clone the depot tools git repository<br />
<br />
~ $ cd src<br />
~/src $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git<br />
<br />
Add the following line to your {{ic|~/.bashrc}}<br />
<br />
export PATH="${PATH}:${HOME}/src/depot_tools"<br />
<br />
== Download chromium code ==<br />
This will use the depot tools to download the chromium project from several repositories. It will take a while so be patient.<br />
<br />
~ $ mkdir src/chromium<br />
~ $ cd src/chromium<br />
~/src/chromium $ fetch --nohooks chromium --nosvn=True<br />
<br />
Edit ~/src/chromium/.gclient and set safesync_url's value to https://chromium-status.appspot.com/git-lkgr<br />
<br />
== Generate ninja build files ==<br />
Ninja is a type of meta-build tool that precomputes all dependencies ahead of time so it doesn't need to process dependencies during the actual build. This allows the developer to rebuild the project much faster because the dependencies are computed only once.<br />
<br />
~ $ cd src/chromium<br />
~/src/chromium $ gclient sync<br />
<br />
== Build ==<br />
=== Build and install chromium sandbox ===<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -C out/Release chrome_sandbox<br />
~/src/chromium/src $ cp out/Release/chrome_sandbox ${HOME}/bin/chrome-devel-sandbox<br />
~/src/chromium/src $ cd ${HOME}/bin<br />
~/bin $ sudo chown root:root chrome-devel-sandbox<br />
~/bin $ sudo chmod 4755 chrome-devel-sandbox<br />
<br />
=== Build Content shell ===<br />
The content shell is a lightweight version of the Chromium browser and it builds much faster than the full browser. It uses all the multithreaded/multiprocess code paths that is used by the Chromium browser so it's a good way to test code changes.<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug content_shell<br />
<br />
=== Build Chromium ===<br />
This will build the full chromium browser<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug chrome<br />
<br />
=== Run Chromium ===<br />
~ $ cd src/chromium/src/out/Debug<br />
~/src/chromium/src/out/Debug $ ./chrome</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=Chromium_development&diff=299458Chromium development2014-02-21T22:14:45Z<p>Imranhaider: add some spacing</p>
<hr />
<div><br />
== Introduction ==<br />
This article assumes that you are building Chromium from source in a 64-bit Arch Linux.<br />
<br />
== Install prerequisite packages ==<br />
~ $ yaourt -Sy --needed python python2 perl gcc gcc-libs bison flex gperf pkgconfig nss alsa-lib gconf glib2 gtk2 nspr ttf-ms-fonts freetype2 cairo dbus libgnome-keyring git vim ccache distcc bash<br />
<br />
== Initial setup ==<br />
=== Setup environment ===<br />
Add the following lines into your ~/.bashrc<br />
<br />
alias cd='cd -P'<br />
<br />
# NaCl (Native Client) requires 32-bit libraries so it won't work in a pure 64-bit Arch Linux<br />
# werror= will prevent the build from stopping when a warning occurs<br />
# Using shared libraries will reduce the LINK time<br />
export GYP_DEFINES="disable_nacl=1 werror= component=shared_library"<br />
<br />
export CCACHE_BASEDIR="${HOME}/src"<br />
export CCACHE_SLOPPINESS="include_file_mtime"<br />
export CHROME_DEVEL_SANDBOX="${HOME}/bin/chrome-devel-sandbox"<br />
export PATH="${HOME}/bin:${PATH}"<br />
<br />
Create ~/bin/python with the following content. Make the file executable with chmod +x ~/bin/python<br />
This bash script will blacklist depot_tools and chromium from running python3 and will ensure they use python2 instead.<br />
<br />
#!/bin/bash<br />
script=`readlink -f -- "$1"`<br />
case "$script" in (${HOME}/src/depot_tools/*|${HOME}/src/chromium/*)<br />
exec python2 "$@"<br />
;;<br />
esac<br />
exec python3 "$@"<br />
<br />
=== Install Depot Tools ===<br />
This will clone the depot tools git repository<br />
<br />
~ $ cd src<br />
~/src $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git<br />
<br />
Add the following line to your ~/.bashrc<br />
<br />
export PATH="${PATH}:${HOME}/src/depot_tools"<br />
<br />
<br />
== Download chromium code ==<br />
This will use the depot tools to download the chromium project from several repositories. It will take a while so be patient.<br />
<br />
~ $ mkdir src/chromium<br />
~ $ cd src/chromium<br />
~/src/chromium $ fetch --nohooks chromium --nosvn=True<br />
<br />
Edit ~/src/chromium/.gclient and set safesync_url's value to https://chromium-status.appspot.com/git-lkgr<br />
<br />
<br />
== Generate ninja build files ==<br />
Ninja is a type of meta-build tool that precomputes all dependencies ahead of time so it doesn't need to process dependencies during the actual build. This allows the developer to rebuild the project much faster because the dependencies are computed only once.<br />
<br />
~ $ cd src/chromium<br />
~/src/chromium $ gclient sync<br />
<br />
<br />
== Build ==<br />
=== Build and install chromium sandbox ===<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -C out/Release chrome_sandbox<br />
~/src/chromium/src $ cp out/Release/chrome_sandbox ${HOME}/bin/chrome-devel-sandbox<br />
~/src/chromium/src $ cd ${HOME}/bin<br />
~/bin $ sudo chown root:root chrome-devel-sandbox<br />
~/bin $ sudo chmod 4755 chrome-devel-sandbox<br />
<br />
=== Build Content shell ===<br />
The content shell is a lightweight version of the Chromium browser and it builds much faster than the full browser. It uses all the multithreaded/multiprocess code paths that is used by the Chromium browser so it's a good way to test code changes.<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug content_shell<br />
<br />
=== Build Chromium ===<br />
This will build the full chromium browswer<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug chrome<br />
<br />
=== Run Chromium ===<br />
~ $ cd src/chromium/src/out/Debug<br />
~/src/chromium/src/out/Debug $ ./chrome</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=Chromium_development&diff=299452Chromium development2014-02-21T22:00:39Z<p>Imranhaider: add info about content shell</p>
<hr />
<div><br />
== Introduction ==<br />
This article assumes that you are building Chromium from source in a 64-bit Arch Linux.<br />
<br />
== Install prerequisite packages ==<br />
~ $ yaourt -Sy --needed python python2 perl gcc gcc-libs bison flex gperf pkgconfig nss alsa-lib gconf glib2 gtk2 nspr ttf-ms-fonts freetype2 cairo dbus libgnome-keyring git vim ccache distcc bash<br />
<br />
== Initial setup ==<br />
=== Setup environment ===<br />
Add the following lines into your ~/.bashrc<br />
<br />
alias cd='cd -P'<br />
<br />
# NaCl (Native Client) requires 32-bit libraries so it won't work in a pure 64-bit Arch Linux<br />
# werror= will prevent the build from stopping when a warning occurs<br />
# Using shared libraries will reduce the LINK time<br />
export GYP_DEFINES="disable_nacl=1 werror= component=shared_library"<br />
<br />
export CCACHE_BASEDIR="${HOME}/src"<br />
export CCACHE_SLOPPINESS="include_file_mtime"<br />
export CHROME_DEVEL_SANDBOX="${HOME}/bin/chrome-devel-sandbox"<br />
export PATH="${HOME}/bin:${PATH}"<br />
<br />
Create ~/bin/python with the following content. Make the file executable with chmod +x ~/bin/python<br />
This bash script will blacklist depot_tools and chromium from running python3 and will ensure they use python2 instead.<br />
<br />
#!/bin/bash<br />
script=`readlink -f -- "$1"`<br />
case "$script" in (${HOME}/src/depot_tools/*|${HOME}/src/chromium/*)<br />
exec python2 "$@"<br />
;;<br />
esac<br />
exec python3 "$@"<br />
<br />
=== Install Depot Tools ===<br />
This will clone the depot tools git repository<br />
<br />
~ $ cd src<br />
~/src $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git<br />
<br />
Add the following line to your ~/.bashrc<br />
<br />
export PATH="${PATH}:${HOME}/src/depot_tools"<br />
<br />
== Download chromium code ==<br />
This will use the depot tools to download the chromium project from several repositories. It will take a while so be patient.<br />
<br />
~ $ mkdir src/chromium<br />
~ $ cd src/chromium<br />
~/src/chromium $ fetch --nohooks chromium --nosvn=True<br />
<br />
Edit ~/src/chromium/.gclient and set safesync_url's value to https://chromium-status.appspot.com/git-lkgr<br />
<br />
== Generate ninja build files ==<br />
Ninja is a type of meta-build tool that precomputes all dependencies ahead of time so it doesn't need to process dependencies during the actual build. This allows the developer to rebuild the project much faster because the dependencies are computed only once.<br />
<br />
~ $ cd src/chromium<br />
~/src/chromium $ gclient sync<br />
<br />
== Build ==<br />
=== Build and install chromium sandbox ===<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -C out/Release chrome_sandbox<br />
~/src/chromium/src $ cp out/Release/chrome_sandbox ${HOME}/bin/chrome-devel-sandbox<br />
~/src/chromium/src $ cd ${HOME}/bin<br />
~/bin $ sudo chown root:root chrome-devel-sandbox<br />
~/bin $ sudo chmod 4755 chrome-devel-sandbox<br />
<br />
=== Build Content shell ===<br />
The content shell is a lightweight version of the Chromium browser and it builds much faster than the full browser. It uses all the multithreaded/multiprocess code paths that is used by the Chromium browser so it's a good way to test code changes.<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug content_shell<br />
<br />
=== Build Chromium ===<br />
This will build the full chromium browswer<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug chrome<br />
<br />
=== Run Chromium ===<br />
~ $ cd src/chromium/src/out/Debug<br />
~/src/chromium/src/out/Debug $ ./chrome</div>Imranhaiderhttps://wiki.archlinux.org/index.php?title=Chromium_development&diff=299326Chromium development2014-02-21T05:31:46Z<p>Imranhaider: Created page with " == Introduction == This article assumes that you are building Chromium from source in a 64-bit Arch Linux. == Install prerequisite packages == ~ $ yaourt -Sy --needed pytho..."</p>
<hr />
<div><br />
== Introduction ==<br />
This article assumes that you are building Chromium from source in a 64-bit Arch Linux.<br />
<br />
== Install prerequisite packages ==<br />
~ $ yaourt -Sy --needed python python2 perl gcc gcc-libs bison flex gperf pkgconfig nss alsa-lib gconf glib2 gtk2 nspr ttf-ms-fonts freetype2 cairo dbus libgnome-keyring git vim ccache distcc bash<br />
<br />
== Initial setup ==<br />
=== Setup environment ===<br />
Add the following lines into your ~/.bashrc<br />
<br />
alias cd='cd -P'<br />
<br />
# NaCl (Native Client) requires 32-bit libraries so it won't work in a pure 64-bit Arch Linux<br />
# werror= will prevent the build from stopping when a warning occurs<br />
# Using shared libraries will reduce the LINK time<br />
export GYP_DEFINES="disable_nacl=1 werror= component=shared_library"<br />
<br />
export CCACHE_BASEDIR="${HOME}/src"<br />
export CCACHE_SLOPPINESS="include_file_mtime"<br />
export CHROME_DEVEL_SANDBOX="${HOME}/bin/chrome-devel-sandbox"<br />
export PATH="${HOME}/bin:${PATH}"<br />
<br />
Create ~/bin/python with the following content. Make the file executable with chmod +x ~/bin/python<br />
This bash script will blacklist depot_tools and chromium from running python3 and will ensure they use python2 instead.<br />
<br />
#!/bin/bash<br />
script=`readlink -f -- "$1"`<br />
case "$script" in (${HOME}/src/depot_tools/*|${HOME}/src/chromium/*)<br />
exec python2 "$@"<br />
;;<br />
esac<br />
exec python3 "$@"<br />
<br />
=== Install Depot Tools ===<br />
This will clone the depot tools git repository<br />
<br />
~ $ cd src<br />
~/src $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git<br />
<br />
Add the following line to your ~/.bashrc<br />
<br />
export PATH="${PATH}:${HOME}/src/depot_tools"<br />
<br />
== Download chromium code ==<br />
This will use the depot tools to download the chromium project from several repositories. It will take a while so be patient.<br />
<br />
~ $ mkdir src/chromium<br />
~ $ cd src/chromium<br />
~/src/chromium $ fetch --nohooks chromium --nosvn=True<br />
<br />
Edit ~/src/chromium/.gclient and set safesync_url's value to https://chromium-status.appspot.com/git-lkgr<br />
<br />
== Generate ninja build files ==<br />
Ninja is a type of meta-build tool that precomputes all dependencies ahead of time so it doesn't need to process dependencies during the actual build. This allows the developer to rebuild the project much faster because the dependencies are computed only once.<br />
<br />
~ $ cd src/chromium<br />
~/src/chromium $ gclient sync<br />
<br />
== Build ==<br />
=== Build and install chromium sandbox ===<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -C out/Release chrome_sandbox<br />
~/src/chromium/src $ cp out/Release/chrome_sandbox ${HOME}/bin/chrome-devel-sandbox<br />
~/src/chromium/src $ cd ${HOME}/bin<br />
~/bin $ sudo chown root:root chrome-devel-sandbox<br />
~/bin $ sudo chmod 4755 chrome-devel-sandbox<br />
<br />
=== Build chromium ===<br />
~ $ cd src/chromium/src<br />
~/src/chromium/src $ ninja -j10 -C out/Debug chrome<br />
<br />
=== Run chromium ===<br />
~ $ cd src/chromium/src/out/Debug<br />
~/src/chromium/src/out/Debug $ ./chrome</div>Imranhaider