samjaninf

#!/bin/bash

set -ex

echo "#!/bin/sh\nexit 0" > /usr/sbin/policy-rc.d
echo 'Acquire::ForceIPv4 "true";' > /etc/apt/apt.conf.d/99force-ipv4

rm -rf /var/lib/apt/lists/* preseed.txt

echo "postfix postfix/main_mailer_type string Internet site" > preseed.txt

samjaninf

#301 Redirects for .htaccess

#Redirect a single page:
Redirect 301 /pagename.php http://www.domain.com/pagename.html

#Redirect an entire site:
Redirect 301 / http://www.domain.com/

#Redirect an entire site to a sub folder
Redirect 301 / http://www.domain.com/subfolder/

samjaninf

So today I'm going to be a little different and talk about one technical aspect of my game [TinyKeep](http://tinykeep.com/), that is random procedural dungeon generation. It's pretty over-engineered, but hopefully will give anyone interested some ideas on generating dungeon layouts for their own games.

###The interactive demo can be found here: [Dungeon Generation Demo](http://tinykeep.com/dungen/)
####Here's how I do it, step by step:
1. First I set the number of cells I want to generate, say 150. This is an arbitrary amount really, but the higher the number the larger the dungeon and in general more complexity.
2. For each "cell" I spawn a Rectangle of random width and length within some radius. Again the radius doesn't matter too much, but it should probably be proportionate to the number of cells.
  *Instead of using uniformly distributed random numbers (the default Math.random generator in most languages), I'm using [Park-Miller Normal Distribution](https://en.wikipedia.org/wiki/Normal_distribution). Th

samjaninf

Zimbra Letsencrypt SSL Renew

Zimbra Version: Release 8.6.0_GA_1153.RHEL7_64_20141215151110 RHEL7_64 FOSS edition

Based on Zimbra Article KB 22434 : https://wiki.zimbra.com/wiki/Installing_a_LetsEncrypt_SSL_Certificate

Let's Begin

Log on Zimbra user then stop proxy and mail box service for renew proccess.

su zimbra

samjaninf

7f9c8bfeb000-7f9c8c1eb000 ---p 00060000 ca:01 4304415                    /usr/lib64/libpcre.so.1.2.0
7f9c8c1eb000-7f9c8c1ec000 r--p 00060000 ca:01 4304415                    /usr/lib64/libpcre.so.1.2.0
7f9c8c1ec000-7f9c8c1ed000 rw-p 00061000 ca:01 4304415                    /usr/lib64/libpcre.so.1.2.0
7f9c8c1ed000-7f9c8c20e000 r-xp 00000000 ca:01 4271978                    /usr/lib64/ld-2.17.so
7f9c8c223000-7f9c8c235000 rw-s 00000000 00:04 558417                     /dev/zero (deleted)
7f9c8c377000-7f9c8c3f5000 rw-s 00000000 00:04 723009                     /dev/zero (deleted)
7f9c8c3f5000-7f9c8c3f9000 r-xp 00000000 ca:01 4304377                    /usr/lib64/libsystemd-daemon.so.0.0.12
7f9c8c3f9000-7f9c8c3fa000 ---p 00004000 ca:01 4304377                    /usr/lib64/libsystemd-daemon.so.0.0.12
7f9c8c3fa000-7f9c8c3fb000 r--p 00004000 ca:01 4304377                    /usr/lib64/libsystemd-daemon.so.0.0.12
7f9c8c3fb000-7f9c8c3fc000 rw-p 00005000 ca:01 4304377                    /usr/lib64/libsystemd-daemon.so

samjaninf

This was located at: https://blog.nousefreak.be/blog/letsencrypt-nginx-reverse-proxy

Letsencrypt: nginx reverse proxy
TLS certificates (or SSL certificates) is something lots of people might have wanted, but they rarely were willing to spend their money on it. Since a few days letsencrypt solves this problem. At least for those who run their own server. Letsencrypt comes with a different approach to certificate request and certificate require times, aiming for a more automated future.

Letsencrypt
Now that letsencrypt is in public beta everyone can benifit from it and provide a secure connection for their website users.
Because letsencrypt will only provide certificates that are valid for a maximum of 90 days, you will likely want to automate the renewal process.

Nginx

samjaninf

{
  "kind": "Template",
  "apiVersion": "v1",
  "metadata": {
    "name": "gitlab-ce",
    "annotations": {
      "iconClass": "icon-gitlab",
      "description": "GitLab. Collaboration and source control management: code, test, and deploy together! \n\n GitLab requries that the serviceaccount for the main GitLab app be added to the anyuid security context. The service account name is: <application name>-user",
      "tags": "instant-app,gitlab,VCS,ci-cd"
    }

samjaninf

[Unit]
Description=WS02 Identity Server

[Service]
Type=simple
PIDFile=/opt/WSO2/wso2is-5.4.0/wso2carbon.pid
Environment=JAVA_HOME=/usr/java/jdk1.8.0_161
Environment=CARBON_HOME=/opt/WSO2/wso2is-5.4.0
User=wso2
PermissionsStartOnly=true

samjaninf

# Advanced config for NGINX
	server_tokens off;
	add_header X-XSS-Protection "1; mode=block";
	add_header X-Content-Type-Options nosniff;

# Redirect all HTTP traffic to HTTPS
server {
   listen 80;
   	server_name www.domain.com domain.com;
   	return 301 https://$host$request_uri;

samjaninf

README

This gist assumes you are migrating an existing site for www.example.com — ideally WordPress — to a new server — ideally Ubuntu Server 16.04 LTS — and wish to enable HTTP/2 (backwards compatibile with HTTP/1.1) with always-on HTTPS, caching, compression, and more. Although these instructions are geared towards WordPress, they should be trivially extensible to other PHP frameworks, other FastCGI backends, and even non-FastCGI backends (using proxy in lieu of fastcgi in the terminal Caddyfile stanza).

Quickstart: Use your own naked and canonical domain names instead of example.com and www.example.com and customize the Caddyfile and VCL provided in this gist to your preferences!

These instructions target Varnish Cache 4.1, PHP-FPM 7.0, and Caddy 0.10. (I'm using MariaDB 10.1 as well, but that's not relevant to this guide.)