精简了上游直播源内容,仅保留个人所需的。
https://gist.githubusercontent.com/inkss/0cf33e9f52fbb1f91bc5eb0144e504cf/raw/ipv6.m3u
// Website you intended to retrieve for users. | |
const upstream = 'api.openai.com' | |
// Custom pathname for the upstream website. | |
const upstream_path = '/' | |
// Website you intended to retrieve for users using mobile devices. | |
const upstream_mobile = upstream | |
// Countries and regions where you wish to suspend your service. |
# 概述:一共三大部分配置。 | |
# 其中#注释掉的可以在需要的时候开启并修改,没有注释掉的(除了下面location示例)不要删掉,基本都是必须的配置项。 | |
###############################第一部分 全局配置############################ | |
#user nobody; 指定启动进程的用户,默认不用指定即可。 | |
#error_log logs/error.log; 配置日志输出,虽然叫error_log但是可以定义输出的级别,默认不写是ERROR级别 | |
#error_log logs/error.log notice; | |
#error_log logs/error.log info; | |
#pid logs/nginx.pid; 记录pid的文件,默认就是放到这个位置,可以修改。 |
A regular expression (shortened as regex) is a sequence of characters that specifies a search pattern in text. The patterns are often used by string-search algorithms for "find" or " find and replace" operations or for input validation (i.e if input matches requirement, e.g. if you input a phone that is in fact a phone number and not a name of a country). See more on wikipedia.
We have all been asked to create a password and told if that our password is not strong enough or does not contain a special character. As you might have guessed, password regex is behind this! In this regex tutorial I will be describing how to understand a strong password regex. A strong password regex looks like this:
^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*[!@#\$%\^&\*])(?=.{8,})
#!/bin/bash | |
############################################################################## | |
# An rclone bash script to backup files by Anuj Subedi ([email protected]). | |
# | |
# Copyright (C) 2020 Anuj Subedi <[email protected]> | |
# | |
# This script is licensed under the terms of the MIT license. | |
# https://opensource.org/licenses/MIT | |
# |
Testing Jenkins flows on your local machine, or running Jenkins in production in a docker container can be a little tricky with a docker-in-docker scenario. You could install Jenkins to avoid any docker-in-docker issues, but then you have Jenkins on your machine, and the local environment is likely going to be a fairly different from the actual production build servers, which can lead to annoying and time-consuming issues to debug.
Build environment differences are precisely why there is a strong argument to be made to run build processes strictly in docker containers. If we follow the philosophy that every build step or action should run in a docker container, even the Jenkins server itself, then we get massive benefits from things like, total control over the build environment, easily modify the build environment without the possibility of adversely effecting other jobs, explicit and strongly controlled tool versions,
# 1. put frpc and frpc.ini under /usr/local/frpc/ | |
# 2. put this file (frpc.service) at /etc/systemd/system | |
# 3. run `sudo systemctl daemon-reload && sudo systemctl enable frpc && sudo systemctl start frpc` | |
# Then we can manage frpc with `sudo service frpc {start|stop|restart|status}` | |
# See also: https://nosame.net/use-frp-to-reverse-proxy-your-nas/ | |
# Alternative for server: | |
# - Offical: https://github.com/fatedier/frp/blob/a4cfab6/conf/systemd/frpc%40.service | |
[Unit] |
# | |
# Server challenge directory for Let's encrypt! | |
# | |
location /.well-known/acme-challenge/ { | |
alias /var/www/acme/; | |
} |
Some Jenkinsfile examples |