Docs: replace gitea with Gitea (#17838)
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
This commit is contained in:
qwerty287
GitHub
parent
1fee11d69a
commit
b1df890951
14 changed files with 48 additions and 48 deletions
|
|
@ -25,7 +25,7 @@ wget -O /path/to/custom/public/privacy.html https://raw.githubusercontent.com/go
|
|||
|
||||
Now you need to edit the page to meet your requirements. In particular you must change the email addresses, web addresses and references to "Your Gitea Instance" to match your situation.
|
||||
|
||||
You absolutely must not place a general ToS or privacy statement that implies that the gitea project is responsible for your server.
|
||||
You absolutely must not place a general ToS or privacy statement that implies that the Gitea project is responsible for your server.
|
||||
|
||||
## Make it Visible
|
||||
|
||||
|
|
|
|||
|
|
@ -76,20 +76,20 @@ To extract resources embedded in Gitea's executable, use the following syntax:
|
|||
gitea [--config {file}] embedded extract [--destination {dir}|--custom] [--overwrite|--rename] [--include-vendored] {patterns...}
|
||||
```
|
||||
|
||||
The `--config` option tells gitea the location of the `app.ini` configuration file if
|
||||
The `--config` option tells Gitea the location of the `app.ini` configuration file if
|
||||
it's not in its default location. This option is only used with the `--custom` flag.
|
||||
|
||||
The `--destination` option tells gitea the directory where the files must be extracted to.
|
||||
The `--destination` option tells Gitea the directory where the files must be extracted to.
|
||||
The default is the current directory.
|
||||
|
||||
The `--custom` flag tells gitea to extract the files directly into the `custom` directory.
|
||||
The `--custom` flag tells Gitea to extract the files directly into the `custom` directory.
|
||||
For this to work, the command needs to know the location of the `app.ini` configuration
|
||||
file (`--config`) and, depending of the configuration, be ran from the directory where
|
||||
gitea normally starts. See [Customizing Gitea]({{< relref "doc/advanced/customizing-gitea.en-us.md" >}}) for details.
|
||||
|
||||
The `--overwrite` flag allows any existing files in the destination directory to be overwritten.
|
||||
|
||||
The `--rename` flag tells gitea to rename any existing files in the destination directory
|
||||
The `--rename` flag tells Gitea to rename any existing files in the destination directory
|
||||
as `filename.bak`. Previous `.bak` files are overwritten.
|
||||
|
||||
At least one file search pattern must be provided; see `list` subcomand above for pattern
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ Values containing `#` or `;` must be quoted using `` ` `` or `"""`.
|
|||
### Repository - Upload (`repository.upload`)
|
||||
|
||||
- `ENABLED`: **true**: Whether repository file uploads are enabled
|
||||
- `TEMP_PATH`: **data/tmp/uploads**: Path for uploads (tmp gets deleted on gitea restart)
|
||||
- `TEMP_PATH`: **data/tmp/uploads**: Path for uploads (tmp gets deleted on Gitea restart)
|
||||
- `ALLOWED_TYPES`: **\<empty\>**: Comma-separated list of allowed file extensions (`.zip`), mime types (`text/plain`) or wildcard type (`image/*`, `audio/*`, `video/*`). Empty value or `*/*` allows all types.
|
||||
- `FILE_MAX_SIZE`: **3**: Max size of each file in megabytes.
|
||||
- `MAX_FILES`: **5**: Max number of files per upload
|
||||
|
|
@ -184,7 +184,7 @@ The following configuration set `Content-Type: application/vnd.android.package-a
|
|||
Values can be emoji alias (:smile:) or a unicode emoji.
|
||||
For custom reactions, add a tightly cropped square image to public/img/emoji/reaction_name.png
|
||||
- `CUSTOM_EMOJIS`: **gitea, codeberg, gitlab, git, github, gogs**: Additional Emojis not defined in the utf8 standard.
|
||||
By default we support gitea (:gitea:), to add more copy them to public/img/emoji/emoji_name.png and
|
||||
By default we support Gitea (:gitea:), to add more copy them to public/img/emoji/emoji_name.png and
|
||||
add it to this config.
|
||||
- `DEFAULT_SHOW_FULL_NAME`: **false**: Whether the full name of the users should be shown where possible. If the full name isn't set, the username will be used.
|
||||
- `SEARCH_REPO_DESCRIPTION`: **true**: Whether to search within description at repository search on explore page.
|
||||
|
|
@ -240,10 +240,10 @@ The following configuration set `Content-Type: application/vnd.android.package-a
|
|||
- `STATIC_URL_PREFIX`: **\<empty\>**:
|
||||
Overwrite this option to request static resources from a different URL.
|
||||
This includes CSS files, images, JS files and web fonts.
|
||||
Avatar images are dynamic resources and still served by gitea.
|
||||
Avatar images are dynamic resources and still served by Gitea.
|
||||
The option can be just a different path, as in `/static`, or another domain, as in `https://cdn.example.com`.
|
||||
Requests are then made as `%(ROOT_URL)s/static/css/index.css` and `https://cdn.example.com/css/index.css` respective.
|
||||
The static files are located in the `public/` directory of the gitea source repository.
|
||||
The static files are located in the `public/` directory of the Gitea source repository.
|
||||
- `HTTP_ADDR`: **0.0.0.0**: HTTP listen address.
|
||||
- If `PROTOCOL` is set to `fcgi`, Gitea will listen for FastCGI requests on TCP socket
|
||||
defined by `HTTP_ADDR` and `HTTP_PORT` configuration settings.
|
||||
|
|
@ -272,7 +272,7 @@ The following configuration set `Content-Type: application/vnd.android.package-a
|
|||
- `SSH_CREATE_AUTHORIZED_KEYS_FILE`: **true**: Gitea will create a authorized_keys file by default when it is not using the internal ssh server. If you intend to use the AuthorizedKeysCommand functionality then you should turn this off.
|
||||
- `SSH_AUTHORIZED_KEYS_BACKUP`: **true**: Enable SSH Authorized Key Backup when rewriting all keys, default is true.
|
||||
- `SSH_TRUSTED_USER_CA_KEYS`: **\<empty\>**: Specifies the public keys of certificate authorities that are trusted to sign user certificates for authentication. Multiple keys should be comma separated. E.g.`ssh-<algorithm> <key>` or `ssh-<algorithm> <key1>, ssh-<algorithm> <key2>`. For more information see `TrustedUserCAKeys` in the sshd config man pages. When empty no file will be created and `SSH_AUTHORIZED_PRINCIPALS_ALLOW` will default to `off`.
|
||||
- `SSH_TRUSTED_USER_CA_KEYS_FILENAME`: **`RUN_USER`/.ssh/gitea-trusted-user-ca-keys.pem**: Absolute path of the `TrustedUserCaKeys` file gitea will manage. If you're running your own ssh server and you want to use the gitea managed file you'll also need to modify your sshd_config to point to this file. The official docker image will automatically work without further configuration.
|
||||
- `SSH_TRUSTED_USER_CA_KEYS_FILENAME`: **`RUN_USER`/.ssh/gitea-trusted-user-ca-keys.pem**: Absolute path of the `TrustedUserCaKeys` file Gitea will manage. If you're running your own ssh server and you want to use the Gitea managed file you'll also need to modify your sshd_config to point to this file. The official docker image will automatically work without further configuration.
|
||||
- `SSH_AUTHORIZED_PRINCIPALS_ALLOW`: **off** or **username, email**: \[off, username, email, anything\]: Specify the principals values that users are allowed to use as principal. When set to `anything` no checks are done on the principal string. When set to `off` authorized principal are not allowed to be set.
|
||||
- `SSH_CREATE_AUTHORIZED_PRINCIPALS_FILE`: **false/true**: Gitea will create a authorized_principals file by default when it is not using the internal ssh server and `SSH_AUTHORIZED_PRINCIPALS_ALLOW` is not `off`.
|
||||
- `SSH_AUTHORIZED_PRINCIPALS_BACKUP`: **false/true**: Enable SSH Authorized Principals Backup when rewriting all keys, default is true if `SSH_AUTHORIZED_PRINCIPALS_ALLOW` is not `off`.
|
||||
|
|
@ -298,7 +298,7 @@ The following configuration set `Content-Type: application/vnd.android.package-a
|
|||
- `STATIC_CACHE_TIME`: **6h**: Web browser cache time for static resources on `custom/`, `public/` and all uploaded avatars. Note that this cache is disabled when `RUN_MODE` is "dev".
|
||||
- `ENABLE_GZIP`: **false**: Enable gzip compression for runtime-generated content, static resources excluded.
|
||||
- `ENABLE_PPROF`: **false**: Application profiling (memory and cpu). For "web" command it listens on localhost:6060. For "serv" command it dumps to disk at `PPROF_DATA_PATH` as `(cpuprofile|memprofile)_<username>_<temporary id>`
|
||||
- `PPROF_DATA_PATH`: **data/tmp/pprof**: `PPROF_DATA_PATH`, use an absolute path when you start gitea as service
|
||||
- `PPROF_DATA_PATH`: **data/tmp/pprof**: `PPROF_DATA_PATH`, use an absolute path when you start Gitea as service
|
||||
- `LANDING_PAGE`: **home**: Landing page for unauthenticated users \[home, explore, organizations, login\].
|
||||
|
||||
- `LFS_START_SERVER`: **false**: Enables git-lfs support.
|
||||
|
|
@ -497,7 +497,7 @@ Certain queues have defaults that override the defaults set in `[queue]` (this o
|
|||
Gitea instance and perform arbitrary actions in the name of the Gitea OS user.
|
||||
This maybe harmful to you website or your operating system.
|
||||
- `DISABLE_WEBHOOKS`: **false**: Set to `true` to disable webhooks feature.
|
||||
- `ONLY_ALLOW_PUSH_IF_GITEA_ENVIRONMENT_SET`: **true**: Set to `false` to allow local users to push to gitea-repositories without setting up the Gitea environment. This is not recommended and if you want local users to push to gitea repositories you should set the environment appropriately.
|
||||
- `ONLY_ALLOW_PUSH_IF_GITEA_ENVIRONMENT_SET`: **true**: Set to `false` to allow local users to push to gitea-repositories without setting up the Gitea environment. This is not recommended and if you want local users to push to Gitea repositories you should set the environment appropriately.
|
||||
- `IMPORT_LOCAL_PATHS`: **false**: Set to `false` to prevent all users (including admin) from importing local path on server.
|
||||
- `INTERNAL_TOKEN`: **\<random at every install if no uri set\>**: Secret used to validate communication within Gitea binary.
|
||||
- `INTERNAL_TOKEN_URI`: **<empty>**: Instead of defining internal token in the configuration, this configuration option can be used to give Gitea a path to a file that contains the internal token (example value: `file:/etc/gitea/internal_token`)
|
||||
|
|
@ -592,7 +592,7 @@ Certain queues have defaults that override the defaults set in `[queue]` (this o
|
|||
- `ALLOWED_USER_VISIBILITY_MODES`: **public,limited,private**: Set which visibility modes a user can have
|
||||
- `DEFAULT_ORG_VISIBILITY`: **public**: Set default visibility mode for organisations, either "public", "limited" or "private".
|
||||
- `DEFAULT_ORG_MEMBER_VISIBLE`: **false** True will make the membership of the users visible when added to the organisation.
|
||||
- `ALLOW_ONLY_INTERNAL_REGISTRATION`: **false** Set to true to force registration only via gitea.
|
||||
- `ALLOW_ONLY_INTERNAL_REGISTRATION`: **false** Set to true to force registration only via Gitea.
|
||||
- `ALLOW_ONLY_EXTERNAL_REGISTRATION`: **false** Set to true to force registration only using third-party services.
|
||||
- `NO_REPLY_ADDRESS`: **noreply.DOMAIN** Value for the domain part of the user's email address in the git log if user has set KeepEmailPrivate to true. DOMAIN resolves to the value in server.DOMAIN.
|
||||
The user's email will be replaced with a concatenation of the user name in lower case, "@" and NO_REPLY_ADDRESS.
|
||||
|
|
@ -750,11 +750,11 @@ Default templates for project boards:
|
|||
- `LEVEL`: **Info**: General log level. \[Trace, Debug, Info, Warn, Error, Critical, Fatal, None\]
|
||||
- `STACKTRACE_LEVEL`: **None**: Default log level at which to log create stack traces. \[Trace, Debug, Info, Warn, Error, Critical, Fatal, None\]
|
||||
- `ROUTER_LOG_LEVEL`: **Info**: The log level that the router should log at. (If you are setting the access log, its recommended to place this at Debug.)
|
||||
- `ROUTER`: **console**: The mode or name of the log the router should log to. (If you set this to `,` it will log to default gitea logger.)
|
||||
- `ROUTER`: **console**: The mode or name of the log the router should log to. (If you set this to `,` it will log to default Gitea logger.)
|
||||
NB: You must have `DISABLE_ROUTER_LOG` set to `false` for this option to take effect. Configure each mode in per mode log subsections `\[log.modename.router\]`.
|
||||
- `ENABLE_ACCESS_LOG`: **false**: Creates an access.log in NCSA common log format, or as per the following template
|
||||
- `ENABLE_SSH_LOG`: **false**: save ssh log to log file
|
||||
- `ACCESS`: **file**: Logging mode for the access logger, use a comma to separate values. Configure each mode in per mode log subsections `\[log.modename.access\]`. By default the file mode will log to `$ROOT_PATH/access.log`. (If you set this to `,` it will log to the default gitea logger.)
|
||||
- `ACCESS`: **file**: Logging mode for the access logger, use a comma to separate values. Configure each mode in per mode log subsections `\[log.modename.access\]`. By default the file mode will log to `$ROOT_PATH/access.log`. (If you set this to `,` it will log to the default Gitea logger.)
|
||||
- `ACCESS_LOG_TEMPLATE`: **`{{.Ctx.RemoteAddr}} - {{.Identity}} {{.Start.Format "[02/Jan/2006:15:04:05 -0700]" }} "{{.Ctx.Req.Method}} {{.Ctx.Req.URL.RequestURI}} {{.Ctx.Req.Proto}}" {{.ResponseWriter.Status}} {{.ResponseWriter.Size}} "{{.Ctx.Req.Referer}}\" \"{{.Ctx.Req.UserAgent}}"`**: Sets the template used to create the access log.
|
||||
- The following variables are available:
|
||||
- `Ctx`: the `context.Context` of the request.
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ shouldn't be touched without fully understanding these components.
|
|||
|
||||
Copy [`home.tmpl`](https://github.com/go-gitea/gitea/blob/main/templates/home.tmpl) for your version of Gitea from `templates` to `$GITEA_CUSTOM/templates`.
|
||||
Edit as you wish.
|
||||
Dont forget to restart your gitea to apply the changes.
|
||||
Dont forget to restart your Gitea to apply the changes.
|
||||
|
||||
### Adding links and tabs
|
||||
|
||||
|
|
@ -248,7 +248,7 @@ $GITEA_CUSTOM/public
|
|||
`-- three.min.js
|
||||
```
|
||||
|
||||
Then restart gitea and open a STL file on your gitea instance.
|
||||
Then restart Gitea and open a STL file on your Gitea instance.
|
||||
|
||||
## Customizing Gitea mails
|
||||
|
||||
|
|
@ -338,7 +338,7 @@ Community themes are listed in [gitea/awesome-gitea#themes](https://gitea.com/gi
|
|||
The `arc-green` theme source can be found [here](https://github.com/go-gitea/gitea/blob/main/web_src/less/themes/theme-arc-green.less).
|
||||
|
||||
If your custom theme is considered a dark theme, set the global css variable `--is-dark-theme` to `true`.
|
||||
This allows gitea to adjust the Monaco code editor's theme accordingly.
|
||||
This allows Gitea to adjust the Monaco code editor's theme accordingly.
|
||||
|
||||
## Customizing fonts
|
||||
|
||||
|
|
|
|||
|
|
@ -328,13 +328,13 @@ This is equivalent to sending all logs to the console, with default go log being
|
|||
## Releasing-and-Reopening, Pausing and Resuming logging
|
||||
|
||||
If you are running on Unix you may wish to release-and-reopen logs in order to use `logrotate` or other tools.
|
||||
It is possible force gitea to release and reopen it's logging files and connections by sending `SIGUSR1` to the
|
||||
It is possible force Gitea to release and reopen it's logging files and connections by sending `SIGUSR1` to the
|
||||
running process, or running `gitea manager logging release-and-reopen`.
|
||||
|
||||
Alternatively, you may wish to pause and resume logging - this can be accomplished through the use of the
|
||||
`gitea manager logging pause` and `gitea manager logging resume` commands. Please note that whilst logging
|
||||
is paused log events below INFO level will not be stored and only a limited number of events will be stored.
|
||||
Logging may block, albeit temporarily, slowing gitea considerably whilst paused - therefore it is
|
||||
Logging may block, albeit temporarily, slowing Gitea considerably whilst paused - therefore it is
|
||||
recommended that pausing only done for a very short period of time.
|
||||
|
||||
## Adding and removing logging whilst Gitea is running
|
||||
|
|
@ -439,6 +439,6 @@ Gitea includes built-in log rotation, which should be enough for most deployment
|
|||
- Install `logrotate`.
|
||||
- Configure `logrotate` to match your deployment requirements, see `man 8 logrotate` for configuration syntax details. In the `postrotate/endscript` block send Gitea a `USR1` signal via `kill -USR1` or `kill -10` to the `gitea` process itself, or run `gitea manager logging release-and-reopen` (with the appropriate environment). Ensure that your configurations apply to all files emitted by Gitea loggers as described in the above sections.
|
||||
- Always do `logrotate /etc/logrotate.conf --debug` to test your configurations.
|
||||
- If you are using docker and are running from outside of the container you can use `docker exec -u $OS_USER $CONTAINER_NAME sh -c 'gitea manager logging release-and-reopen'` or `docker exec $CONTAINER_NAME sh -c '/bin/s6-svc -1 /etc/s6/gitea/'` or send `USR1` directly to the gitea process itself.
|
||||
- If you are using docker and are running from outside of the container you can use `docker exec -u $OS_USER $CONTAINER_NAME sh -c 'gitea manager logging release-and-reopen'` or `docker exec $CONTAINER_NAME sh -c '/bin/s6-svc -1 /etc/s6/gitea/'` or send `USR1` directly to the Gitea process itself.
|
||||
|
||||
The next `logrotate` jobs will include your configurations, so no restart is needed. You can also immediately reload `logrotate` with `logrotate /etc/logrotate.conf --force`.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ menu:
|
|||
{{< toc >}}
|
||||
|
||||
Gitea will verify GPG commit signatures in the provided tree by
|
||||
checking if the commits are signed by a key within the gitea database,
|
||||
checking if the commits are signed by a key within the Gitea database,
|
||||
or if the commit matches the default key for git.
|
||||
|
||||
Keys are not checked to determine if they have expired or revoked.
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ i.e. `servcies/user`, `models/repository`.
|
|||
### Import Alias
|
||||
|
||||
Since there are many package levels and sub packages, so you will find `modules/user`, `models/user`, `services/user`. When these packages are import into one Go file, it's difficult to know which package we are using and if it's a variable name or an import name. So we recommand to always use import alias. To differ from package variables which are commonly use camelCase, just use **snake_case** as import package alias.
|
||||
i.e. `import user_service "code.Gitea.io/Gitea/services/user"`
|
||||
i.e. `import user_service "code.gitea.io/gitea/services/user"`
|
||||
|
||||
### Future Tasks
|
||||
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ SVG icons are built using the `make svg` target which compiles the icon sources
|
|||
|
||||
### Building the Logo
|
||||
|
||||
The PNG and SVG versions of the gitea logo are built from a single SVG source file `assets/logo.svg` using the `TAGS="gitea" make generate-images` target. To run it, Node.js and npm must be available.
|
||||
The PNG and SVG versions of the Gitea logo are built from a single SVG source file `assets/logo.svg` using the `TAGS="gitea" make generate-images` target. To run it, Node.js and npm must be available.
|
||||
|
||||
The same process can also be used to generate custom logo PNGs from a SVG source file by updating `assets/logo.svg` and running `make generate-images`. Omitting the `gitea` tag will update only the user-designated logo files.
|
||||
|
||||
|
|
@ -321,12 +321,12 @@ for more information.
|
|||
## GoLand
|
||||
|
||||
Clicking the `Run Application` arrow on the function `func main()` in `/main.go`
|
||||
can quickly start a debuggable gitea instance.
|
||||
can quickly start a debuggable Gitea instance.
|
||||
|
||||
The `Output Directory` in `Run/Debug Configuration` MUST be set to the
|
||||
gitea project directory (which contains `main.go` and `go.mod`),
|
||||
otherwise, the started instance's working directory is a GoLand's temporary directory
|
||||
and prevents gitea from loading dynamic resources (eg: templates) in a development environment.
|
||||
and prevents Gitea from loading dynamic resources (eg: templates) in a development environment.
|
||||
|
||||
To run unit tests with SQLite in GoLand, set `-tags sqlite,sqlite_unlock_notify`
|
||||
in `Go tool arguments` of `Run/Debug Configuration`.
|
||||
|
|
|
|||
|
|
@ -282,12 +282,12 @@ Before activating SSPI single sign-on authentication (SSO) you have to prepare y
|
|||
|
||||
- If you are using Chrome or Edge, add the URL of the web app to the Local intranet sites (`Internet Options -> Security -> Local intranet -> Sites`)
|
||||
|
||||
- Start Chrome or Edge and navigate to the FQDN URL of gitea (eg. `http://host.domain.local:3000`)
|
||||
- Start Chrome or Edge and navigate to the FQDN URL of Gitea (eg. `http://host.domain.local:3000`)
|
||||
|
||||
- Click the `Sign In` button on the dashboard and choose SSPI to be automatically logged in with the same user that is currently logged on to the computer
|
||||
|
||||
- If it does not work, make sure that:
|
||||
- You are not running the web browser on the same server where gitea is running. You should be running the web browser on a domain joined computer (client) that is different from the server. If both the client and server are running on the same computer NTLM will be preferred over Kerberos.
|
||||
- You are not running the web browser on the same server where Gitea is running. You should be running the web browser on a domain joined computer (client) that is different from the server. If both the client and server are running on the same computer NTLM will be preferred over Kerberos.
|
||||
- There is only one `HTTP/...` SPN for the host
|
||||
- The SPN contains only the hostname, without the port
|
||||
- You have added the URL of the web app to the `Local intranet zone`
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ chmod 770 /etc/gitea
|
|||
chmod 750 /etc/gitea
|
||||
chmod 640 /etc/gitea/app.ini
|
||||
```
|
||||
If you don't want the web installer to be able to write the config file at all, it is also possible to make the config file read-only for the gitea user (owner/group `root:git`, mode `0640`), and set `INSTALL_LOCK = true`. In that case all database configuration details must be set beforehand in the config file, as well as the `SECRET_KEY` and `INTERNAL_TOKEN` values. See the [command line documentation]({{< relref "doc/usage/command-line.en-us.md" >}}) for information on using `gitea generate secret INTERNAL_TOKEN`.
|
||||
If you don't want the web installer to be able to write the config file at all, it is also possible to make the config file read-only for the Gitea user (owner/group `root:git`, mode `0640`), and set `INSTALL_LOCK = true`. In that case all database configuration details must be set beforehand in the config file, as well as the `SECRET_KEY` and `INTERNAL_TOKEN` values. See the [command line documentation]({{< relref "doc/usage/command-line.en-us.md" >}}) for information on using `gitea generate secret INTERNAL_TOKEN`.
|
||||
|
||||
### Configure Gitea's working directory
|
||||
|
||||
|
|
@ -123,15 +123,15 @@ It is recommended you do a [backup]({{< relref "doc/usage/backup-and-restore.en-
|
|||
If you have carried out the installation steps as described above, the binary should
|
||||
have the generic name `gitea`. Do not change this, i.e. to include the version number.
|
||||
|
||||
### 1. Restarting gitea with systemd (recommended)
|
||||
### 1. Restarting Gitea with systemd (recommended)
|
||||
|
||||
As explained before, we recommend to use systemd as service manager. In this case ```systemctl restart gitea``` should be enough.
|
||||
|
||||
### 2. Restarting gitea without systemd
|
||||
### 2. Restarting Gitea without systemd
|
||||
|
||||
To restart your gitea instance, we recommend to use SIGHUP signal. If you know your gitea PID use ```kill -1 $GITEA_PID``` otherwise you can use ```killall -1 gitea``` or ```pkill -1 gitea```
|
||||
To restart your Gitea instance, we recommend to use SIGHUP signal. If you know your Gitea PID use ```kill -1 $GITEA_PID``` otherwise you can use ```killall -1 gitea``` or ```pkill -1 gitea```
|
||||
|
||||
To gracefully stop the gitea instance, a simple ```kill $GITEA_PID``` or ```killall gitea``` is enough.
|
||||
To gracefully stop the Gitea instance, a simple ```kill $GITEA_PID``` or ```killall gitea``` is enough.
|
||||
|
||||
**NOTE:** We don't recommend to use SIGKILL signal (know also as `-9`), you may be forcefully stopping some of Gitea internal tasks and it will not gracefully stop (tasks in queues, indexers processes, etc.)
|
||||
|
||||
|
|
|
|||
|
|
@ -285,13 +285,13 @@ services:
|
|||
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
|
||||
```
|
||||
|
||||
To set required TOKEN and SECRET values, consider using gitea's built-in [generate utility functions](https://docs.gitea.io/en-us/command-line/#generate).
|
||||
To set required TOKEN and SECRET values, consider using Gitea's built-in [generate utility functions](https://docs.gitea.io/en-us/command-line/#generate).
|
||||
|
||||
# SSH Container Passthrough
|
||||
|
||||
Since SSH is running inside the container, SSH needs to be passed through from the host to the container if SSH support is desired. One option would be to run the container SSH on a non-standard port (or moving the host port to a non-standard port). Another option which might be more straightforward is to forward SSH commands from the host to the container. This setup is explained in the following.
|
||||
|
||||
This guide assumes that you have created a user on the host called `git` with permission to run `docker exec`, and that the gitea container is called `gitea`. You will need to modify that user's shell to forward the commands to the `sh` executable inside the container, using `docker exec`.
|
||||
This guide assumes that you have created a user on the host called `git` with permission to run `docker exec`, and that the Gitea container is called `gitea`. You will need to modify that user's shell to forward the commands to the `sh` executable inside the container, using `docker exec`.
|
||||
|
||||
First, create the file `/usr/local/bin/gitea-shell` on the host, with the following contents:
|
||||
|
||||
|
|
@ -314,7 +314,7 @@ Once the wrapper is in place, you can make it the shell for the `git` user:
|
|||
sudo usermod -s /usr/local/bin/gitea-shell git
|
||||
```
|
||||
|
||||
Now that all the SSH commands are forwarded to the container, you need to set up the SSH authentication on the host. This is done by leveraging the [SSH AuthorizedKeysCommand](https://docs.gitea.io/en-us/command-line/#keys) to match the keys against those accepted by gitea. Add the following block to `/etc/ssh/sshd_config`, on the host:
|
||||
Now that all the SSH commands are forwarded to the container, you need to set up the SSH authentication on the host. This is done by leveraging the [SSH AuthorizedKeysCommand](https://docs.gitea.io/en-us/command-line/#keys) to match the keys against those accepted by Gitea. Add the following block to `/etc/ssh/sshd_config`, on the host:
|
||||
|
||||
```bash
|
||||
Match User git
|
||||
|
|
|
|||
|
|
@ -303,7 +303,7 @@ services:
|
|||
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
|
||||
```
|
||||
|
||||
To set required TOKEN and SECRET values, consider using gitea's built-in [generate utility functions](https://docs.gitea.io/en-us/command-line/#generate).
|
||||
To set required TOKEN and SECRET values, consider using Gitea's built-in [generate utility functions](https://docs.gitea.io/en-us/command-line/#generate).
|
||||
|
||||
## SSH Container Passthrough
|
||||
|
||||
|
|
|
|||
|
|
@ -79,8 +79,8 @@ Admin operations:
|
|||
- `gitea admin user delete --id 1`
|
||||
- `create`:
|
||||
- Options:
|
||||
- `--name value`: Username. Required. As of gitea 1.9.0, use the `--username` flag instead.
|
||||
- `--username value`: Username. Required. New in gitea 1.9.0.
|
||||
- `--name value`: Username. Required. As of Gitea 1.9.0, use the `--username` flag instead.
|
||||
- `--username value`: Username. Required. New in Gitea 1.9.0.
|
||||
- `--password value`: Password. Required.
|
||||
- `--email value`: Email. Required.
|
||||
- `--admin`: If provided, this makes the user an admin. Optional.
|
||||
|
|
@ -301,7 +301,7 @@ Provides an SSHD AuthorizedKeysCommand. Needs to be configured in the sshd confi
|
|||
```ini
|
||||
...
|
||||
# The value of -e and the AuthorizedKeysCommandUser should match the
|
||||
# username running gitea
|
||||
# username running Gitea
|
||||
AuthorizedKeysCommandUser git
|
||||
AuthorizedKeysCommand /path/to/gitea keys -e git -u %u -t %t -k %k
|
||||
```
|
||||
|
|
@ -311,7 +311,7 @@ provided key. You should also set the value
|
|||
`SSH_CREATE_AUTHORIZED_KEYS_FILE=false` in the `[server]` section of
|
||||
`app.ini`.
|
||||
|
||||
NB: opensshd requires the gitea program to be owned by root and not
|
||||
NB: opensshd requires the Gitea program to be owned by root and not
|
||||
writable by group or others. The program must be specified by an absolute
|
||||
path.
|
||||
NB: Gitea must be running for this command to succeed.
|
||||
|
|
@ -327,13 +327,13 @@ Converts an existing MySQL database from utf8 to utf8mb4.
|
|||
|
||||
### doctor
|
||||
|
||||
Diagnose the problems of current gitea instance according the given configuration.
|
||||
Diagnose the problems of current Gitea instance according the given configuration.
|
||||
Currently there are a check list below:
|
||||
|
||||
- Check if OpenSSH authorized_keys file id correct
|
||||
When your gitea instance support OpenSSH, your gitea instance binary path will be written to `authorized_keys`
|
||||
when there is any public key added or changed on your gitea instance.
|
||||
Sometimes if you moved or renamed your gitea binary when upgrade and you haven't run `Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.)` on your Admin Panel. Then all pull/push via SSH will not be work.
|
||||
When your Gitea instance support OpenSSH, your Gitea instance binary path will be written to `authorized_keys`
|
||||
when there is any public key added or changed on your Gitea instance.
|
||||
Sometimes if you moved or renamed your Gitea binary when upgrade and you haven't run `Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.)` on your Admin Panel. Then all pull/push via SSH will not be work.
|
||||
This check will help you to check if it works well.
|
||||
|
||||
For contributors, if you want to add more checks, you can wrie ad new function like `func(ctx *cli.Context) ([]string, error)` and
|
||||
|
|
@ -367,7 +367,7 @@ with the defaults set appropriately by using:
|
|||
gitea doctor recreate-table user
|
||||
```
|
||||
|
||||
You can ask gitea to recreate multiple tables using:
|
||||
You can ask Gitea to recreate multiple tables using:
|
||||
|
||||
```
|
||||
gitea doctor recreate-table table1 table2 ...
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ We can tune the performance in splitting requests into categories static and dyn
|
|||
CSS files, JavaScript files, images and web fonts are static content.
|
||||
The front page, a repository view or issue list is dynamic content.
|
||||
|
||||
Nginx can serve static resources directly and proxy only the dynamic requests to gitea.
|
||||
Nginx can serve static resources directly and proxy only the dynamic requests to Gitea.
|
||||
Nginx is optimized for serving static content, while the proxying of large responses might be the opposite of that
|
||||
(see [https://serverfault.com/q/587386](https://serverfault.com/q/587386)).
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ server {
|
|||
Set `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea` in your configuration.
|
||||
|
||||
```apacheconf
|
||||
# application server running gitea
|
||||
# application server running Gitea
|
||||
server {
|
||||
listen 80;
|
||||
server_name git.example.com;
|
||||
|
|
|
|||
Loading…
Reference in a new issue