aiko/dotTiddlywiki
1
0
Fork 0
mirror of /repos/dotTiddlywiki.git synced 2025-12-30 07:31:33 +01:00
Code Issues Releases Wiki Activity

new

Browse Source
This commit is contained in:
Aiko Mastboom 2019-05-13 21:54:41 +02:00
parent e2b04070cd
commit 636925686f
18 changed files with 1235 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
mywiki/tiddlers/Adding worker to CI.tid Normal file
View File

@ -0,0 +1,47 @@
created: 20180615091542932
creator: user
modified: 20180615095456398
modifier: user
tags:
title: Adding worker to CI
type: text/vnd.tiddlywiki
1. create new Droplet on DO
https://cloud.digitalocean.com/droplets/new?i=c080b8&size=s-2vcpu-2gb&region=ams3&options=private_networking,install_agent&imageId=35314372&type=snapshots
* snapshot ci-worker-base-image
* region AMS-3
* private networking, monitoring
* tags: ci, worker
make sure you can log into the `www-data` user
(you may need to add your key to .ssh/authorized_keys)
make a note of the droplets IP you need it later on
2. add node to CI
http://ci.bjoola.nl/computer/new
# copy from `worker-01`
# make a note of the java command line presented, you need the `NODE_NAME` and `NODE_SECRET` later on.
```
Run from agent command line:
java -jar agent.jar -jnlpUrl http://ci.bjoola.nl/computer/NODE_NAME/slave-agent.jnlp -secret NODE_SECRET
```
3. starting the node on the Droplet
```
git clone https://github.com/kantoor-f12/ci-operations.git ;
cd ci-operations ;
git checkout jenkins-slave ;
cd operations/docker/jenkins-slave
NODE_NAME=nameYouGaveItAbove NODE_SECRET=secretRecievedAbove SSH_HOST=IPofDroplet ./remoteSlave.sh
```

17
mywiki/tiddlers/Avant-Wizz Certs.tid Normal file
View File

@ -0,0 +1,17 @@
created: 20180411102534861
creator: user
modified: 20180411102733178
modifier: user
tags:
title: Avant-Wizz Certs
type: text/vnd.tiddlywiki
```
ssh portal.avant-wizz.nl
www-data@portal:~$ docker start live_apache_1
www-data@portal:~$ docker exec -it live_apache_1 bash
root@842deca53d0b:/# ./run_letsencrypt.sh --apache --domains portal.avant-wizz.nl,portal-api.avant-wizz.nl
root@842deca53d0b:/# service apache2 reload
```

720
mywiki/tiddlers/Beanstalk protocol.tid Normal file
View File

