gitlab_rails['packages_object_store_remote_directory'] = "packages" # The bucket name.
gitlab_rails['packages_object_store_direct_upload'] = false # Use Object Storage directly for uploads instead of background uploads if enabled (Default: false).
gitlab_rails['packages_object_store_remote_directory']="packages"# The bucket name.
gitlab_rails['packages_object_store_direct_upload']=false# Use Object Storage directly for uploads instead of background uploads if enabled (Default: false).
gitlab_rails['packages_object_store_background_upload']=true# Temporary option to limit automatic upload (Default: true).
gitlab_rails['packages_object_store_proxy_download']=false# Passthrough all downloads via GitLab instead of using Redirects to Object Storage.
1. Configure Postfix to receive mail on all interfaces, which includes the internet:
```sh
sudo postconf -e "inet_interfaces = all"
```
```sh
sudo postconf -e "inet_interfaces = all"
```
1. Configure Postfix to use the `+` delimiter for sub-addressing:
```sh
sudo postconf -e "recipient_delimiter = +"
```
```sh
sudo postconf -e "recipient_delimiter = +"
```
1. Restart Postfix:
```sh
sudo service postfix restart
```
```sh
sudo service postfix restart
```
## Test the final setup
1. Test SMTP under the new setup:
1. Connect to the SMTP server:
1. Connect to the SMTP server:
```sh
telnet gitlab.example.com 25
```
```sh
telnet gitlab.example.com 25
```
You should see a prompt like this:
You should see a prompt like this:
```sh
Trying 123.123.123.123...
Connected to gitlab.example.com.
Escape character is '^]'.
220 gitlab.example.com ESMTP Postfix (Ubuntu)
```
```sh
Trying 123.123.123.123...
Connected to gitlab.example.com.
Escape character is '^]'.
220 gitlab.example.com ESMTP Postfix (Ubuntu)
```
If you get a `Connection refused` error instead, make sure your firewall is set up to allow inbound traffic on port 25.
If you get a `Connection refused` error instead, make sure your firewall is set up to allow inbound traffic on port 25.
1. Send the `incoming` user a dummy email to test SMTP, by entering the following into the SMTP prompt:
1. Send the `incoming` user a dummy email to test SMTP, by entering the following into the SMTP prompt:
```
ehlo gitlab.example.com
mail from: root@gitlab.example.com
rcpt to: incoming@gitlab.example.com
data
Subject: Re: Some issue
```
ehlo gitlab.example.com
mail from: root@gitlab.example.com
rcpt to: incoming@gitlab.example.com
data
Subject: Re: Some issue
Sounds good!
.
quit
```
Sounds good!
.
quit
```
(Note: The `.` is a literal period on its own line)
(Note: The `.` is a literal period on its own line)
1. Check if the `incoming` user received the email:
1. Check if the `incoming` user received the email:
```sh
su - incoming
MAIL=/home/incoming/Maildir
mail
```
```sh
su - incoming
MAIL=/home/incoming/Maildir
mail
```
You should see output like this:
You should see output like this:
```
"/home/incoming/Maildir": 1 message 1 unread
>U 1 root@gitlab.example.com 59/2842 Re: Some issue
```
```
"/home/incoming/Maildir": 1 message 1 unread
>U 1 root@gitlab.example.com 59/2842 Re: Some issue
```
Quit the mail app:
Quit the mail app:
```sh
q
```
```sh
q
```
1. Log out of the `incoming` account and go back to being `root`:
1. Log out of the `incoming` account and go back to being `root`:
```sh
logout
```
```sh
logout
```
1. Test IMAP under the new setup:
1. Connect to the IMAP server:
1. Connect to the IMAP server:
```sh
telnet gitlab.example.com 143
```
```sh
telnet gitlab.example.com 143
```
You should see a prompt like this:
You should see a prompt like this:
```sh
Trying 123.123.123.123...
Connected to mail.example.gitlab.com.
Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2011 Double Precision, Inc. See COPYING for distribution information.
```
```sh
Trying 123.123.123.123...
Connected to mail.example.gitlab.com.
Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2011 Double Precision, Inc. See COPYING for distribution information.
```
1. Sign in as the `incoming` user to test IMAP, by entering the following into the IMAP prompt:
1. Sign in as the `incoming` user to test IMAP, by entering the following into the IMAP prompt:
```
a login incoming PASSWORD
```
```
a login incoming PASSWORD
```
Replace PASSWORD with the password you set on the `incoming` user earlier.
Replace PASSWORD with the password you set on the `incoming` user earlier.
-`id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
-`sha` (optional) - The commit SHA to download. A tag, branch reference, or SHA can be used. This defaults to the tip of the default branch if not specified. For example:
@@ -484,9 +484,11 @@ When making a request to an HTTP Endpoint (think `/users/sign_in`) the request w
Below we describe the different pathing that HTTP vs. SSH Git requests will take. There is some overlap with the Web Request Cycle but also some differences.
### Web Request (80/443)
TODO
### SSH Request (22)
TODO
## System Layout
...
...
@@ -505,7 +507,9 @@ To summarize here's the [directory structure of the `git` user home directory](.
### Processes
ps aux | grep '^git'
```sh
ps aux | grep'^git'
```
GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or Nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process).
Instead of just overriding `Base#execute`, we should update it and extract
the behaviour into another method:
Instead of just overriding `Base#execute`, we should update it and extract
the behaviour into another method:
```ruby
class Base
def execute
return unless enabled?
```ruby
classBase
defexecute
returnunlessenabled?
do_something
end
do_something
end
private
private
def do_something
# ...
# ...
end
defdo_something
# ...
# ...
end
```
end
```
Then we're free to override that `do_something` without worrying about the
guards:
Then we're free to override that `do_something` without worrying about the
guards:
```ruby
module EE::Base
extend ::Gitlab::Utils::Override
```ruby
moduleEE::Base
extend::Gitlab::Utils::Override
override :do_something
def do_something
# Follow the above pattern to call super and extend it
end
override:do_something
defdo_something
# Follow the above pattern to call super and extend it
end
```
end
```
This would require updating CE first, or make sure this is back ported to CE.
This would require updating CE first, or make sure this is back ported to CE.
When prepending, place them in the `ee/` specific sub-directory, and
wrap class or module in `module EE` to avoid naming conflicts.
...
...
@@ -1038,8 +1038,8 @@ to avoid conflicts during CE to EE merge.
Until the work completed to merge the ce and ee codebases, which is tracked on [epic &802](https://gitlab.com/groups/gitlab-org/-/epics/802), there exists times in which some changes for EE require specific changes to the CE
code base. Examples of backports include the following:
* Features intended or originally built for EE that are later decided to move to CE
* Sometimes some code in CE may impact the EE feature
- Features intended or originally built for EE that are later decided to move to CE
- Sometimes some code in CE may impact the EE feature
Here is a workflow to make sure those changes end up backported safely into CE too.
