pie-ai

#!/bin/bash
URL=$(curl http://mirrors.jenkins-ci.org/war/latest/jenkins.war -s -L -I -o /dev/null -w '%{url_effective}')
#echo "url to download jenkins from: ${URL}"

VERSION="not-detected"
for PART in $(echo ${URL} | tr "\/" "\n")
do
  #echo "part: ${PART}"
  if [ "${PART}" != "jenkins.war" ]; then
    VERSION=${PART}

pie-ai

#!/bin/bash

set -o errexit
echo "Removing exited docker containers..."
docker ps -a -f status=exited -q | xargs -r docker rm -v

echo "Removing dangling images..."
docker images --no-trunc -q -f dangling=true | xargs -r docker rmi

echo "Removing unused docker images"

pie-ai

HOST="esentool.ted.europa.eu"
for ADDRESS in $(nslookup ${HOST}|grep Address|grep -v "#"); do 
echo "'${ADDRESS}'"; 
	if [ "${ADDRESS}" != "Address:" ]; then
    	curl https://${HOST} --resolve ${HOST}:443:${ADDRESS}
    fi
done

pie-ai

#!/bin/bash
 
usage()
{
cat <<EOF
Usage: $(basename $0) [options]
 
This shell script is a simple wrapper around the openssl binary. It uses
s_client to get certificate information from remote hosts, or x509 for local
certificate files. It can parse out some of the openssl output or just dump all

pie-ai

#!/usr/bin/env bash

set -e
[ -z "$DEBUG" ] || set -x;

usage() {
  echo "$0 <repo> <tag> [<release name>] [-- <asset>...]" >&2;
}

if [ "$1" = "-h" -o "$1" = "--help" ]; then

pie-ai

image: golang:latest

variables:
  REPO_NAME: gitlab.com/***/***

before_script:
  - go version
  - echo $CI_BUILD_REF
  - echo $CI_PROJECT_DIR

pie-ai

README

Let Tomcat is download and installed under /opt/tomcat. Also, let tomcat be a non-provileged user under which the server will be running.

We assume that we keep server's binaries under /opt/tomcat and we will create a server instance named foo under /var/tomcat/ (carrying its own conf, logs, webapps, work, lib directories). See also https://dzone.com/articles/running-multiple-tomcat.

Create a template service unit file at /etc/systemd/system/tomcat@.service:

pie-ai

Setup CoreDNS w/ etcd backend

Why CoreDNS

[CoreDNS][coredns] was designed from the ground up to provide robust, plugin-based DNS server for use in cloud environments. Namely, it serves as the default primary service discovery mechanism for Kubernetes.

Using CoreDNS allows us to have a lightweight DNS server on RockNSM (11 Mb binary is all that's needed!) to facilitate multi-node service discovery. Alternatively, if another existing DNS service is available, this can be used instead. Aligning with the way the Kubernetes manages service discovery also allows us to build new RockNSM features in parallel with the coming Kubernetes support.

RockNSM Application