@ -0,0 +1,720 @@
created: 20171110103619563
creator: user
modified: 20181219111950102
modifier: user
tags:
title: Beanstalk protocol
type: text/x-markdown
= Beanstalk Protocol =
Protocol
--------
The beanstalk protocol runs over TCP using ASCII encoding. Clients connect,
send commands and data, wait for responses, and close the connection. For each
connection, the server processes commands serially in the order in which they
were received and sends responses in the same order. All integers in the
protocol are formatted in decimal and (unless otherwise indicated)
nonnegative.
Names, in this protocol, are ASCII strings. They may contain letters (A-Z and
a-z), numerals (0-9), hyphen ("-"), plus ("+"), slash ("/"), semicolon (";"),
dot ("."), dollar-sign ("$"), underscore ("_"), and parentheses ("(" and ")"),
but they may not begin with a hyphen. They are terminated by white space
(either a space char or end of line). Each name must be at least one character
long.
The protocol contains two kinds of data: text lines and unstructured chunks of
data. Text lines are used for client commands and server responses. Chunks are
used to transfer job bodies and stats information. Each job body is an opaque
sequence of bytes. The server never inspects or modifies a job body and always
sends it back in its original form. It is up to the clients to agree on a
meaningful interpretation of job bodies.
The client may issue the "quit" command, or simply close the TCP connection
when it no longer has use for the server. However, beanstalkd performs very
well with a large number of open connections, so it is usually better for the
client to keep its connection open and reuse it as much as possible. This also
avoids the overhead of establishing new TCP connections.
If a client violates the protocol (such as by sending a request that is not
well-formed or a command that does not exist) or if the server has an error,
the server will reply with one of the following error messages:
- "OUT_OF_MEMORY\r\n" The server cannot allocate enough memory for the job.
The client should try again later.
- "INTERNAL_ERROR\r\n" This indicates a bug in the server. It should never
happen. If it does happen, please report it at
http://groups.google.com/group/beanstalk-talk.
- "BAD_FORMAT\r\n" The client sent a command line that was not well-formed.
This can happen if the line does not end with \r\n, if non-numeric
characters occur where an integer is expected, if the wrong number of
arguments are present, or if the command line is mal-formed in any other
way.
- "UNKNOWN_COMMAND\r\n" The client sent a command that the server does not
know.
These error responses will not be listed in this document for individual
commands in the following sections, but they are implicitly included in the
description of all commands. Clients should be prepared to receive an error
response after any command.
As a last resort, if the server has a serious error that prevents it from
continuing service to the current client, the server will close the
connection.
Job Lifecycle
-------------
A job in beanstalk gets created by a client with the "put" command. During its
life it can be in one of four states: "ready", "reserved", "delayed", or
"buried". After the put command, a job typically starts out ready. It waits in
the ready queue until a worker comes along and runs the "reserve" command. If
this job is next in the queue, it will be reserved for the worker. The worker
will execute the job; when it is finished the worker will send a "delete"
command to delete the job.
Here is a picture of the typical job lifecycle:
put reserve delete
-----> [READY] ---------> [RESERVED] --------> *poof*
Here is a picture with more possibilities:
put with delay release with delay
----------------> [DELAYED] <------------.
| |
| (time passes) |
| |
put v reserve | delete
-----------------> [READY] ---------> [RESERVED] --------> *poof*
^ ^ | |
| \ release | |
| `-------------' |
| |
| kick |
| |
| bury |
[BURIED] <---------------'
|
| delete
`--------> *poof*
The system has one or more tubes. Each tube consists of a ready queue and a
delay queue. Each job spends its entire life in one tube. Consumers can show
interest in tubes by sending the "watch" command; they can show disinterest by
sending the "ignore" command. This set of interesting tubes is said to be a
consumer's "watch list". When a client reserves a job, it may come from any of
the tubes in its watch list.
When a client connects, its watch list is initially just the tube named
"default". If it submits jobs without having sent a "use" command, they will
live in the tube named "default".
Tubes are created on demand whenever they are referenced. If a tube is empty
(that is, it contains no ready, delayed, or buried jobs) and no client refers
to it, it will be deleted.
Producer Commands
-----------------
The "put" command is for any process that wants to insert a job into the queue.
It comprises a command line followed by the job body:
put <pri> <delay> <ttr> <bytes>\r\n
<data>\r\n
It inserts a job into the client's currently used tube (see the "use" command
below).
- <pri> is an integer < 2**32. Jobs with smaller priority values will be
scheduled before jobs with larger priorities. The most urgent priority is 0;
the least urgent priority is 4,294,967,295.
- <delay> is an integer number of seconds to wait before putting the job in
the ready queue. The job will be in the "delayed" state during this time.
- <ttr> -- time to run -- is an integer number of seconds to allow a worker
to run this job. This time is counted from the moment a worker reserves
this job. If the worker does not delete, release, or bury the job within
<ttr> seconds, the job will time out and the server will release the job.
The minimum ttr is 1. If the client sends 0, the server will silently
increase the ttr to 1.
- <bytes> is an integer indicating the size of the job body, not including the
trailing "\r\n". This value must be less than max-job-size (default: 2**16).
- <data> is the job body -- a sequence of bytes of length <bytes> from the
previous line.
After sending the command line and body, the client waits for a reply, which
may be:
- "INSERTED <id>\r\n" to indicate success.
- <id> is the integer id of the new job
- "BURIED <id>\r\n" if the server ran out of memory trying to grow the
priority queue data structure.
- <id> is the integer id of the new job
- "EXPECTED_CRLF\r\n" The job body must be followed by a CR-LF pair, that is,
"\r\n". These two bytes are not counted in the job size given by the client
in the put command line.
- "JOB_TOO_BIG\r\n" The client has requested to put a job with a body larger
than max-job-size bytes.
- "DRAINING\r\n" This means that the server has been put into "drain mode" and
is no longer accepting new jobs. The client should try another server or
disconnect and try again later. To put the server in drain mode, send the
SIGUSR1 signal to the process.
The "use" command is for producers. Subsequent put commands will put jobs into
the tube specified by this command. If no use command has been issued, jobs
will be put into the tube named "default".
use <tube>\r\n
- <tube> is a name at most 200 bytes. It specifies the tube to use. If the
tube does not exist, it will be created.
The only reply is:
USING <tube>\r\n
- <tube> is the name of the tube now being used.
Worker Commands
---------------
A process that wants to consume jobs from the queue uses "reserve", "delete",
"release", and "bury". The first worker command, "reserve", looks like this:
reserve\r\n
Alternatively, you can specify a timeout as follows:
reserve-with-timeout <seconds>\r\n
This will return a newly-reserved job. If no job is available to be reserved,
beanstalkd will wait to send a response until one becomes available. Once a
job is reserved for the client, the client has limited time to run (TTR) the
job before the job times out. When the job times out, the server will put the
job back into the ready queue. Both the TTR and the actual time left can be
found in response to the stats-job command.
If more than one job is ready, beanstalkd will choose the one with the
smallest priority value. Within each priority, it will choose the one that
was received first.
A timeout value of 0 will cause the server to immediately return either a
response or TIMED_OUT. A positive value of timeout will limit the amount of
time the client will block on the reserve request until a job becomes
available.
During the TTR of a reserved job, the last second is kept by the server as a
safety margin, during which the client will not be made to wait for another
job. If the client issues a reserve command during the safety margin, or if
the safety margin arrives while the client is waiting on a reserve command,
the server will respond with:
DEADLINE_SOON\r\n
This gives the client a chance to delete or release its reserved job before
the server automatically releases it.
TIMED_OUT\r\n
If a non-negative timeout was specified and the timeout exceeded before a job
became available, or if the client's connection is half-closed, the server
will respond with TIMED_OUT.
Otherwise, the only other response to this command is a successful reservation
in the form of a text line followed by the job body:
RESERVED <id> <bytes>\r\n
<data>\r\n
- <id> is the job id -- an integer unique to this job in this instance of
beanstalkd.
- <bytes> is an integer indicating the size of the job body, not including
the trailing "\r\n".
- <data> is the job body -- a sequence of bytes of length <bytes> from the
previous line. This is a verbatim copy of the bytes that were originally
sent to the server in the put command for this job.
The delete command removes a job from the server entirely. It is normally used
by the client when the job has successfully run to completion. A client can
delete jobs that it has reserved, ready jobs, delayed jobs, and jobs that are
buried. The delete command looks like this:
delete <id>\r\n
- <id> is the job id to delete.
The client then waits for one line of response, which may be:
- "DELETED\r\n" to indicate success.
- "NOT_FOUND\r\n" if the job does not exist or is not either reserved by the
client, ready, or buried. This could happen if the job timed out before the
client sent the delete command.
The release command puts a reserved job back into the ready queue (and marks
its state as "ready") to be run by any client. It is normally used when the job
fails because of a transitory error. It looks like this:
release <id> <pri> <delay>\r\n
- <id> is the job id to release.
- <pri> is a new priority to assign to the job.
- <delay> is an integer number of seconds to wait before putting the job in
the ready queue. The job will be in the "delayed" state during this time.
The client expects one line of response, which may be:
- "RELEASED\r\n" to indicate success.
- "BURIED\r\n" if the server ran out of memory trying to grow the priority
queue data structure.
- "NOT_FOUND\r\n" if the job does not exist or is not reserved by the client.
The bury command puts a job into the "buried" state. Buried jobs are put into a
FIFO linked list and will not be touched by the server again until a client
kicks them with the "kick" command.
The bury command looks like this:
bury <id> <pri>\r\n
- <id> is the job id to release.
- <pri> is a new priority to assign to the job.
There are two possible responses:
- "BURIED\r\n" to indicate success.
- "NOT_FOUND\r\n" if the job does not exist or is not reserved by the client.
The "touch" command allows a worker to request more time to work on a job.
This is useful for jobs that potentially take a long time, but you still want
the benefits of a TTR pulling a job away from an unresponsive worker. A worker
may periodically tell the server that it's still alive and processing a job
(e.g. it may do this on DEADLINE_SOON). The command postpones the auto
release of a reserved job until TTR seconds from when the command is issued.
The touch command looks like this:
touch <id>\r\n
- <id> is the ID of a job reserved by the current connection.
There are two possible responses:
- "TOUCHED\r\n" to indicate success.
- "NOT_FOUND\r\n" if the job does not exist or is not reserved by the client.
The "watch" command adds the named tube to the watch list for the current
connection. A reserve command will take a job from any of the tubes in the
watch list. For each new connection, the watch list initially consists of one
tube, named "default".
watch <tube>\r\n
- <tube> is a name at most 200 bytes. It specifies a tube to add to the watch
list. If the tube doesn't exist, it will be created.
The reply is:
WATCHING <count>\r\n
- <count> is the integer number of tubes currently in the watch list.
The "ignore" command is for consumers. It removes the named tube from the
watch list for the current connection.
ignore <tube>\r\n
The reply is one of:
- "WATCHING <count>\r\n" to indicate success.
- <count> is the integer number of tubes currently in the watch list.
- "NOT_IGNORED\r\n" if the client attempts to ignore the only tube in its
watch list.
Other Commands
--------------
The peek commands let the client inspect a job in the system. There are four
variations. All but the first operate only on the currently used tube.
- "peek <id>\r\n" - return job <id>.
- "peek-ready\r\n" - return the next ready job.
- "peek-delayed\r\n" - return the delayed job with the shortest delay left.
- "peek-buried\r\n" - return the next job in the list of buried jobs.
There are two possible responses, either a single line:
- "NOT_FOUND\r\n" if the requested job doesn't exist or there are no jobs in
the requested state.
Or a line followed by a chunk of data, if the command was successful:
FOUND <id> <bytes>\r\n
<data>\r\n
- <id> is the job id.
- <bytes> is an integer indicating the size of the job body, not including
the trailing "\r\n".
- <data> is the job body -- a sequence of bytes of length <bytes> from the
previous line.
The kick command applies only to the currently used tube. It moves jobs into
the ready queue. If there are any buried jobs, it will only kick buried jobs.
Otherwise it will kick delayed jobs. It looks like:
kick <bound>\r\n
- <bound> is an integer upper bound on the number of jobs to kick. The server
will kick no more than <bound> jobs.
The response is of the form:
KICKED <count>\r\n
- <count> is an integer indicating the number of jobs actually kicked.
The kick-job command is a variant of kick that operates with a single job
identified by its job id. If the given job id exists and is in a buried or
delayed state, it will be moved to the ready queue of the the same tube where it
currently belongs. The syntax is:
kick-job <id>\r\n
- <id> is the job id to kick.
The response is one of:
- "NOT_FOUND\r\n" if the job does not exist or is not in a kickable state. This
can also happen upon internal errors.
- "KICKED\r\n" when the operation succeeded.
The stats-job command gives statistical information about the specified job if
it exists. Its form is:
stats-job <id>\r\n
- <id> is a job id.
The response is one of:
- "NOT_FOUND\r\n" if the job does not exist.
- "OK <bytes>\r\n<data>\r\n"
- <bytes> is the size of the following data section in bytes.
- <data> is a sequence of bytes of length <bytes> from the previous line. It
is a YAML file with statistical information represented a dictionary.
The stats-job data is a YAML file representing a single dictionary of strings
to scalars. It contains these keys:
- "id" is the job id
- "tube" is the name of the tube that contains this job
- "state" is "ready" or "delayed" or "reserved" or "buried"
- "pri" is the priority value set by the put, release, or bury commands.
- "age" is the time in seconds since the put command that created this job.
- "delay" is the integer number of seconds to wait before putting this job in
the ready queue.
- "ttr" -- time to run -- is the integer number of seconds a worker is
allowed to run this job.
- "time-left" is the number of seconds left until the server puts this job
into the ready queue. This number is only meaningful if the job is
reserved or delayed. If the job is reserved and this amount of time
elapses before its state changes, it is considered to have timed out.
- "file" is the number of the earliest binlog file containing this job.
If -b wasn't used, this will be 0.
- "reserves" is the number of times this job has been reserved.
- "timeouts" is the number of times this job has timed out during a
reservation.
- "releases" is the number of times a client has released this job from a
reservation.
- "buries" is the number of times this job has been buried.
- "kicks" is the number of times this job has been kicked.
The stats-tube command gives statistical information about the specified tube
if it exists. Its form is:
stats-tube <tube>\r\n
- <tube> is a name at most 200 bytes. Stats will be returned for this tube.
The response is one of:
- "NOT_FOUND\r\n" if the tube does not exist.
- "OK <bytes>\r\n<data>\r\n"
- <bytes> is the size of the following data section in bytes.
- <data> is a sequence of bytes of length <bytes> from the previous line. It
is a YAML file with statistical information represented a dictionary.
The stats-tube data is a YAML file representing a single dictionary of strings
to scalars. It contains these keys:
- "name" is the tube's name.
- "current-jobs-urgent" is the number of ready jobs with priority < 1024 in
this tube.
- "current-jobs-ready" is the number of jobs in the ready queue in this tube.
- "current-jobs-reserved" is the number of jobs reserved by all clients in
this tube.
- "current-jobs-delayed" is the number of delayed jobs in this tube.
- "current-jobs-buried" is the number of buried jobs in this tube.
- "total-jobs" is the cumulative count of jobs created in this tube in
the current beanstalkd process.
- "current-using" is the number of open connections that are currently
using this tube.
- "current-waiting" is the number of open connections that have issued a
reserve command while watching this tube but not yet received a response.
- "current-watching" is the number of open connections that are currently
watching this tube.
- "pause" is the number of seconds the tube has been paused for.
- "cmd-delete" is the cumulative number of delete commands for this tube
- "cmd-pause-tube" is the cumulative number of pause-tube commands for this
tube.
- "pause-time-left" is the number of seconds until the tube is un-paused.
The stats command gives statistical information about the system as a whole.
Its form is:
stats\r\n
The server will respond:
OK <bytes>\r\n
<data>\r\n
- <bytes> is the size of the following data section in bytes.
- <data> is a sequence of bytes of length <bytes> from the previous line. It
is a YAML file with statistical information represented a dictionary.
The stats data for the system is a YAML file representing a single dictionary
of strings to scalars. Entries described as "cumulative" are reset when the
beanstalkd process starts; they are not stored on disk with the -b flag.
- "current-jobs-urgent" is the number of ready jobs with priority < 1024.
- "current-jobs-ready" is the number of jobs in the ready queue.
- "current-jobs-reserved" is the number of jobs reserved by all clients.
- "current-jobs-delayed" is the number of delayed jobs.
- "current-jobs-buried" is the number of buried jobs.
- "cmd-put" is the cumulative number of put commands.
- "cmd-peek" is the cumulative number of peek commands.
- "cmd-peek-ready" is the cumulative number of peek-ready commands.
- "cmd-peek-delayed" is the cumulative number of peek-delayed commands.
- "cmd-peek-buried" is the cumulative number of peek-buried commands.
- "cmd-reserve" is the cumulative number of reserve commands.
- "cmd-use" is the cumulative number of use commands.
- "cmd-watch" is the cumulative number of watch commands.
- "cmd-ignore" is the cumulative number of ignore commands.
- "cmd-delete" is the cumulative number of delete commands.
- "cmd-release" is the cumulative number of release commands.
- "cmd-bury" is the cumulative number of bury commands.
- "cmd-kick" is the cumulative number of kick commands.
- "cmd-stats" is the cumulative number of stats commands.
- "cmd-stats-job" is the cumulative number of stats-job commands.
- "cmd-stats-tube" is the cumulative number of stats-tube commands.
- "cmd-list-tubes" is the cumulative number of list-tubes commands.
- "cmd-list-tube-used" is the cumulative number of list-tube-used commands.
- "cmd-list-tubes-watched" is the cumulative number of list-tubes-watched
commands.
- "cmd-pause-tube" is the cumulative number of pause-tube commands.
- "job-timeouts" is the cumulative count of times a job has timed out.
- "total-jobs" is the cumulative count of jobs created.
- "max-job-size" is the maximum number of bytes in a job.
- "current-tubes" is the number of currently-existing tubes.
- "current-connections" is the number of currently open connections.
- "current-producers" is the number of open connections that have each
issued at least one put command.
- "current-workers" is the number of open connections that have each issued
at least one reserve command.
- "current-waiting" is the number of open connections that have issued a
reserve command but not yet received a response.
- "total-connections" is the cumulative count of connections.
- "pid" is the process id of the server.
- "version" is the version string of the server.
- "rusage-utime" is the cumulative user CPU time of this process in seconds
and microseconds.
- "rusage-stime" is the cumulative system CPU time of this process in
seconds and microseconds.
- "uptime" is the number of seconds since this server process started running.
- "binlog-oldest-index" is the index of the oldest binlog file needed to
store the current jobs.
- "binlog-current-index" is the index of the current binlog file being
written to. If binlog is not active this value will be 0.
- "binlog-max-size" is the maximum size in bytes a binlog file is allowed
to get before a new binlog file is opened.
- "binlog-records-written" is the cumulative number of records written
to the binlog.
- "binlog-records-migrated" is the cumulative number of records written
as part of compaction.
- "id" is a random id string for this server process, generated when each
beanstalkd process starts.
- "hostname" the hostname of the machine as determined by uname.
The list-tubes command returns a list of all existing tubes. Its form is:
list-tubes\r\n
The response is:
OK <bytes>\r\n
<data>\r\n
- <bytes> is the size of the following data section in bytes.
- <data> is a sequence of bytes of length <bytes> from the previous line. It
is a YAML file containing all tube names as a list of strings.
The list-tube-used command returns the tube currently being used by the
client. Its form is:
list-tube-used\r\n
The response is:
USING <tube>\r\n
- <tube> is the name of the tube being used.
The list-tubes-watched command returns a list tubes currently being watched by
the client. Its form is:
list-tubes-watched\r\n
The response is:
OK <bytes>\r\n
<data>\r\n
- <bytes> is the size of the following data section in bytes.
- <data> is a sequence of bytes of length <bytes> from the previous line. It
is a YAML file containing watched tube names as a list of strings.
The quit command simply closes the connection. Its form is:
quit\r\n
The pause-tube command can delay any new job being reserved for a given time. Its form is:
pause-tube <tube-name> <delay>\r\n
- <tube> is the tube to pause
- <delay> is an integer number of seconds < 2**32 to wait before reserving any more
jobs from the queue
There are two possible responses:
- "PAUSED\r\n" to indicate success.
- "NOT_FOUND\r\n" if the tube does not exist.

