Thuan Duong thuandt

Installing XenServer 6.2.0 from a USB Stick

Download the XenServer 6.2.0 ISO image
Format a USB stick using FAT32.
Use unetbootin to install the ISO to the USB stick. Use the “DiskImage” option instead of the “Distribution” one, and point it right to the ISO file.
Now we need to fix up some boot stuff (All paths are relative to the root of the USB drive)

Keybase proof

I hereby claim:

I am thuandt on github.
I am thuandt (https://keybase.io/thuandt) on keybase.
I have a public key ASAOXz-V0iQWVO2CXIGKgcuhu_js3JzwICItI0Szy2unOAo

To claim this, I am signing this object:

RAID-Z

The strongest valid recommendation based on exact fitting of blocks into stripes is the following: If you are using RAID-Z with 512-byte sector devices with recordsize=4K or 8K and compression=off (but you probably want compression=lz4): use at least 5 disks with RAIDZ1; use at least 6 disks with RAIDZ2; and use at least 11 disks with RAIDZ3.

To summarize: Use RAID-Z. Not too wide. Enable compression.

Types

A type is a collection of possible values. An integer can have values 0, 1, 2, 3, etc.; a boolean can have values true and false. We can imagine any type we like: for example, a HighFive type that allows the values "hi" or 5, but nothing else. It's not a string and it's not an integer; it's its own, separate type.

Statically typed languages constrain variables' types: the programming language might know, for example, that x is an Integer. In that case, the programmer isn't allowed to say x = true; that would be an invalid program. The compiler will refuse to compile it, so we can't even run it.

GCP & GKE setup

$ gcloud auth application-default login
$ gcloud config set core/project ${GCP_PROJECT}
$ gcloud config set core/account ${SERVICE_ACCOUNT}
$ gcloud config set compute/region ${REGION}
$ gcloud config set compute/zone ${ZONE}
$ gcloud config set container/cluster ${CLUSTER_NAME}
# gcloud config set container/use_client_certificate True

Random delay for cron.daily, cron.weekly, cron.monthly

Source

Wouldn’t it be nice if cron’s daily, weekly and monthly jobs could be run with a slight offset? At least that’s what I thought when 20+ servers were hitting my backup infrastructure at once. The scripts in /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly are triggered directly from crontab at fixed times. Here’s what /etc/crontab looks like in Ubuntu Server 16.04:

Requirements

no upfront installation/agents on remote/slave machines - ssh should be enough
application components should use third-party software, e.g. HDFS, Spark's cluster, deployed separately
configuration templating
environment requires/asserts, i.e. we need a JVM in a given version before doing deployment
deployment process run from Jenkins

	/* Disable "List all Tabs" Button */
	.tabs-alltabs-button {
	display: none !important;
	}

	/* Disable Container box for "List all Tabs" Button */
	.tabs-alltabs-box {
	display: none !important;
	}

	# List unique values in a DataFrame column
	# h/t @makmanalp for the updated syntax!
	df['Column Name'].unique()

	# Convert Series datatype to numeric (will error if column has non-numeric values)
	# h/t @makmanalp
	pd.to_numeric(df['Column Name'])

	# Convert Series datatype to numeric, changing non-numeric values to NaN
	# h/t @makmanalp for the updated syntax!