44
mywiki/tiddlers/Cleanup CI.bjoola.nl.tid Normal file
View File

@ -0,0 +1,44 @@
created: 20180302135343133
creator: user
modified: 20181102170219909
modifier: user
tags:
title: Cleanup CI.bjoola.nl
type: text/vnd.tiddlywiki
```
Host ci.bjoola.nl
Hostname 146.185.146.107
User jenkins
# User root
```
```
ssh ci.bjoola.nl
docker ps -aq |xargs docker rm
docker rmi $(docker images --filter "dangling=true" -q --no-trunc) ;
docker images |grep docker-registry | awk '{print $3}' | xargs docker rmi --force ;
find /var/lib/jenkins/jobs/ -name .dobi -exec sudo rm -rf \{\}/images/ \;
sudo rm /var/lib/jenkins/jobs/vrendly-app/workspace/release/*
sudo rm /var/lib/jenkins/jobs/genifer-dev/workspace/release/*
sudo rm /var/lib/jenkins/jobs/genifer-auth/workspace/release/*
```
```
Host ci-worker
Hostname 192.168.0.115
User www-data
Host ci-worker-01.bjoola.nl
Hostname 174.138.3.187
User www-data
```
```
ssh ci-worker
docker rmi $(docker images --filter "dangling=true" -q --no-trunc) ;
docker images |grep docker-registry | awk '{print $3}' | xargs docker rmi --force ;
find /var/lib/jenkins/workspace/ -name .dobi -exec sudo rm -rf \{\}/images/ \;
```

55
mywiki/tiddlers/CreditForce LIVE.tid Normal file
View File

@ -0,0 +1,55 @@
created: 20180112115643461
creator: user
modified: 20180312173003177
modifier: user
tags:
title: CreditForce LIVE
type: text/vnd.tiddlywiki
Tijmen van Dobbenburgh [10:37 01-2018]
gegevens voor [[CreditForce LIVE]]
creditforce-monolith-live 178.62.192.94
[[countryApplicationId=a8fe7f78-7bf7-e711-80e4-3464a991bb39|https://apps.exactonline.com/nl/nl-NL/Manage/EditApp?countryApplicationId=a8fe7f78-7bf7-e711-80e4-3464a991bb39]]
(VRENDLY SUPPORT ACCOUNT IN EXACT APP STORE)
```
ClientID: 46dc4d3b-af2c-4a78-a67a-4d0ab5b47327
ClientSecret: KYHbza2Ckda1
WebTokenSecret: q1fsUwZQSGFz7ncy
```
[10:37]
andere kan je aanmaken via [[OpenProvider:creditforceonline.nl|https://rcp.openprovider.eu/web/action/index#/dns/details/creditforceonline.nl]]
CNAME lb.digitalefactuur.nl
* https://portal-api.creditforceonline.nl
* https://portal.creditforceonline.nl
* https://debitor.creditforceonline.nl
* http://go.creditforceonline.nl -302-> https://debitor.creditforceonline.nl/app/#/token-login
* http://ideal.creditforceonline.nl -302-> https://debitor.creditforceonline.nl/app/#/token-login
---
! victor
Config is read from disk for LIVE deployment. You need to put contents of ''LASTPASS "portal-api.creditforceonline live victor config"'' secret note into `./operations/deployment/portal-api.creditforceonline.nl.json`
```sh
VERSION=3.1.49-d2bead6e10 DB_PASSWORD=n7B2PRq3r29aYjGYh2p728gG7PwvgrwZ TOKEN_SECRET=U92NNm7zJC2Cn7Vx6g34hX9jFahsPei8 ./operations/deployment/deploy.portal-api.creditforceonline.nl.sh
```
* https://portal-api.creditforceonline.nl/site/version
! creditforce
```sh
VERSION=2.0.100-cf-e476a58a9e ./operations/deployment/deploy.portal.creditforceonline.nl.sh
```
* https://portal.creditforceonline.nl
* https://debitor.creditforceonline.nl
* http://go.creditforceonline.nl -302-> https://debitor.creditforceonline.nl/app/#/token-login
* http://ideal.creditforceonline.nl -302-> https://debitor.creditforceonline.nl/app/#/token-login

28
mywiki/tiddlers/Genifer Swarm.tid Normal file
View File

@ -0,0 +1,28 @@
created: 20180418122731117
creator: user
modified: 20180418122806528
modifier: user
tags:
title: Genifer Swarm
type: text/vnd.tiddlywiki
DOCKER SWARM
docker swarm join --token SWMTKN-1-30urz08fvvbbpeu3b6g185eooxvynhdtpwfb9dydy82pbs1p8r-b3zfsgvsb7wcuo6xmnqaq6ttx 10.133.27.94:2377
MASTER
167.99.217.21
10.133.27.94
WORKER 1
206.189.10.187
10.133.53.51
WORKER 2
206.189.10.189
10.133.53.56
WORKER 3
206.189.12.60
10.133.53.49
visualizer http://167.99.217.21:8080/

14
mywiki/tiddlers/LaunchDaemon.tid Normal file
View File

@ -0,0 +1,14 @@
created: 20190504100259844
creator: user
modified: 20190504100503828
modifier: user
tags: osx
title: LaunchDaemon
type: text/vnd.tiddlywiki
; How to start/stop/restart launchd services from the command line?
: https://serverfault.com/questions/194832/how-to-start-stop-restart-launchd-services-from-the-command-line
```sh
$ sudo launchctl unload /Library/LaunchDaemons/ssh.plist
```

29
mywiki/tiddlers/Live Backup.tid Normal file
View File

@ -0,0 +1,29 @@
created: 20190124142051851
creator: user
modified: 20190128093420483
modifier: user
tags:
title: Live Backup
type: text/vnd.tiddlywiki
setup tunnel to live-db and
start `dobi dev`
```
DB_USER=dev_creditforce DB_NAME=dev_creditforce DB_PASSWORD=4sdf2As221 DB_HOST=192.168.0.227 ./operations/live/vrendly/backupLiveDB.sh
```
!LIVE
```
DB_USER=live_notarieelbetalen DB_NAME=live_notarieelbetalen DB_PASSWORD=k4c74C8rs9T8dP7uGpafBYBBzKcG76D6 DB_HOST=192.168.77.1 ./operations/live/vrendly/backupLiveDB.sh
DB_USER=creditforce DB_NAME=live_creditforce DB_PASSWORD=n7B2PRq3r29aYjGYh2p728gG7PwvgrwZ DB_HOST=192.168.77.1 ./operations/live/vrendly/backupLiveDB.sh
DB_USER=creditforce DB_NAME=live_debbt_creditforce DB_PASSWORD=n7B2PRq3r29aYjGYh2p728gG7PwvgrwZ DB_HOST=192.168.77.1 ./operations/live/vrendly/backupLiveDB.sh
DB_USER=vrendly DB_NAME=live_vrendly DB_PASSWORD=Hjf729hvkjlller7cg37rgllhukKhfjdkkskHdf839 DB_HOST=192.168.77.1 ./operations/live/vrendly/backupLiveDB.sh
DB_USER=vrendly DB_NAME=live_debbt DB_PASSWORD=Hjf729hvkjlller7cg37rgllhukKhfjdkkskHdf839 DB_HOST=192.168.77.1 ./operations/live/vrendly/backupLiveDB.sh
```

60
mywiki/tiddlers/New Dev Machine.tid Normal file
View File

@ -0,0 +1,60 @@
created: 20190504211837442
creator: user
modified: 20190506152929196
modifier: user
tags: osx
title: New Dev Machine
type: text/vnd.tiddlywiki
; install from AppStore
: xcode
; install commandline developer tools
: `xcode-select --install`
; install ohmyzsh:
: https://ohmyz.sh
: `sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"`
; install brew:
: https://brew.sh
: `/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"`
; install some apps:
: $ `brew cask install \
1password \
dropbox \
insomnia \
virtualbox \
flux \
iterm2 \
jetbrains-toolbox \
sizeup \
google-chrome \
slack \
sourcetree \
grandperspective \
`
; install some tools:
: $ `brew install \
git \
docker \
docker-compose \
docker-machine \
node \
n \
multitail \
unrar \
watch \
pv \
awscli \
yarn \
`
; disable ExactVPN:
: $ `sudo launchctl unload /Library/LaunchDaemons/net.pulsesecure.AccessService.plist`

11
mywiki/tiddlers/New Tiddler.tid Normal file
View File

@ -0,0 +1,11 @@
created: 20161110215845556
creator: user
modified: 20161110220729343
modifier: user
tags:
title: New Tiddler
type: text/vnd.tiddlywiki
https://github.com/rancher/community-catalog/issues/109
docker run -e SETTINGS_FLAVOR=local -e STORAGE_PATH=/registry -p 5000:5000 -v /registry:/registry --name registry registry

17
mywiki/tiddlers/PortForwarding.tid Normal file
View File

@ -0,0 +1,17 @@
created: 20180907160514426
creator: user
modified: 20180907161924988
modifier: user
tags:
title: PortForwarding
type: text/vnd.tiddlywiki
iptables
--------
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 2.2.2.2:4443
iptables -t nat -A POSTROUTING -j MASQUERADE
443 is local to machine running iptables
4443 is destination machine port

23
mywiki/tiddlers/Tunnels.tid Normal file
View File

@ -0,0 +1,23 @@
created: 20180810122954587
creator: user
modified: 20181128145217114
modifier: user
tags:
title: Tunnels
type: text/vnd.tiddlywiki
live db
```
ssh live-db1 -L 0.0.0.0:3306:localhost:3306
```
dev db
```
ssh server2 -t lxc-attach -n galera_one -- ssh fruit@192.168.0.22 -R 0.0.0.0:3306:0.0.0.0:3306
ssh server2
lxc-attach -n galera_one
ssh fruit@192.168.0.22 -R 0.0.0.0:3306:0.0.0.0:3306
```

38
mywiki/tiddlers/Vrendly DEMO.tid Normal file
View File

@ -0,0 +1,38 @@
created: 20180122171906288
creator: user
modified: 20180123091602155
modifier: user
tags:
title: Vrendly DEMO
type: text/vnd.tiddlywiki
```
"vrendlyDemo": {
"exact": {
"clientID": "544c8c85-d0d5-41c2-b77b-d04acbcaf15e",
"clientSecret": "MCHQ5dzEwGNK"
}
}
```
---
! victor
Config is read from disk for LIVE deployment. You need to put contents of ''LASTPASS "portal-api.creditforceonline live victor config"'' secret note into `./operations/deployment/demo-api.vrendly.nl.json`
```sh
VERSION=3.1.49-d2bead6e10 DB_PASSWORD=Pofd81818kj3k22 TOKEN_SECRET=2RDxH32ddcxnN2yUg9Bwvb4B77r8Xa2C ./operations/deployment/deploy.demo-api.vrendly.nl.sh
```
* https://demo-api.vrendly.nl/site/version
! vrendly Demo
```sh
VERSION=2.0.101-de370da119 ./operations/deployment/deploy.demo.vrendly.nl.sh
```
* https://demo.vrendly.nl
* https://demo-debitor.creditforceonline.nl
* http://demo-go.creditforceonline.nl -302-> https://demo-debitor.creditforceonline.nl/app/#/token-login
* http://demo-ideal.creditforceonline.nl -302-> https://demo-debitor.creditforceonline.nl/app/#/token-login

32
mywiki/tiddlers/ci.bjoola.nl.tid Normal file
View File

@ -0,0 +1,32 @@
created: 20180725125918879
creator: user
modified: 20180725130128422
modifier: user
tags:
title: ci.bjoola.nl
type: text/vnd.tiddlywiki
2.90
;https://jenkins.io/changelog/
;war repository
:http://mirrors.jenkins.io/war/
upgrading hangs startup:
```
INFO: Injecting JRuby into XStream
Trying to load models from /var/lib/jenkins/plugins/travis-yml/WEB-INF/classes/models
Loading /var/lib/jenkins/plugins/travis-yml/WEB-INF/classes/models/travis_yml_builder.rb
Loading /var/lib/jenkins/plugins/travis-yml/WEB-INF/classes/models/travis_yml_script.rb
----- HANG version > 2.90 last checked with 2.134 -----
Jul 25, 2018 2:40:49 PM jenkins.InitReactorRunner$1 onAttained
INFO: Prepared all plugins
Jul 25, 2018 2:40:49 PM jenkins.InitReactorRunner$1 onAttained
INFO: Started all plugins
Jul 25, 2018 2:40:51 PM jenkins.InitReactorRunner$1 onAttained
INFO: Augmented all extensions
```

11
mywiki/tiddlers/docker cleanup.tid Normal file
View File

@ -0,0 +1,11 @@
created: 20180302134738347
creator: user
modified: 20180302134951047
modifier: user
tags: docker
title: docker cleanup
type: text/vnd.tiddlywiki
`docker images --no-trunc |grep months | grep none | awk '{print $3}' | xargs -r docker rmi`
* https://lebkowski.name/docker-volumes/

40
mywiki/tiddlers/renew certs forward.bjoola.nl.tid Normal file
View File

@ -0,0 +1,40 @@
created: 20180423083743685
creator: user
modified: 20180423083811492
modifier: user
tags:
title: renew certs forward.bjoola.nl
type: text/vnd.tiddlywiki
```
service nginx stop
certbot certonly -d acceptatie.creditforce.bjoola.com -d cycle-acceptatie.creditforce-api.bjoola.com -d acceptatie.creditforce-api.bjoola.com -d acceptatie.creditforce-cycle.bjoola.com -d my-acceptatie.creditforce.bjoola.com -d pay-acceptatie.creditforce.bjoola.com -d acceptatie.debbt-creditforce-api.bjoola.com
certbot certonly -d acceptatie.digitalefactuur.nl
certbot certonly -d acceptatie.vrendly.bjoola.com -d acceptatie.auth.bjoola.com -d acceptatie.genifer.bjoola.com -d acceptatie.vrendly-api.bjoola.com -d acceptatie.debbt-api.bjoola.com
certbot certonly -d auth-dev.bjoola.nl
certbot certonly -d auth-staging.bjoola.nl
certbot certonly -d dev2.vrendly.bjoola.com -d dev2.auth.bjoola.com -d dev2.genifer.bjoola.com -d dev2.vrendly-api.bjoola.com -d dev2.creditforce.bjoola.com -d dev2.creditforce-api.bjoola.com
certbot certonly -d dev.creditforce.bjoola.com -d cycle-dev.creditforce-api.bjoola.com -d dev.creditforce-api.bjoola.com -d dev.creditforce-cycle.bjoola.com -d my-dev.creditforce.bjoola.com -d pay-dev.creditforce.bjoola.com -d dev.debbt-creditforce-api.bjoola.com
certbot certonly -d development.digitalefactuur.nl
certbot certonly -d dev.vrendly.bjoola.com -d dev.auth.bjoola.com -d dev.genifer.bjoola.com -d dev.vrendly-api.bjoola.com -d dev.debbt-api.bjoola.com
certbot certonly -d phpmyadmin.bjoola.nl
certbot certonly -d staging-api-evaluator.evalytics.nl
certbot certonly -d staging-api-portal.evalytics.nl
certbot certonly -d staging-api.vrendly.nl
certbot certonly -d staging-app.evalytics.nl
certbot certonly -d staging.evalytics.nl
certbot certonly -d staging.vrendly.bjoola.com -d staging.auth.bjoola.com -d staging.genifer.bjoola.com -d staging.vrendly-api.bjoola.com -d staging.debbt-api.bjoola.com
certbot certonly -d staging.creditforce.bjoola.com -d cycle-staging.creditforce-api.bjoola.com -d staging.creditforce-api.bjoola.com -d staging.creditforce-cycle.bjoola.com -d my-staging.creditforce.bjoola.com -d pay-staging.creditforce.bjoola.com -d staging.debbt-creditforce-api.bjoola.com
certbot certonly -d staging.digitalefactuur.nl
certbot certonly -d staging-docent.evalytics.nl
certbot certonly -d staging.genifer.bjoola.nl
certbot certonly -d staging-new.genifer.bjoola.nl
certbot certonly -d staging-portal.evalytics.nl
certbot certonly -d staging-evalueren.evalytics.nl -d staging-student.evalytics.nl -d staging-code.evalytics.nl
certbot certonly -d staging-www.evalytics.nl -d staging-api.evalytics.nl
certbot certonly -d staging.evalytics.nl
certbot certonly -d tappan.bjoola.nl
certbot certonly -d test.notarieelbetalen.bjoola.com -d test.notarieelbetalen-api.bjoola.com
certbot certonly -d test.server.bjoola.nl
service nginx start
```

24
mywiki/tiddlers/renew certs lb.digitalefactuur.nl.tid Normal file
View File

@ -0,0 +1,24 @@
created: 20180413162419071
creator: user
modified: 20180423083826015
modifier: user
tags:
title: renew certs lb.digitalefactuur.nl
type: text/vnd.tiddlywiki
```
~/certbot-auto certonly -d demo.vrendly.nl -d demo-api.vrendly.nl -d demo-go.vrendly.nl -d demo-ideal.vrendly.nl -d demo-debitor.vrendly.nl
~/certbot-auto certonly -d debitor.creditforceonline.nl -d go.creditforceonline.nl -d ideal.creditforceonline.nl -d portal-api.creditforceonline.nl -d portal.creditforceonline.nl
~/certbot-auto certonly -d acceptatie.auth.bjoola.com -d acceptatie.creditforce-api.bjoola.com -d acceptatie.creditforce-cycle.bjoola.com -d acceptatie.creditforce.bjoola.com -d acceptatie.genifer.bjoola.com -d acceptatie.vrendly-api.bjoola.com -d acceptatie.vrendly.bjoola.com -d cycle-acceptatie.creditforce-api.bjoola.com -d cycle-dev.creditforce-api.bjoola.com -d cycle-staging.creditforce-api.bjoola.com -d dev.auth.bjoola.com -d dev.creditforce-api.bjoola.com -d dev.creditforce-cycle.bjoola.com -d dev.creditforce.bjoola.com -d dev.genifer.bjoola.com -d dev.vrendly-api.bjoola.com -d dev.vrendly.bjoola.com -d my-acceptatie.creditforce.bjoola.com -d my-dev.creditforce.bjoola.com -d my-staging.creditforce.bjoola.com -d pay-acceptatie.creditforce.bjoola.com -d pay-dev.creditforce.bjoola.com -d pay-staging.creditforce.bjoola.com -d staging.auth.bjoola.com -d staging.creditforce-api.bjoola.com -d staging.creditforce-cycle.bjoola.com -d staging.creditforce.bjoola.com -d staging.genifer.bjoola.com -d staging.vrendly-api.bjoola.com -d staging.vrendly.bjoola.com
~/certbot-auto certonly -d administratie.digitalefactuur.nl -d api.digitalefactuur.nl -d auth.digitalefactuur.nl -d auth.vrendly.nl -d billingonline.onlinebeheer.eu -d debitor.vrendly.nl -d digitalefactuur.be -d digitalefactuur.nl -d facturen.thinq.nl -d factuur.skal.nl -d go.vrendly.nl -d ideal.vrendly.nl -d lb.digitalefactuur.nl -d online.digitalefactuur.nl -d online.mijnbedrijfs.nl -d ortal.genifer.xyz -d portal-api.vrendly.nl -d portal.genifer.xyz -d portal.vrendly.nl -d sesam.toegang.xyz -d www.digitalefactuur.be -d www.digitalefactuur.nl
~/certbot-auto certonly
-d portal.vrendly.nl auth.digitalefactuur.nl,
auth.vrendly.nl, debitor.vrendly.nl, go.vrendly.nl, ideal.vrendly.nl,
ortal.genifer.xyz, portal-api.vrendly.nl, sesam.toegang.xyz
~/certbot-auto certonly -d auth-dev.bjoola.nl -d staging-new.genifer.bjoola.nl -d staging.digitalefactuur.nl -d staging.vrendly.nl
```

25
mywiki/tiddlers/unpause osx.tid Normal file
View File

@ -0,0 +1,25 @@
created: 20190211075526808
creator: user
modified: 20190211080022770
modifier: user
tags:
title: unpause osx
type: text/vnd.tiddlywiki
;https://superuser.com/questions/118190/unpause-application-in-mac-os-x
To un-pause all applications, run this command in Terminal:
`pkill -CONT -u $UID`
or (as suggested here):
`kill -CONT -1`
To un-pause the specific app (such as Chrome), try:
`kill -CONT $(pgrep Chrome)`
Consider adding the following alias into your rc files (such as ~/.bashrc):
`alias unpause="pkill -CONT -u $UID"`
So next time you may just run: unpause.