This year was no different, and on my travels through the statement, I stumbled upon my LastPass subscription.

While there are two certainties for everyone in life (death and taxes), for me there are also two Sisyphean tasks that I continue to work on:

• Unsubscribing for emails
• Ceasing subscriptions

Figuring I could save some money here, and the inertia to leave a password manager is possibly even higher than leaving your bank, I felt up to the challenge.

Why not LastPass?

This would have been a good question 5-10 years ago, but honestly I feel like the more relevant question now is Why LastPass?

Since their acquisition by LogMeIn in 2015, the only new feature I've seen is an increase in cost. I've been a premium subscriber for a few years in order to share password folders, but it still irks me that they use predatory practices to stymie usage of their free account.

The most egregious of which is the recent limitation of one device per free user. Honestly, which person nowadays only has one device? I find it to be an extremely security hindering limitation for a company that states:

Security is our highest priority at LastPass

But it's not just price gouging that's given me the ick. It's also the aggregation of security incidents in 2015, 2016, 2017, 2019, and 2021. I want my most secure data to remain secure and my trust, the most thing important (currently) in an online world has been shaken. I say currently because zero-trust is neat.

What are the alternatives?

LastPass isn't the boy without a date at prom. There're a handful of password managers which have gained prevalence over the last few years to choose from from 1Password to KeyPassX to Dashlane. Each has their own benefits, drawbacks, and pricing.

Ultimately though, I chose to go with Bitwarden and it was down to three reasons:

• Open Source (Despite leaving the FOSS world I'm still a FOSS boy at heart)
• A free account that hasn't been hamstrung into impracticality
• Strong emphasis on security both in system architecture and level of audit

While I could have signed up for a free account on the Bitwarden website, I decided to go full neckbeard and host my own password manager. This was 50:50 living my open source tenets as well as just seeing whether I could.

How did I install Bitwarden?

In a word: Ansible.

In a few more words, I created a new 1GB/1CPU Digital Ocean droplet (referral link) using Ubuntu 18.04 LTS because I wanted to ensure complete separation between where my passwords are stored and other servers. I also enabled automatic backups because why not right?

Once the server was provisioned, I SSH'd in and ran the following commands to install Ansible and the packages I'd require.

apt-get update
apt-get upgrade
add-apt-repository --yes --update ppa:ansible/ansible
apt install ansible
ansible-galaxy install geerlingguy.swap
ansible-galaxy install ahuffman.resolv
ansible-galaxy install geerlingguy.security
ansible-galaxy install geerlingguy.firewall
ansible-galaxy install geerlingguy.ntp
ansible-galaxy install geerlingguy.certbot
ansible-galaxy install geerlingguy.nginx
ansible-galaxy install geerlingguy.postgresql
ansible-galaxy install geerlingguy.postfix
ansible-galaxy install jenstimmerman.vaultwarden
ansible-galaxy install adamruzicka.wireguard

I did end up having to use the version of jenstimmerman.vaultwarden from GitHub rather than Ansible Galaxy because 0.5 hadn't been pushed. The author has since fixed that though!

After this, I created a custom role and placed it the following configuration in  /etc/ansible/roles/yphonius.servername/tasks/main.yml for some of the tweaks I'd need in the server:

# Create required users and ensure periodic running of Ansible
- name: Ensure typhonius group exists
  group:
    name: typhonius
    state: present

- name: Add the user typhonius
  user:
    name: typhonius
    groups: typhonius,sudo
    create_home: true
    shell: '/bin/bash'

- name: Installing ssh key for typhonius
  authorized_key:
    user: typhonius
    key: "{{ lookup('file', './files/authorized_keys.typhonius.pub') }}"

- name: Add the user bitwarden
  user:
    name: bitwarden
    create_home: false
    shell: '/bin/nologin'

- name: Runs Ansible on cron
  cron:
    name: "Ansible cron"
    state: "present"
    user: "root"
    hour: "15"
    minute: "0"
    job: '/usr/bin/ansible-playbook /etc/ansible/servername.yml'

# Required packages for Certbot
- name: install unzip
  package:
    name: unzip
    state: present

- name: install openresolv
  package:
    name: openresolv
    state: present

# For Wireguard
- sysctl:
    name: net.ipv4.ip_forward
    value: '1'
    state: present
    reload: yes

- sysctl:
    name: net.ipv6.conf.all.forwarding
    value: '1'
    state: present
    reload: yes

- sysctl:
    name: net.ipv4.conf.wg0.route_localnet
    value: '1'
    state: present
    reload: yes

I then created a servername.yml in /etc/ansible and filled it with the following

- hosts: localhost
  vars_files:
    - vars/main.yml
  roles:
    - { role: typhonius.servername }
    - { role: geerlingguy.swap }
    - { role: ahuffman.resolv }
    - { role: geerlingguy.security }
    - { role: geerlingguy.firewall }
    - { role: geerlingguy.ntp }
    - { role: geerlingguy.certbot }
    - { role: geerlingguy.nginx }
    - { role: geerlingguy.postgresql }
    - { role: geerlingguy.postfix }
    - { role: jenstimmerman.vaultwarden }
    - { role: adamruzicka.wireguard }

ansible_python_interpreter: /usr/bin/python3

# geerlingguy.nginx
nginx_extra_http_options: |
        resolver 1.1.1.1;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

nginx_remove_default_vhost: true
nginx_server_tokens: "off"
nginx_multi_accept: "on"
nginx_listen_ipv6: false
nginx_vhosts:
  - server_name: "servername.adammalone.net"
    listen: "127.0.0.1:443 ssl http2"
    state: "present"
    template: "{{ nginx_vhost_template }}"
    filename: "servername.adammalone.net-https.conf"
    extra_parameters: |
        location / { deny all; }
        ssl_certificate     /etc/letsencrypt/live/servername.adammalone.net/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/servername.adammalone.net/privkey.pem;
  - server_name: "bitwarden.adammalone.net"
    listen: "127.0.0.1:443 ssl http2"
    filename: "bitwarden.adammalone.net-https.conf"
    extra_parameters: |
        ssl_certificate     /etc/letsencrypt/live/bitwarden.adammalone.net/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/bitwarden.adammalone.net/privkey.pem;
        location / {
                proxy_pass http://localhost:8008/;
                proxy_set_header Host $server_name;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        location /notifications/hub {
                proxy_pass http://localhost:3003;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
        location /notifications/hub/negotiate {
                proxy_pass http://localhost:8008;
        }
        add_header X-Frame-Options SAMEORIGIN;
        add_header Referrer-Policy "strict-origin-when-cross-origin";
        add_header Content-Security-Policy "default-src 'self'; prefetch-src 'self'; connect-src 'self' adammalone.report-uri.com; font-src 'self' data:; frame-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' ; style-src 'self' 'unsafe-inline'; media-src 'self'; base-uri 'self'; report-to csp-endpoint";
        add_header Report-To '{"group":"csp-endpoint","max_age":31536000,"endpoints":[{"url":"https://adammalone.report-uri.com/r/d/csp/enforce"}]},{"group":"default","max_age":31536000,"endpoints":[{"url":"https://adammalone.report-uri.com/a/d/g"}],"include_subdomains":true}';
        add_header X-Content-Type-Options "nosniff";
        add_header Feature-Policy "accelerometer 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; payment 'none'; usb 'none'";

# geerlingguy.ntp
ntp_manage_config: true
  - "127.0.0.1"
  - "::1"

# geerlingguy.security
security_ssh_port: 38387
security_autoupdate_mail_to: "servername@adammalone.net"
security_sudoers_passwordless:
  - typhonius

# geerlingguy.firewall
firewall_allowed_tcp_ports:
  - "38387" # SSH
  - "80" # Certbot
firewall_allowed_udp_ports:
  - "53" # Wireguard
  - "55290" # Wireguard

firewall_additional_rules:
  - "iptables -t nat -A PREROUTING -p tcp -i wg0 --dport 443  -d REDACTED -j DNAT --to-destination 127.0.0.1"
  - "iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 51820 -i eth0"
  - "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE"
  - "iptables -A INPUT -p tcp -i wg0 --dport 443 -j ACCEPT"

# geerlingguy.postgres
postgresql_users:
  - name: bitwarden
    password: REDACTED

postgresql_databases:
  - name: bitwarden
    owner: bitwarden

# jenstimmerman.vaultwarden
vaultwarden_version: 1.23.1
vaultwarden_webvault_version: 2.25.0
vaultwarden_config:
  DOMAIN: "https://bitwarden.adammalone.net"
  DOMAIN_PATH: ""  # results in a domain of https://example.com/vaultwarden/, needs to start with a '/'
  DATABASE_URL: "postgresql://bitwarden:REDACTED@/bitwarden?host=/run/postgresql/"
  ROCKET_ADDRESS: 127.0.0.1
  ROCKET_PORT: 8008
  SIGNUPS_ALLOWED: false
  SIGNUPS_VERIFY: true
  SIGNUPS_DOMAINS_WHITELIST: 'adammalone.net'
  INVITATIONS_ALLOWED: 'false'
  SMTP_FROM: 'bitwarden@adammalone.net'
  SMTP_FROM_NAME: 'bitwarden'
  SMTP_HOST: smtp.sendgrid.net
  SMTP_PORT: 587
  SMTP_SSL: true
  SMTP_EXPLICIT_TLS: false
  SMTP_USERNAME: apikey
  SMTP_PASSWORD: REDACTED
  SMTP_AUTH_MECHANISM: "Login"
  WEBSOCKET_ENABLED: true
  WEBSOCKET_ADDRESS: 127.0.0.1
  WEBSOCKET_PORT: 3003
  #ADMIN_TOKEN: "REDACTED"

# adamruzicka.wireguard
wireguard_networks:
  - wg0

wireguard_wg0_interface:
  address: 10.10.0.0/16
  private_key: REDACTED
  listen_port: 51820
  post_up: 'iptables -A FORWARD -i %i -j wireguard; iptables -A FORWARD -o %i -j wireguard; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE'
  post_down: 'iptables -D FORWARD -i %i -j wireguard; iptables -D FORWARD -o %i -j wireguard; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE'
  dns: 1.1.1.1

wireguard_wg0_peers:
  laptop:
    public_key: REDACTED
    allowed_ips: 10.10.10.96/32
  mobile:
    public_key: REDACTED
    allowed_ips: 10.10.10.97/32

# ahuffman.ansible-resolv
resolv_nameservers:
  - "1.1.1.1"
  - "1.0.0.1"
resolv_options:
  - "timeout:2"
  - "rotate"

# geerlingguy.certbot
certbot_create_if_missing: true
certbot_admin_email: certbot@adammalone.net
certbot_certs:
 - domains:
     - servername.adammalone.net
 - domains:
     - bitwarden.adammalone.net

Is it more secure?

As a result of the firewalling, the server is for all intents and purposes as locked down as is possible with a single box. Yes, I could have added in jump servers/bastion hosts and further increased complexity but the following was Good Enough™ for my needs.

The only publicly available TCP port is my SSH port which greatly limits the attack surface. In order for me to get access to any of the passwords within Bitwarden, I need to authenticate via WireGuard which will then give me access to NGINX.

Without authenticating, anyone trying to access the server won't be able to access anything and if they navigate to the Bitwarden URL then the page simply won't load and instead will error out.

I decided to architect the configuration in this way to provide me with a little extra protection in the event of a Bitwarden vulnerability. If a bad actor isn't able to access the Bitwarden instance, then they won't be able to attack it. This is my way of attempting to use defence in depth.

Am I going to keep it?

Honestly, probably not. But maybe.

As a proof of concept super fun, and I've been using it successfully on all my devices for over six months. That being said, I'm probably going to switch over to one of the Bitwarden hosted plans reasonably shortly for two reasons:

• I don't really have a backup strategy for Bitwarden aside from block level server backups and that's scary. Some exist, but I would want to write my own as another fun project (which I can then of course open source). The main issue here is lack of pgSQL support in existing repos
• Having to activate Wireguard every time I want to save a new password is actually a massive pain – even if it's only one click

I noticed that my laptop was still connecting to ad serving domains I'd blackholed in /etc/hosts when I was connected to my WireGuard VPN. Obviously this wasn't great as the point of blackholing them was to ensure my laptop couldn't connect.

Looking at the official WireGuard docs, I couldn't see anything that pointed me in the right direction. The unofficial docs were better, but didn't have much about the DNS line in wg0.conf.

Before I begun, my wg0.conf looked like this, with DNS provided by Cloudflare.

[Interface]
PrivateKey = <SNIP>
PostDown = iptables -D FORWARD -i %i -j wireguard; iptables -D FORWARD -o %i -j wireguard; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
Address = 10.10.0.0/16
PostUp = iptables -A FORWARD -i %i -j wireguard; iptables -A FORWARD -o %i -j wireguard; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 52880
DNS = 1.1.1.1

[Peer] # laptop
PublicKey = <SNIP>
AllowedIPs = 10.10.10.10/32

[Peer] # phone
PublicKey = <SNIP>
AllowedIPs = 10.10.10.11/32

After a few tries with multiple DNS entries and separators, I found that to block domains effectively, I simply needed to add them to the DNS config line, separated by ;. This means that my DNS entry became as follows and those domains were sequestered in the darkness.

DNS = 1.1.1.1; 0.0.0.0, example1.com; 0.0.0.0, example2.com

My first NFT that isn't an overpriced JPEG or playing card from an online game

Remaining up-to-date with technology as it evolves, albeit to a reduced depth concordant with my gradual tech withdrawal, is something I've blogged about previously.

I've had my eye on the Ethereum Name Service (ENS) for a while; especially since I'm an accidental domain collector for side projects that I complete 80% of.

My interest in the ENS rose even further over the last couple of months after seeing a lot more people from crypto Twitter change their name to <username>.eth.

This weekend, with New Year out of the way I decided to register my own domain, and stencil ownership of it immutably into the blockchain.

After doing some cursory research into the steps I'd need to take, I jotted down my next steps so I'd have a rough plan to work to:

1. Set up an IPFS node to host my ETH website
2. Add the ETH website content to my IPFS node so it could be distributed
3. Register the domain
4. Associate the content hash of my website with the domain

Why a domain?

The choice to purchase a domain NFT rather than a JPEG like everyone else was also pretty clear to me. While there's a lot of hype (and a lot of money changing hands) in the profile picture space, I'm treating the majority of picture collections as proofs of concept.

The real benefit of an NFT comes from provable and irrevocable ownership of something and a domain is an example of something I would use rather than just hodl. Whilst I think we're still early in the crypto hype cycle, and NFTs are pumping right now, there's a lot both to come and to stabilise.

Over the next few years, there'll likely be more concrete use cases for what today seems like a fad. I'm personally very interested in zero-knowledge proofs as that will completely change the way authentication is completed – say goodbye passwords!

IPFS

Ansible

The reason I decided to host my own IPFS node was twofold:

1. I didn't want to pay a third party
2. I wanted to learn how to do it so I'd be able to talk about it

It was startlingly easy to set up IPFS on one of my servers by including andrewrothstein's ipfs role and then tweaking a custom role of my own to run the service in the background as a daemon.

- name: Add systemd service for ipfs daemon.
  copy:
    src: ipfs.service
    dest: /etc/systemd/system/ipfs.service
    owner: root
    group: root
    mode: '0644'

- name: Make sure ipfs service is running
  systemd:
    name: ipfs
    state: started
    enabled: yes

[Unit]
Description=IPFS Daemon
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/usr/local/bin/ipfs daemon --enable-namesys-pubsub --enable-gc --init --init-profile=server --routing=dhtclient
User=adam

[Install]
WantedBy=multi-user.target

As an optional addition, I decided to be a good netizen by opening up port 4001 so my node would play a more active role in the network and so in the event that no other nodes pin my content, it can always be found.

Whilst I didn't do this for speed, another good recommendation would be to create a service user called ipfs with a nologin shell.

Content

Creating and pinning the content was also super easy. While I could have created an entire website to be hosted in ipfs, I surmised that the most valuable thing to do would be to create a redirect to this site.

The HTML I wrote was extremely basic, and in hindsight should probably have used a meta refresh tag rather than JavaScript to be more inclusive to noscript users.

<!DOCTYPE html>
<html lang="en" dir="ltr">
    <head>
        <meta charset="utf-8">
        <title>adammalone.eth</title>

        <script>
            window.location.href = "https://www.adammalone.net"
        </script>
    </head>
</html>

Taking this file, I added it to ipfs and pinned so it would persist and prevent it from being garbage collected.

adam@ipfs:~$ ipfs add ~/ipfs/index.html
 added QmRw4UV4UukUydbKXshFD9UwghpWZeFYd4Nsrp4UChSSEh index.html
 243 B / 243 B [===========================] 100.00%
 
adam@ipfs:~$ ipfs pin add /ipfs/QmRw4UV4UukUydbKXshFD9UwghpWZeFYd4Nsrp4UChSSEh
pinned QmRw4UV4UukUydbKXshFD9UwghpWZeFYd4Nsrp4UChSSEh recursively

Testing

In order to test that everything worked as expected, I wanted to use the web UI to check my commands had the desired outcome.

To do this without opening UI ports to the internet, I created an SSH tunnel and forwarded my local ports to the remote ipfs node.

ssh -L 5001:127.0.0.1:5001 ipfs.example.com

The SSH tunnel allows me to connect to port 5001 on my local laptop and have that securely forwarded through the tunnel to port 5001 on my remote server. So when my browser navigates to 127.0.0.1:5001, it's actually from the frame of reference of the remote server.

From there, I was able to open a browser on my local laptop and navigate to http://127.0.0.1:5001/webui to confirm the daemon was working and confirm that my pinned files existed and the content matched.

When using the IPFS explorer, sometimes pinned files aren't shown in the files tab. To show them, manually alter the URL from .../#/files to .../#/pins

DHT

I was curious about how a file on my node could be located and accessed by other people using only a content identified (CID) and it turns out I'd used something similar previously.

Over in my blog titled How I got into technology, I discussed my use of the Direct Connect (DC) protocol. It turns out both DC and IPFS use Distributed Hash Tables (DHT) as the mechanism of publishing to the world who has what content (and how to get there).

Turns out DHT is pretty cool.

Any content you make available on IPFS gets cryptographically hashed and assigned an associated content ID (CID). That means:

• Any difference in the content will produce a different CID and
• The same content added to two different IPFS nodes using the same settings will produce the same CID.

In my case, the cryptographic hash for my file is QmRw4UV4UukUydbKXshFD9UwghpWZeFYd4Nsrp4UChSSEh

As with DC, peers are connected together within the IPFS network. The lookup algorithm connects to the 10 closest peers and asks who their closest peers are to the CID we're looking for. Traversing the list of peers and eventually finding a peer that has the content.

This of course looks super cool when visualised. From my home node, I queried the hash of the file I've stored in my public IPFS node and used Protocol Labs' code to chart the queries.

A few challenges

I found that after running go-ipfs on my node for a couple of weeks, I noticed that my server resources were being expended almost entirely by the daemon. I could have tried was the nice sledgehammer approach, but a little bit more research indicated that setting systemd configuration options may also work. By using --init-profile=server --routing=dhtclient we instruct the IPFS daemon to disable local host discovery and use DHT in client only mode.

I was tempted to change the init profile to lowpower, but the server resource issues cleared up with the above options.

ENS

Registering my domain

Once I'd created the payload, it was easy enough to register on ens.domains and sign the transaction to take ownership of the DNS address I'd requested. The annoying majority of the price however was gas fees, and another reason why Layer 2 Rollups (L2s) are something I'm learning more are a way to reduce adoption blockers.

I opted to purchase my domain for 10 years at a cost of 0.002Ξ per year (plus gas).

Linking domain & website

After ENS had detected my payment for the domain and the token was attached to my wallet, I executed a different function on the smart contract to change the content of the token to point to my CID. This can now be observed on etherscan along with any other metadata I decide to include.

This now means I have of course joined all the other crypto sheep and changed my Twitter name to adammalone.eth.

For the future

As was discussed in my Ghost on Tor blog, this website is now available on the tor network. In addition to tor, it's now (sort of) available on IPFS.

While a user can navigate to adammalone.eth (or adammalone.eth.link if your browser isn't IPFS enabled), the actual IPFS part is merely a redirect to the .net domain.

For me to run the website entirely on IPFS, I'll need to start looking more into IPNS as this will allow me to update the website and content without continually having to update the CID within my ENS token.

I think it's pretty common to think of everyone's life as being a story of many arcs. Just like any good book, TV series, or movie, the plot involves one long and evolving character mega-arc. Within the mega-arc are arcs and sub-arcs.

Everyone has their own unique stories, with different combinations of arcs and sub-arcs throughout their life. Many people would define their school-life, university (if they go), each of their serious relationships, children (if any), home-ownership, retirement etc as individual arcs. Sub-arcs within these arcs would be smaller storylines, perhaps like a year studying abroad, or an individual project working with a specific team.

I like to think of both my life and career as stories, which means it's important for me to be able to craft a good narrative. A mentor previously advised me that the story itself was far more important than the reality and a little embellishment was requisite artistic license.

I've always liked the work raconteur for this reason, because the story and the telling of are the raison d'être for this tenuous quiddity analogy.  

noun, plural rac·on·teurs  [rak-uhn-turz; French ra-kawn-tœr]. A person who is skilled in relating stories and anecdotes interestingly.

I love hearing other people's (abridged) life stories, how they approached their junctures and decided on the paths they took, because ultimately it's a record of how they came to exist in that present moment.

Bastardising Descartes, and far less of an aphorism than the original: ego eram ergo sum or I was therefore I am

Back to my story

The past year has been both a continuation of the pandemic-derived folie à plusieurs. It also marks a year since taking another new path which made me think it was worth a personal, if public, retrospective.

I'd originally written the majority of this blog last year, but ultimately kept it in draft because I wanted to look back rather than forward given I'm more of an expert in my history than divination.

Plus, it's proven I don't care about future me.

With that in mind, I've added a few notes based on my first year at Drift as footnotes for when I finally draw up all my arcs.

1. Staying closer to customers was right

I wasn't sure what the right role would be for me:

• A strong foundation in technology would have allowed for a role in engineering - less hands on but instead enabling
• A background in presales would allow a future in presales
• Delivery is delivery is delivery

Couple the above with partnering and sales that I'd developed in conjunction with previous roles, and there were a few options. Counterintuitively, however, this just led to decision paralysis about the right pathway to proceed down.

Another mentor advised me to stay as close to customers as I possibly could. They are, after all, the reason for being, and why everyone in an organisation has a job.

This proved to be prescient.

I've really enjoyed taking the lead in development of new customer relationships, learning about their organisations, and helping both my customers and the companies they work for become successful.

Staying closer to customer problems, decisions, and solutions is also having a multiplicative effect on my network. I'm meeting more people more often and gaining a lot more insight into how each of them is building successful revenue streams. This in turn, helps me to craft better stories and provide better advice in each subsequent interaction.

2. Being technology adjacent is hard

I've been on a journey to abstract myself from technology pigeon-holing for a while. This was the year that I finally cut the cord that had been growing tenuously thin and took myself out of my niche.

I generally have a rule to never go backwards, and this applies to companies I've worked for, roles I've had, and technologies I've used.

That all being said, it's always difficult to leave the comfort zone. If I've previously done something, there's a non-zero chance I now know how to do it to a reasonable level of capability.

It's definitely been a challenge over the last year to not dive into the technology I'm working with as much. After all, that's not my job anymore.

One concession I'll make though is that while I need to rely on more technically savvy people to support my customers, having a base level understanding of the tech is never a bad thing and imbues the relationship with a lot of trust.

3. Product over implementation

After working in each of the big three factions when it comes to technology implementation, I feel like I have a far better understanding now of the benefits and drawbacks to each.

Working in-house is great if you want to get stuck in to really long term initiatives and see them through from inception until the end. As a result, your subject matter expertise is pretty high.

As an implementor, you can ride along for part of these initiatives and deliver high quality outcomes as part of a project. Typically seeing 1-4 clients in a year and being exposed to different use cases gives a range of experience to a moderate amount of depth.

Vendors support a larger number of customers annually, and hold shallower knowledge across an entire range of topics - crudely diagrammed below.

After having deep technical knowledge previously, I prefer the variety of knowing a little bit about a lot, and in being a master of nothing.

4. I can't wait to travel again

As I've referenced in point 1, working with customers is an absolute blast. Putting on my consultant tricorn and diving into problems (whiteboard optional but recommended) is where I feel like I flow best.

The transition to purely digital interaction for a mostly extroverted personality type has been a challenge. I find that the staccato, Zoom pierced day is mirrored by equivalent frenzied moments of productivity which in itself is more exhausting than a longer, busier day meeting customers in person.

The other thing that I'm lacking are the intangibles outside of scheduled conversations. Corridor conversations, coffees, and casual catch-ups.

I cannot wait until I can both meet the customers I've worked with this year and start to introduce myself to new customers I'll work with over 2022. Despite being a proponent of service digitisation, we do not have a truly comparable solution yet.

In summary, the change has been good, the challenges fun to surmount, and can't wait to see what 2022 will bring.

I decided to spend some of that time learning how to create a hidden service, and make my own blog available over the Tor network. Although this task was mainly as a proof of concept so I could say I've done it, I did have a tiny desire to be lucky and brute force an awesome vanity Tor .onion address.

Creating my address

Remembering that I had some free Google Cloud Platform (GCP) credits, I spun up some servers and cloned mkp224o, the vanity address generator for ed25519 onion services, onto each of them. I opted for CPU optimised instances as this was my limitation using the tool.

Knowing that a 10-character prefix (adammalone) was potentially out of my computational reach, I decided to temporarily calculate an easier hash with a shorter known prefix. This would allow me to move on to the next step in my PoC while the GCP servers continue churning away for as long as I still have free credits.

I ended up calculating a hash with the prefix amalone in an unbelievably lucky 30 seconds.

This blog post provides some further recommended reading for people more interested in how .onion hostnames can be generated.

Installing tor

Continuing the trend I've written about in my previous blog posts, I had to find a way to install and configure everything using Ansible. Ultimately I ended up using haghighi_ahmad.tor with some pretty minor configuration in vars/main.xml

tor_proxy: false
tor_http_port: "80"
tor_nickname: "torphonius"
tor_run_as_daemon: true
tor_user: "debian-tor"
tor_group: "debian-tor"
tor_hidden_service_dir: "/var/lib/tor/hidden_service"
tor_hidden_services: 
  - name: http
    version: 3
    port: 80
    host: "127.0.0.1:88"

This configures tor to listen on port 80 and to forward requests through to port 88 where Nginx is listening for it. Whilst there is an existing Nginx server block using port 80, I wanted to segregate Tor further.

N.B. Tor can listen on port 80 at the same time as Nginx. The reason for this is that Tor isn't binding to an external interface as Nginx does.

The above configuration provides me with an /etc/tor/torrc that looks like the below:

RunAsDaemon 1
SOCKSPort 0

# Hidden services
HiddenServiceDir /var/lib/tor/hidden_service/http
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:88

Configuring Ghost to listen to an onion

One of the limitations of Ghost is its inability to respond to multiple different domains. The domain that each Ghost blog uses to serve pages is hardcoded in config.production.yml and any attempt to access the site with a different URL leads to either redirects or errors.

As Tor uses a different way entirely of representing a hostname, this blog would need to be accessible using two entirely separate combinations of words in the browser's URL bar. I tried initially to use some clever Nginx configuration to point requests coming in on the .onion domain to the clearnet domain by rewriting on the way in and out.

That unfortunately proved fruitless since I assume Ghost uses the URL configured in config.production.yml to create links and routes rather than the Host header associated with incoming requests. This approach is good from a security perspective, but the limit of a single domain makes this sort of implementation challenging.

I eventually settled on creating a shadow install of Ghost for the .onion domain that would mirror the clearnet domain. I achieved this by creating a new directory for the Tor install and symlinking content, current, system, and versions directories to the clearnet install. I copied across config.production.yml and changed only the url and server: port values.

N.B. MySQL details should remain the same as we're reading from the same clearnet database regardless of which install the user accesses.

I could potentially use the .onion hostname as my production URL and then construct another Cloudflare Worker to rewrite links and alter request/response Host headers for anyone coming in on the clearnet domain, but that seemed like too much work.

Fitting it all together

After learning about the fantastic drawing tool Excalidraw, I felt it only appropriate to draw a pretty picture to show how users may reach the server over either HTTPS or Tor.

What can be seen in the diagram below is that users browsing over standard HTTP/S will be converted to HTTPS with Cloudflare before going through Nginx to my Ghost public instance.

Users browsing with Tor pop out inside the server, bypassing the firewall and hit Nginx on port 88. These requests are then routed to the tor instance of Ghost due to the limitation discussed above.

server {
    listen 443 ssl http2;
    server_name www.adammalone.net;
    index index.html index.htm;

    ssl_certificate     /etc/ansible/keys/www.adammalone.net-ec.pem;
    ssl_certificate_key /etc/ansible/keys/www.adammalone.net-ec.key;

    include /etc/nginx/cloudflare-allow.conf;
    deny all;
    location / {
            proxy_pass http://localhost:2112/;
    }
}

As discussed above, both instances of Ghost hit the same MySQL database. The below configuration shows how requests to the administration pages are blocked which I think makes the concept of two ghosts one db more of a safe one.

server {
    listen 127.0.0.1:88;
    root /var/www/html/tor;
    index index.html index.htm;

    location /ghost { deny all; }
    location / {
            proxy_pass http://localhost:2113/;
    }
}

N.B. Security headers set in Nginx have been removed from these snippets for brevity.

Why no SSL certificate?

Finally, you may have noticed that I've not utilised an SSL certificate for users accessing the site over Tor. After a good deal of research, my opinion has coagulated to the view that over Tor, SSL certificates provide positive identity but no additional security.

To summarise this very good Stack Overflow comment:

• As Tor is already an encrypted protocol, an SSL certificate adds no additional security
• Anyone can generate an .onion hostname although it's cryptographically all but impossible for someone to generate your .onion hostname
• An SSL certificate with EV extension can prove the real identity of the owner of the authenticated hosts

Because I'm not looking to positively identify myself as the owner of this blog any further than I already have, I'm happy to not go through the additional effort, time, and cost of using an unnecessary SSL certificate.

Find me

Until I strike cryptographic gold with a nice 10-character prefix, you can find me on Tor here: http://amalone2l6sqxt75shmkrbglepe5uawm4gr5gjk4w7h4l3qsao7iwcqd.onion.

As we had a handful of different websites and applications running on the server, I wanted to simplify everything with the use of an identity platform. This would then be the place that usernames and passwords are stored, thus governing authentication to any existing or new property.

Installing Keycloak itself with a supplied Ansible role didn't quite go to plan, mostly due to some minor differences in Ubuntu 20 and Keycloak 12. Eventually I worked my way around the error messages that Ansible kept throwing and created a pull request so we could share the love back.

Despite the fact that every single blog post and technical article claimed the only way to complete a Keycloak/Nginx integration was to use OpenResty (as it combines Nginx with LuaJIT), I didn't want to because I was extremely happy with the Ansible role I use to manage Nginx and a comparable role wasn't available for OpenResty. Using this role was also the reason I didn't want to have to install Nginx from source.

As a result, I needed to find a way to install Lua and other dependencies for me to be able to use access_by_lua in my Nginx configuation. Doing this by hand in the first isntance revealed that:

• The versions of Lua and LuaRocks in default Ubuntu apt repos were not recent enough
• Lua-resty-string did not have a recent enough version in the LuaRocks repos which led to undefined symbol: EVP_CIPHER_CTX_init errors

The correct combination of each for a successful implementation was therefore:

• Lua 5.4.2
• LuaRocks 3.4.0
• libnginx-mod-http-lua
• lua-cjson
• lua-resty-http
• lua-resty-session
• lua-resty-jwt
• lua-resty-openidc
• lua-resty-string

All of the Lua modules except for lua-resty-string can be installed directly with LuaRocks. Because of the error mentioned above, I installed lua-resty-string from source. Converting this to Ansible and using roles to install Lua and LuaRocks gave me the following example playbook:

- hosts: webservers
  vars_files:
    - vars/main.yml
  roles:
    - { role: andrewrothstein.lua }
    - { role: andrewrothstein.luarocks }
    
- name: install libnginx-mod-http-lua
  package:
    name: libnginx-mod-http-lua
    state: present

- name: luarocks install lua-resty-http
  become: yes
  become_user: root
  command: luarocks install lua-resty-http
  args:
    creates: /usr/local/share/lua/5.1/resty/http.lua

- name: luarocks install lua-resty-session
  become: yes
  become_user: root
  command: luarocks install lua-resty-session
  args:
    creates: /usr/local/share/lua/5.1/resty/session.lua

- name: luarocks install lua-resty-jwt
  become: yes
  become_user: root
  command: luarocks install lua-resty-jwt
  args:
    creates: /usr/local/share/lua/5.1/resty/jwt.lua

- name: luarocks install lua-resty-openidc
  become: yes
  become_user: root
  command: luarocks install lua-resty-openidc
  args:
    creates: /usr/local/share/lua/5.1/resty/openidc.lua

- name: luarocks install lua-cjson
  become: yes
  become_user: root
  command: luarocks install lua-cjson
  args:
    creates: /usr/local/share/lua/5.1/cjson

- name: look for resty-string
  become: yes
  stat:
    path: /usr/local/share/lua/5.1/resty/string.lua
  changed_when: False
  register: restystring
- when: not restystring.stat.exists
  block:
    - name: download tgz...
      become: yes
      become_user: root
      get_url:
        url: https://github.com/openresty/lua-resty-string/archive/v0.12.tar.gz
        dest: /tmp/lua-resty-string-0.12
        checksum: sha256:bfd8c4b6c90aa9dcbe047ac798593a41a3f21edcb71904d50d8ac0e8c77d1132
    - name: unarchiving tgz
      become: yes
      become_user: root
      unarchive:
        remote_src: yes
        src: /tmp/lua-resty-string-0.12
        dest: /usr/local/src
    - copy:
        src: "{{ item }}"
        dest: /usr/local/share/lua/5.1/resty/
        owner: root
        group: root
        mode: '0644'
      with_fileglob:
        - /usr/local/src/lua-resty-string-0.12/lib/resty/*
  always:
    - name: cleaning up...
      become: yes
      become_user: root
      with_items:
        - /tmp/lua-resty-string-0.12
        - /usr/local/src/lua-resty-string-0.12
      file:
        path: '{{ item }}'
        state: absent

The final step from here was to extend the Nginx configuration from my previous blog post to use access_by_lua. The set $session_secret line was crucially important as without that I kept running into the following error:

SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking

The final working Nginx configuration looked like the below (with replacement values for session_secret, client_id and client_secret of course).

server {
    listen 443 ssl http2;
    server_name www.oursite.com;
    index index.html index.htm;
    
    include /etc/nginx/cloudflare-allow.conf;
    deny all;
    ssl_certificate     /etc/letsencrypt/live/oursite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/oursite.com/privkey.pem;
    ssl_verify_client on;
    ssl_client_certificate /etc/ssl/ca/certs/OurRoot_CA.crt;

    set $session_secret gbbPlrI5jJrWTAHuZpQxAg961dwNSUFB;
    access_by_lua '
      local opts = {
        redirect_uri = "https://www.oursite.com/redirect_uri",
        accept_none_alg = true,
        discovery = "https://keycloak.oursite.com/auth/realms/master/.well-known/openid-configuration",
        client_id = "nginx-oursite",
        client_secret = "client-secret-goes-here",
        ssl_verify = "no",
        redirect_uri_scheme = "https",
        logout_path = "/logout",
        redirect_after_logout_uri = "https://keycloak.oursite.com/auth/realms/master/protocol/openid-connect/logout",
        redirect_after_logout_with_id_token_hint = false,
        session_contents = {id_token=true}
      }
      local res, err = require("resty.openidc").authenticate(opts)

      if err then
        ngx.status = 403
        ngx.say(err)
        ngx.exit(ngx.HTTP_FORBIDDEN)
      end
    ';
    location / {
        proxy_pass http://localhost:3434/;
    }

}

Hopefully this helps anyone else wanting to use Ansible to install Nginx and Keycloak!

After using Ansible to set up the server and configure its security and firewalls, I created our Let's Encrypt SSL certificates (as this step is more easily completed outside Ansible). I then decided to go a step further and create client certificates which would prohibit anyone but the holders of those certificates from accessing the NextCloud instance. This meant that even if users had poor passwords or if there was a zero-day on NextCloud, we had a further line of defence to prevent access.

Every single forum post I found online said that we couldn't create client certificates with Let's Encrypt as we don't have the root certificate, meaning no signing ability. The only solution that seemed viable from here was to create our own Certificate Authority (CA) and combine origin SSL termination from Let's Encrypt with certificates generated from our own CA.

I knew the basics, from setting up a CA on my home server, however this time would be a little difference since we were using Certbot to provision our certificates and Cloudflare to manage our DNS/protect our edge.

Taking a huge number of examples from other Ansible code, and a few trips into StackOverflow, I put together an Ansible role that would manage our server CA and create client certificates for us. Our server vars/main.yml was then extended to customise variables from this role to create client certificates:

ca_passphrase: somethingsecrethere
ca_country_name: AU
ca_organization_name: Oursite
ca_organizational_unit_name: ca.oursite.com
ca_state_or_province_name: NSW
ca_email_address: ca@oursite.com
ca_common_name: Oursite Root CA
ca_requests:
  - name: adam
    email_address: adam@oursite.com
    common_name: oursite.com
    subject_alt_name:
      - DNS:www.oursite.com
      - DNS:wiki.oursite.com
      - DNS:cloud.oursite.com
    country_name: AU
    organization_name: Oursite
    organizational_unit_name: Client Certificate
    passphrase: somethingsecrethere
    cipher: aes256
    
ca_privatekey_path: "{{ ca_private_path }}/OurSite_Root_CA.pem"
ca_csr_path: ca/OurSite_Root_CA.csr
ca_certificate_path: "{{ ca_certs_path }}/OurSite_Root_CA.crt"
ca_root_name: "Oursite_Root"

After running Ansible, we had a number of client certificates that I distributed to everyone who used the server. A certificate was created for each user so everyone had their own separate access keys. During the previous step, I also configured Ansible to alter Nginx configuration and make it require client certificates. The resulting Nginx configuration thus included the following lines:

server {
    listen 443 ssl http2;
    server_name oursite.com;
    index index.html index.htm;

    ssl_certificate     /etc/letsencrypt/live/oursite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/oursite.com/privkey.pem;
    ssl_verify_client on;
    ssl_client_certificate /etc/ssl/ca/certs/OurRoot_CA.crt;
    location / {
        proxy_pass http://localhost:3434/;
    }
}

Before anyone says anything, I know it's better to use an intermediate certificate rather than the root, but we wanted something quick to start with.

Unfortunately, regardless of any of the above, we received the following error.

This was definitely an error I'd seen before when I set up another CA for myself and spent hours banging my head against the wall to get the right combination of OpenSSL commands and certificates created. I initially assumed that I'd done something wrong when formulating the Ansible role, however the answer turned out to be more simple than that.

Because of our set up, any internet traffic that reaches our server origin has to pass through Cloudflare which acts as both a CDN and WAF for us. My hypothesis was that something was happening on the wire between their edge and our origin that meant client certificates weren't getting transmitted with the request.

Bypassing Cloudflare by hard-coding our server IP in /etc/hosts confirmed this, so it looked like we'd have to can the whole idea of client certificates and instead restrict our access to when we were on our Wireguard VPN.

A brief look through Cloudflare options however gave me a bit of hope as there was reference to client certificates. I was presented with two options when I clicked 'Create client certificate':

• Generate private key and CSR with Cloudflare
• Use my private key and CSR

Seeing as we'd gone through the effort of creating our own CA, I decided that we'd allow Cloudflare to take our CSRs (helpfully already on the server from our Ansible role), and create and sign some certificates so we could take advantage of restricting based on valid certificate at the edge.

Once I had the signed certificates from Cloudflare, I needed to go back to our server and create some combined PKCS #12 files that could be loaded into each of our browsers in order to authenticate with the Cloudflare edge. The following command uses the signed certificate from Cloudflare and the private key on the server.

openssl pkcs12 -export -out adam.p12 -in adam.cert.pem -inkey adam.key.pem

The benefit of this method is that while Cloudflare is able to authenticate our client certificates, they only hold what is publicly available so our private keys are never leaked to a third party. The benefit of this is that even if someone breaks into my Cloudflare account, they would not be able to make or retrieve valid client certificates.

The next step to this approach is to add a firewall rule that ensures all requests coming in to specific hostnames have a valid certificate. The below rule blocks requests that traverse Cloudflare that are not accompanied by a valid client certificate.

Ah but what about people who are sneaky and use your /etc/hosts method

The final step to this approach is to deny access to Nginx from anyone outside Cloudflare's IP ranges. As is well documented elsewhere on the internet, I took the Cloudflare IP list and configured Ansible to add the following to my Nginx configuration.

server {
    listen 443 ssl http2;
    server_name oursite.com;
    index index.html index.htm;

    include /etc/nginx/cloudflare-allow.conf;
    deny all;
    ssl_certificate     /etc/letsencrypt/live/oursite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/oursite.com/privkey.pem;
    ssl_verify_client on;
    ssl_client_certificate /etc/ssl/ca/certs/OurRoot_CA.crt;
    location / {
        proxy_pass http://localhost:3434/;
    }
}

# https://www.cloudflare.com/ips
# IPv4
allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
allow 141.101.64.0/18;
allow 108.162.192.0/18;
allow 190.93.240.0/20;
allow 188.114.96.0/20;
allow 197.234.240.0/22;
allow 198.41.128.0/17;
allow 162.158.0.0/15;
allow 104.16.0.0/12;
allow 172.64.0.0/13;
allow 131.0.72.0/22;

# IPv6
allow 2400:cb00::/32;
allow 2606:4700::/32;
allow 2803:f800::/32;
allow 2405:b500::/32;
allow 2405:8100::/32;
allow 2a06:98c0::/29;
allow 2c0f:f248::/32;

This then allows us to get the best of all worlds:

• SSL certificates managed with Certbot and Let's Encrypt
• Our own CA to create client certificates without third party involvement
• Protection at the edge with client certificates
• Locking Nginx requests and responses to those coming from the edge so people can't bypass it

I'll have another blog post up in the coming weeks about how I then integrated NextCloud, Wiki.js, as well as a number of other custom services with Keycloak acting as an identity provider (IdP) to reduce the number of usernames and password in use.

Footnotes

1: We're not stupid enough to try to host our own mail.

The simple answer is equal parts passion and procrastination with a sprinkling of subversion and a pinch of counter-culture.

The longer answer is that it all began when I got my first computer.

The background

Growing up while the internet was becoming prevalent was an interesting time. The graph below shows that the '90s and '00s were when internet use took off in a huge way, and my experience was no different. Learning to type on MSN Messenger, picking my online pseudonym, and being taught (incorrectly) how a search engine worked were all things I distinctly remember doing.

Never before or again will a generation go through formative years at the same time as both the world was becoming more connected and information was becoming more available to everyone. While a lot different now, I think the internet was much more like the Wild West as it was burgeoning. Security wasn't really much of a thing, many small sites and blogs existed in place of larger conglomerate presence, and it felt new and exciting to be a part of something that hadn't yet fully gained widespread adoption.

That all being said, I never saw much allure in studying I.T. at school, preferring rather to experiment on my own at home on my laptop. This meant idling in IRC, trying out code snippets or programs I found online without much care for the consequences, and trying to work out how to download music for free. A memory I have from the time is that I couldn't for the life of me get torrent files to download. Not knowing that a torrent client was needed, I downloaded 1kb files and furrowed my brow when they didn't play in VLC or iTunes.

I think my interest in technology was further enhanced by spending infrequent weekends with my Uncle, when he was back from university. We built computers, created LANs to play video games, and constructed elaborate train tracks around his parent's living room (more time was spent using the track eraser to get a fully conductive system than actually driving the trains). I learned how to crack games, what Warez meant, and of course finally learned how torrent files worked.

The set-up

Fast forward to university and I was happily studying chemistry, a passion I'd picked up from school and increased by my own extra-curricular home experiments. In my third year, I studied abroad, and thus began the chain of events that switched my passions from science to technology.

Living on campus in residential halls at university, everyone tussled with access to the internet and to media by the metered connection (100MB a day) hard-wired into all rooms, and the exorbitant price of data on cell-phone plans.

What we did have however was gigabit ethernet between all endpoints on the campus network backed by a connection to AARNET.

Being resourceful university students, someone had set up a Direct Connect server and students could access their share of Linux ISOs locally whilst socialising with other students over the intranet. I eventually found my way onto this server and with that started to become a part of the online university community.

Fast-forward a couple of months and I realised I'd found a friend-group in the most unlikely place. While my parents and teachers had advised me against making friends with people online, I'd instead found a group of kindred spirits – people without lots of deep technical knowledge, but with nous and determination.

I started to hang out (in-person this time) with the motley group who administrated and moderated this hub, eventually being invited to the moderator group myself and donning the stole of responsibility that came with it (mainly being heavy handed with the kick button).

I learned that what I had assumed was a deeply technical set of infrastructure, software, and glue code was actually just YnHub.exe running on an old Windows laptop in someone's dorm cupboard. As nothing was encrypted and all traffic was likely logged extensively, the laptop was moved incongruously between dorms when someone in the university IT department (we'll hear more about these later) blocked an IP.

The Challenge

Eventually, we either ran out of trusted dorm rooms to host the server, or a port was blocked that allowed DC++ to run seamlessly and all was thought lost. Everyone was sent back to their 100MB data caps and with it came a dearth of sharing large files on campus.

With that came the challenge so neatly and succinctly summarised by the following tweet. Out of the window went university work and through that same window came a lot of learning about technology.

We eventually came to the conclusion that the next evolution of DC++ would need to be off campus; in a place outside the reach of university IT, yet accessible to those on campus wanting to connect. One of the moderator team provided us with the root password to one of their friend's CentOS servers, and after extensive googling about how to get in to the server, we managed to open up an SSH connection. Further extensive googling provided us with a test command that we executed before shutting the window lest we broke anything.

Without the comfort zone of a GUI and with limited/no Linux knowledge, we realised that this would be significant challenge for us. Over the next few days, we followed a set of instructions to install OpenDCHub on the server and another set of instructions to open the right port in the firewall. We learned that DNS was the phone book of the internet and registered a new domain so users wouldn't have to remember our IP address and started spreading the word that we were back in business.

We'd correctly, albeit accidentally, surmised that even though DC++ used a centralised architecture, the point-to-point connections were direct. This meant no round trips from client to server for data transfer, and users were still able to benefit from the ultra-fast campus intranet.

Education by procrastination

Rather than be satisfied with the default server settings, we started a quest to be secure, performant, and user-friendly, by spending many late nights learning all there was to know about Linux so we could effectively administrate this server.

We also became aware that there was functionality baked into OpenDCHub to run bots written in Perl. We had two example bots that came with the source code, some documentation, and a smattering of examples from around the web – although nothing that we could use directly. This of course meant that our next challenge was to learn Perl and write our own. You'd better believe we sent the relevant XKCD around when things we working, as well as the other relevant XKCD when things weren't.

Running through three iterations, our Perl took the form of ChaosBot. The bot managed users, alert messages, chat statistics, chat history, and a host of other functions; including the ability to self-update. In doing this work, I learned more about the benefits of open source and how it aligned to my personal views. So much so that I published the code on GitHub to collaborate.

After we'd built our ideal bot – one that made up for all the drawbacks of our decision to use OpenDCHub – we decided to expand to the web. Knowing nothing about HTML, our first iteration was a series of flat files hosting text and poorly written CSS. I had no idea that content management systems (CMS) existed so each page was written copied from an existing page and edited in Vim.

I was informed by a friend that there was an easier way, and started to learn his recommended CMS, Drupal, to build a new site. Over time, we learned Drupal (and by extent PHP), caching strategies with Varnish, database management, and web security.

We created a place where users could blog, access FAQs, and organise social events to take the friendships that we'd all been making online into the offline space. This community grew and grew with an eventual total of over 6000 users.

This evolved over time to be tightly integrated with the chat server in such a way that users could manage their identity and metadata in one place with that information disseminated to all services; mainly through a combination of glue code, bash scripts, and cron jobs.

Due also to the scattering of students (and former students) who had moved into residences off campus but still wanted to stay connected, along with the rise in prevalence of mobile phones, we were pressed to build a solution that would allow anyone, anywhere to chat together.

Thus another bot (WebRelayBot) was born. The quick and hacky way proved to be robust and reliable with the bot spawning a child that watched for chat to be entered online and injecting it both into chat and into the database.

Looking back at the code from that time that I've got backed up, it seems we spent a lot of time understanding the pitfalls of parent and child processes; specifically because we needed to run it in a continuous while loop to listen for new chat messages.

The code snippet below from 2010 shows how we worked out how to spawn a child that would operate independently of the standard processes rather than acting upon the provided (and infrequent) server triggers. For a long time, the bot would become unresponsive very quickly after instantiation and it was only with the use of tools like Valgrind and Data::Dumper that we worked out it was becoming a zombie and needed some special love to not be reaped.

## VERY IMPORTANT: MUST HAVE $SIG{CHLD} SET TO IGNORE
## if it isn't then the bot will keep making forks and trying to keep
## up with the zombie processes. By not reaping the children it ignores 
## them and they don't become zombies.
$SIG{CHLD} = 'IGNORE';
sub main()
{
    &child();
}
sub child() {
    ## We need this or odch thinks the script is dead.
    $pid=fork(); 
    if($pid == 0) {
        ## Consider using a trigger such as Inotify2 instead of while.
        while(1) {
            open(LOGFILE) or die("Could not open log file.");
            ## In case the server dies and there is an accumulation of lines written from the web they'll all get pasted into chat when it lives again.
            foreach $line (<LOGFILE>) {
                chomp($line);
                &log_and_send_data($line);
            }
            close LOGFILE;
            &empty();
            select(undef, undef, undef, 0.01);
        }
    }
    pid_log();
}

Not being content with polling on the website every few seconds for updates, we started to learn this new thing called Node.js which promised near instantaneous updates online.

Whilst none of us knew JavaScript, this really only needed the most moderate of code to be written. So we spent some more evenings testing a lot of different permutations, until finally it worked as we wanted. Using tools like Wireshark, netcat and nmap to make sure our sockets were working and data was being passed back and forth correctly was probably over the top for the goal. The knowledge it bestowed me with however, likely acted as a contributory catalyst for later on when I was doing this for real.

Over the next few months, we drank lots of coffee, stayed up late, scoured the internet for examples, and gained a ton of experience in everything that we needed to build the platform that we dreamed of and that all our user's wanted.

We ended up with a beautiful plate of spaghetti. Our systems and tools were "integrated" together, albeit with files, periodic rsyncs, and some Blu Tack. We had a backup-ish strategy, and an RTO of a couple of days, but more importantly it was something we'd built from scratch, and it worked really, really well.

During our time hacking scripts into code, code into modules, and modules into packages, I genuinely believe I learned more than I did during my actual university course – the one I was meant to be spending my time on.

The last challenge related to usability was to introduce a function to temporarily gag unruly users. While we had functions to kick and ban users, sometimes a better solution was simply to prevent them from speaking for a few minutes. Unfortunately, this wasn't something that we could do with a bot as by the time it received triggers, user messages had already been sent out to all those subscribed to the channel.

This meant we had to learn C in order to alter the functionality of OpenDCHub itself. Taking lots of cues from how the ban function worked, we copied and pasted as needed to create a gaglist and allow authorised users to manage it. Our next step was to recompile the software and deploy it with our patch.

Otherwise harmless users who felt the need to spam were henceforth taken care of by allowing them to view chat, send PMs, and make use of bot commands; however they were temporarily prevented from speaking in main chat and annoying other users.

While everything inside the chat server was working well, university IT made changes that caused connections to our external server to be blocked. We weren't sure if this was on purpose or a consequence of other actions, but it gave us another challenge to get round in order to continue the service.

It didn't look like an IP block, as SSH connections were unhindered and we could still access the website. This led us to believe it was more likely to be either port blocking or packet sniffing. From here, we started learning encryption and SSL tunnelling as research indicated this to be a possible method of preventing our packets being sniffed.

Getting thousands of individual users to learn how to tunnel was likely not going to be a successful endeavour, especially since it took us a long time to learn how to do it ourselves. What we eventually landed on as a workable solution was Stunnel. A program that we could both install on the server and provide as a preconfigured package for users to install so it would work out of the box.

The network diagram above from our internal documentation and shows how we effectively blocked direct access to campus, requiring all residential college IP ranges to use Stunnel. The problem with Stunnel is that it identified all users as coming from localhost (127.0.0.1), since that's where users were proxying through. We wanted the ability to identify external users so required they connect directly through a different port. Learning IPTables made this possible since we could block ports based on where users were coming from.

Our next challenge was learning how to package preconfigured clients for Windows, Mac, and Linux so users wouldn't need to spend time and effort learning to configure a client and Stunnel by themselves. Our hypothesis was that by making everything install and connect with one click, we'd be more accessible to less technical users.

So with that, we set about packaging software and configuration into portable packages that could update with each new release of the underlying software – or if we needed to switch DNS/port due to the continual attempts at keeping the service running in the face of potential shut-down. The installers (and uninstallers) that we wrote married the advertised functionality with our trademark levity. The Mac installer for example starts talking to the user as it progresses through its assigned tasks.

This did eventually save our bacon when our shoestring budget operation forgot to update the free domain name we were using. The DynDNS service required us to log in once a month and click a button to keep the domain assigned to our IP or it would be placed back into their pool. Unfortunately, the specific tld that we used was moved onto the paid plan, so our domain was lost forever. Quickly rolling out new preconfigured software meant users were switched to a new domain with effectively no downtime.

The whole operation cost no money and earned us no money, but what it did provide us with was a phenomenal experience to meet new people, the ability to learn a lot of interesting code/technology, and the satisfaction of running a service that was firmly in the greyest of areas.

As a final hurrah to say goodbye to the university and to claim our victory in the cat and mouse game against the university IT department, the admin team went on an audacious outing to their office where we had our photo taken with out team hoodies on.

The choice

After completing my studies in the UK, I returned to Australia and began to hunt for a place of employment. I had a background and degree in chemistry, but a simultaneous passion for technology that had grown organically (when I was supposed to be studying) through the creation and management of this service with friends.

Prior to returning to Australia, I had submitted about 15-20 applications for graduate jobs within my field. Unfortunately, I received mostly the same boiler-plate responses from each organisation, which led me to believe that the working holiday visa I was on at the time was not sufficient for them to employ me.

I sought out other roles in my area and decided on a whim to apply for a developer role at a place that hadn't really said they were hiring. This entailed me walking into their office, CV and basic GitHub portfolio in hand, with an Oliver-esque request to be employed – something I'd assumed would never work.

The other role that I interviewed for was as a QA chemist at a pharmaceutical company. Make the chemicals over and over again and test them to make sure they're still the same.

It was at this point, with two offers in hand, that I made the decision on which direction my career should go. Do I do the thing that I've been spending the last four years studying for, or do I do the thing that I find fun?

I think it's obvious which path I took.

While everything generally worked really well, I found myself running up against some obscure issue with Travis that meant despite tests completing successfully, the pull request in GitHub would be left with an amber status and a warning about merging untested PRs.

Fast forward to about a month ago, and I thought I'd give it another try as I was running through enhancements to some of the open-source projects I maintain. The suite of tools I built was in response to Acquia's own tooling at the time being unmaintained and using old (and insecure) versions of libraries to power them.

It was also an opportunity for me to practice writing object oriented PHP, Symfony console commands, and test driven development in the real world – especially as my career had moved away from hands-on development a few years ago. Even though I work in less technical roles, I still think it's important to keep my eye in, and as I'll explain in a forthcoming blog about how I got into technology, I tend to learn best when I'm supposed to be working on something else.

For my tools, I decided to abstract the underlying API SDK, rather than package everything into a single library/client tool. I did this so others could consume it and build tools more befitting their needs. I also abstracted log streaming functionality as a one off tool since it solved a very specific purpose. The end-user CLI tool pulls in both as dependencies so we end up with a basic dependency graph as documented below.

Because each of these exists as its own package, I needed three sets of CI/CD scripts so they could be enhanced and tested in parallel. In keeping with providing the best possible experience for users of these tools, I learned how to create packaged phar applications of the CLI tool and the logstream tool.

Phar applications allow all functionality and upstream dependencies that would typically span hundreds or thousands of PHP files to be pulled together in a single binary. They also omit development/test dependencies and do not require technical knowledge to download and use.

My task was therefore to convert three .travis.yml files into whatever GitHub Actions requires to maintain the same functionality.

• Acquia PHP SDK .travis.yml
• Acquia Cli .travis.yml
• Acquia Logstream .travis.yml

Getting started

I figured that I should start off with the simplest package I had, the PHP SDK. In spite of the fact that the underlying functionality and how its tested took (me) a long time to construct, the end result was an SDK that was not only fully tested, but simple to build and use. It doesn't compile into a phar by itself so CI/CD would be a carbon copy of how it's tested locally.

To make things simple, I use composer to lock developer dependencies and composer scripts to manage testing. This means that what I use locally will be exactly the same as what other people download and what will get tested.

A call to composer test runs:

• PHP linting to make sure we don't have syntax errors
• Unit testing with phpunit to ensure that expected inputs and outputs are nominal
• Code sniffs to keep the codebase at a defined quality and standard (PSR-12)
• Static analysis to detect errors in type and usage etc

The .travis.yml manifest pulls in dependencies, runs the above tests, triggers coveralls to check code coverage, and then, for tagged releases of the CLI and log stream tool, uploads the compiled phar over to GitHub to be linked to the release.

I started off with the default php.yml file provided by GitHub and placed it in the .github/workflows directory. From there, I started to customise each of the steps to align to how my .travis.yml files were set up.

This meant changing the composer install line to being composer install --prefer-source --no-progress --no-suggest --no-interaction and creating a build matrix to test installation on both different operating systems and with the two supported versions of PHP: 7.3, and 7.4.

jobs:
  run:
    runs-on: ${{ matrix.operating-system }}
    strategy:
      matrix:
        operating-system: [ubuntu-latest, macos-latest, windows-latest]
        php-versions: ['7.3', '7.4']

I found during the port that there already existed a number of really useful GitHub Actions that I could pull in to run the additional tasks that I needed – predominantly creation of releases and upload of artefacts.

I came to the conclusion during experimentation that I needed to split my manifests into two separate workflows:

• Build/test
• Deploy

The reason for this was that a workflow, as well as the jobs and steps inside it, gets triggered based on the on key at the top of the workflow file.

I wanted to run build/test on every single pull request and push to the master branch so it would be triggered when enhancements are being requested and eventually merged in.  

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

For deployments, I wanted to only create a release and upload a phar of the CLI and log stream tools when I had tagged a release. As this wouldn't occur on a pull request, I've limited it to pushes only. I also restricted the workflow to run when the pattern of the tag committed matched a semantic version. There's a handy cheat sheet on pattern matching within the yaml files that I used to match the tags.

on:
  push:
    tags:
      - '[0-9]+.[0-9]+.[0-9]+'

I initially tried to bundle the branches and tags parameters in the same workflow file, but found that since GitHub was doing an OR match, I ended up creating releases and deploying on every pull request and push. The result of this mistake can be observed in my releases which I've kept for posterity.

By splitting into two workflows, I could also test against the full matrix of OS and PHP version, but deploy quickly and simply with one version.

One enhancement over Travis that I did find was to make the created phar file and HTML-format code coverage report available for each individual pull request. This meant that for each change requested, the application could be downloaded and tested and a full code coverage report could be reviewed to ensure that new classes and methods were tested. This was all made possible with the upload-artefact action, which took a lot of the pain away from uploading files generated to in the workflow to the output.

The final key to integration made use of the create-release and upload-release-artefact actions. The following code block shows how simple it was to both create the release and then upload the artefact to it. As this workflow only runs on Linux/PHP 7.3, I don't have to contend with the build matrix challenges above, only creating the release and uploading the artefact once. The deploy workflow only runs on a tagged commit, so runs much more infrequently compared to the build and test workflow.

    - name: Create Release
      id: create_release
      uses: actions/create-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: ${{ github.ref }}
        release_name: ${{ github.ref }}
        draft: false
        prerelease: false

    - name: Upload Release Asset
      id: upload-release-asset
      uses: actions/upload-release-asset@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        upload_url: ${{ steps.create_release.outputs.upload_url }}
        asset_path: ./acquiacli.phar
        asset_name: acquiacli.phar
        asset_content_type: application/octet-stream

The end result can be seen as a result of creating a new release tag and pushing to GitHub. I currently manually enter all of the changes using a custom git command but perhaps in future I'll find a way to make that automated too.

Challenges

The first challenge I faced was in keeping code coverage functionality. I had previously used Coveralls by creating a clover.xml coverage file with Xdebug. Unfortunately, even though a Coveralls action exists, it expected code coverage in LCOV format. I spent a while tinkering with this, but ended up putting in the too hard box since I couldn't find the right combination of PHP, phpunit, and LCOV to make it all work.

I also clobbered release artefacts for a while because when using the upload-artefact action, any files with the same name overwrite previous uploads of the same name. Since my build matrix tested 8 iterations, I was overwriting 7 times with no certainty about what would be left over afterwards.

Windows support was another issue that plagued me for a while, as I don't have a Windows machine to test on locally. This meant that I'd fire off a change to the manifest and see what was reported back before making another small change and going from there. The main issues for me were that Windows didn't know how to handle /usr/bin/env php in the shebang, PowerShell doesn't use the same commands (or syntax) as Unix, and of course the ubiquitous issue of line endings.

Every single one of my test cases errored out with the following. This is the result of Windows line endings being CRLF instead of LF used on Linux and Mac. As PSR-12 requires LF, errors were raised for each of the test files.

FILE: D:\a\acquia_cli\acquia_cli\src\Cli\AcquiaCli.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
 1 | ERROR | [x] End of line character is invalid; expected "\n" but
   |       |     found "\r\n"
----------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

Additionally, Windows PowerShell doesn't recognise common Unix commands such as find, so my code linting is currently getting ignored on the Windows runners.

Solutions

To allow the continued check of code coverage, I switched over to the pcov library which can be used in place of Xdebug. This was mainly automatic with the following two entries in the workflow file.

    - name: Setup PHP with pecl extension
      uses: shivammathur/setup-php@v2
      with:
        php-version: ${{ matrix.php-versions }}
        tools: pecl
        extensions: pcov
        
    - name: Setup pcov
      run: |
        composer require pcov/clobber
        vendor/bin/pcov clobber

The pcov library has a requirement on the php-pcov extension which can be installed with pecl. As this is a bit arcane for everyday users, I haven't included it in composer.json as a dependency for any of the packages. Instead, I include a step to install the extension and then require pcov/clobber prior to testing.

Without this, phpunit tests will still run as normal, however code coverage won't be reported to the user which I think is a good middle ground between checking code coverage and making the packages simple to extend without altering PHP installs.

I also altered my phpunit.xml to output in a few different formats as shown below. The formats allow code coverage to be reported to inline in the test log after phpunit finishes running, but also as a downloadable html file. I've documented below how to upload the code coverage file for each run as an artefact.

<logging>
    <log type="coverage-text" target="php://stdout" showUncoveredFiles="true"/>
    <log type="coverage-clover" target="tests/logs/clover.xml" showUncoveredFiles="true"/>
    <log type="coverage-html" target="tests/logs/phpunit.html" lowUpperBound="35" highLowerBound="70"/>
</logging>

I realised that I could prevent test runs from overwriting output artefacts by altering the name based on the build matrix to upload multiple versions. Within my test manifest I have specified the name using matrix variables so they get uploaded as different artefacts.

I've done this for both the compiled phar file as well as the code coverage output which results in a downloadable zip containing a simple, easily navigable HTML site to show tested classes and methods and where more attention to unit testing may be required.

    - name: Upload artefact
      uses: actions/upload-artifact@v2
      with:
        name: ${{ runner.os }}-php-${{ matrix.php-versions }}-acquiacli.phar
        path: acquiacli.phar
        if-no-files-found: error

    - name: Upload code coverage
      uses: actions/upload-artifact@v2
      with:
        name: ${{ runner.os }}-php-${{ matrix.php-versions }}-phpunit.html
        path: ./tests/logs/phpunit.html

As for Windows, I put this off for a while after trying a few different solutions but without much success. The first issue I faced was in line endings. Initially, I tried to write a PowerShell command to convert each file to Unix file endings as I read on a forum somewhere that unix2dos.exe was included in Cygwin. I also had to add the & as apparently Windows is finicky about a quotation mark appearing first within the braces.

- name: Convert Windows CRLF to LF.
      if: runner.os == 'Windows'
      run: |
        dir ".\src" -recurse -include *.php | %{ & "C:\Program Files\unix2dos.exe" $_.FullName}
        dir ".\tests" -recurse -include *.php | %{ & "C:\Program Files\unix2dos.exe" $_.FullName}

This didn't work as unix2dos was not installed on GitHub Actions – at least in that location. I did initially research how to add the binary but recognised how doing that would have been tantamount to going down the Rabbit Hole.

Next, I tried a couple of quick perl one-liners to remove the Windows carriage return (\r) from each of the files.

    - name: Convert Windows CRLF to LF.
      if: runner.os == 'Windows'
      run: |
        dir ".\src" -recurse -include *.php | %{ & perl -i -p -e "s/\r//" $_.FullName}
        dir ".\tests" -recurse -include *.php | %{ & perl -i -p -e "s/\r//" $_.FullName}

This attempt didn't error out like the unix2dos attempt did, but I was still receiving the same phpcs errors as before so I decided to look for an alternate solution.

My answer came in the form of a GitHub issue raised against the checkout action itself. I opted to create a .gitattributes file within the repository with a single line to match all cloned files and force them to use LF line endings.

* text=auto eol=lf

This may have downstream implications for Windows users wishing to enhance the code, however I'm expecting that most Windows users will download the compiled artefact where this won't be an issue. If it does arise again, I'll switch over to the alternate method which will only impact line endings on CI.

    steps:
      - name: Set git to use LF
        run: |
          git config --global core.autocrlf false
          git config --global core.eol lf

To solve the Shebang issue that was impacting the build of the phar, I changed the invocation in composer.json to php tools/box compile. When I ran the script directly with ./tools/box compose, the Shebang couldn't find /usr/bin/env on Windows, however by calling php directly, Windows was able to ignore the Shebang.

Conclusion

Overall I'm super happy with the end result and have moved all of the tools over to GitHub Actions to benefit from the tighter integration, the community supported actions, and the ability to easily manage releases and artefacts as part of CI/CD. Hopefully the challenges and solutions I've documented above can aid others who are looking to convert similar packages.

Sympathy: feelings of pity and sorrow for someone else's misfortune.
Empathy: the ability to understand and share the feelings of another.

Pretty damn simple to understand the difference when you read each of the above definitions, but harder to apply in reality. Even if we're taught adages like:

Do unto others as you would have done to yourself.

Why does empathy matter?

Despite what may have been commonplace thought previously, humans are not robots. The traditional model of supplier and client, where one is essentially employed at the leisure of the other (and at their full disposal) doesn't really align with empathetic delivery because it places a hierarchy on the relationship.

In my view, regardless of whether they're personal relationships between friends, or business relationships between organisations, each should be equal and mutually beneficial to both parties. A one-sided relationship in either context leads to unhappiness.

A great, albeit comedic example, of an attempt at creating an uneven business relationship is from one of my favourite TV shows of all time, Peep Show. Jeremy attempts to order a tradesperson to do a job, because he's the boss and the tradesperson is the worker.

While this looks ridiculous, I have had a client use similar language on me and even though I didn't kick any doors down like the tradesperson, it definitely stayed with me as an example of poor empathy^[1].

What does delivery look like without empathy?

I feel like most people who've had a job have come across a lack of empathy in the workplace in some way, shape, or form. You don't have to search for long before finding either a common trope of workplace jerks, or stories from friends who hate their boss/client.

Delivery is a subset of these general instances and potentially complicated further due to the inherent inclusion of paying a third party for defined services. It can be hard sometimes to properly explain the value provided by experts providing services in specific fields.

As a delivery team, especially in consulting, you're often brought in to deliver a project that a business can't do by itself. The organisation reaps the benefit of the years of collective experience the team has in order to produce high quality work quickly, and effectively.

In some cases though, delivery teams are seen as expensive equivalents of existing staff, which is of course a false equivalence.

Without empathy, any project with those preconceived notions becomes a bit like a Dementor, insofar as it sucks the fun out of everything. The thing that linked fun and delivery and got me thinking about this topic was a discussion I had on my Coast Track hike about scaling/measuring fun.

I learned about REI's fun scale and we quickly agreed that we've experienced all types of fun while out in the wilderness, with the most common being I and II^[2]. I got to thinking that the same fun scale can be applied at work too, with type I and II being where you want to be for the majority of the time, but type III creeping in with deadlines, proposals, launches etc. Unfortunately, it can sometimes be the case that type III gets mis-categorised in hindsight.

This sent me down a rabbit-hole researching cognitive biases – specifically those related to perception and hindsight^[3].

The benefit (and detriment) of hindsight is that our negative experiences gradually fade. This is a form of cognitive bias called the Fading Effect Bias (FAB).

The FAB shows that the emotion associated with negative event memories generally fades faster than the emotion associated with positive event memories.

Drawing together the threads of the Fun Scale and the Fading Effect Bias, it's easy to see how type III fun experienced during delivery could be misappropriated to type I or II after the fact.

After a nightmare project with a difficult client, people have the propensity to reduce the negativity they just experienced. The team may celebrate the launch and look back with positivity over the shared experience, but in reality the project was shitty and nobody was actually having any fun.

I've got a few empathy-free stories from projects I've either lead or participated in, however I always use one story as my example of:

1. How not to work in a blended team
2. How not to deliver with empathy
3. A cautionary tale of old school project managers

The client project manager was an angry person. They shouted when they didn't get their way. They demanded that my team be available during public holidays to support their team. They categorically stated that no change requests would be approved. The oddest one was when they demanded I define what a linked list was to prove I knew about technology.

Storming around from project room to project room, they effused an oppressive air to both my team and their own team. I acted as my team's umbrella to diffuse their anger, explain rationally why I would not be letting the team work during their holidays, and walk the client project manager through change requests.

By diverting all of their frustration to me, I'd assumed a burden that my team detected and rallied behind in support; although not without taking on some of that burden themselves.

In the end, we delivered what we'd promised, to deadlines and to a high standard. However the stress along the way could so easily have been mitigated with empathy, understanding, and communication. The client project manager's high blood pressure too, may also have been mitigated.

In essence, a huge fuss was made over nothing, and as a result a whole lot more type III fun was experienced.

How do I deliver with empathy?

By delivering with empathy, professionals can enjoy project work even if it's tough, and look back without the Fading Effect Bias occluding their view.

Regardless of the title, job description, seniority, or company, I have a firm belief that we are all part of Team Human. Everyone is an individual with thoughts, feelings, and emotions, and efficient delivery relies on people getting into a flow state without undue stressors.

That all being said, I'm also not an idealist. I realise that sometimes unforeseen events occur, causing slow-downs, overruns, and days where a team needs to work late to deliver on goals that they have committed to.

It is because of this that I think the mark of a person is more accurately portrayed not when everything is going right, but when everything is going wrong. How a person reacts and manages that situation will ripple out and impact not only their team, but others beyond that too.

I have some general rules for continuous empathetic delivery during projects:

1. Check in

The simplest thing I recommend for team-members, clients, and stakeholders is to check in. As simple as it seems, going over and above the typical "how are you" rally evokes deeper and more meaningful connections that allow people to know each other as individuals rather than just names.

For the vast majority of projects, what is being delivered is less important than major life events, and understanding what's going on in people's lives can have an immediate cooling effect when things don't go to plan. Focusing only on the microcosm of the issue at hand is superseded by taking in the wider contextual situation to help understanding and empathy.

2. Mentor up, down, and sideways

Mentoring is often seen as a senior person providing advice to a junior person. Too often, I see more senior people completely out of touch with junior people, their lived experiences, and their goals.

I believe mentoring should be undertaken up, down, and sideways because being a more effective leader comes not only from learning how to lead from seniors, but also from receiving continuous constructive feedback from the team being managed.

Having the knowledge about what works and what doesn't will allow leaders to tune their leadership style to both get the most out of their team as well as be more understanding of the needs of the team and provide them with the best delivery experience.

3. Group Therapy

Not the traditional group therapy and not one of the podcasts I listen to; rather an informal and semi-regular session outside of standard delivery ceremonies to get together as a team and discuss thoughts and feelings.

Once again I'll rely on an old adage:

A problem shared is a problem halved.

I find it hugely beneficial to spend time as a team running through hopes, fears, and ideas person by person. In my experience, having a safe space to air frustrations, admit imposter syndrome, and receive support and advice from the people you're in the trenches with day-by-day is the most efficient way to prevent teammates stewing in discomfort.

I aim to run a session every month – typically at the end of the day in a casual setting. I'll introduce the session, share my own thoughts and feelings to prevent the awkwardness of going first, and then ask other team members to volunteer their own.

Not only is this a phenomenal method of allowing the group to support itself, but patterns may quickly emerge through open conversation that allow the astute to prevent risks and issues from emerging.

I've also found that this is an effective mitigation strategy to Imposter Syndrome. By communicating challenges to the group, individuals are prevented from living inside their own head and the group is able to help recognise this most persistent feeling of self-doubt.

4. Share personal targets and create group goals

An extension of Group Therapy, I encourage the sharing of personal targets to allow the group to continually work towards and for each other's successes. With the knowledge of what success means to someone else, your own delivery style may be adjusted to be more empathy driven.

A step further than personal targets is group goals. The group should decide on what they want to achieve (aside from completing the project), as a combined goal will allow the entire team to work towards something that they have all become invested in together.

5. Become invested

Being invested as a team, even those blended with clients, is my final recommendation of delivering with empathy. Being invested as a combined team: in each other, in goals, and in wellbeing. The aim of becoming invested is to make everyone put people first, and the challenge second.

As someone who follows technology and tech blogs closely, the concept of the blameless post-mortem is one that's stuck with me since I first learned about it. This is especially true as someone who has caused 1-2 of these post-mortems to be created^[4].

The sinking feeling in your stomach when you screw up/take a platform down/fall behind on a deadline shouldn't be compounded further by anger. Being invested means that individuals come first, and the solution to the problem is worked on not out of fear of further reprisal, but out of the fun of the challenge itself.

Final Thoughts

While these thoughts are very much my own personal brand of delivering with empathy, they don't form an exhaustive list and I enjoy learning other techniques too.

I try to share where I am able with client project managers and stakeholders because the thoughts of the team, percolated, provide far more colour and substance than my thoughts alone.

Footnotes

1: What the client did say was "I am the client, and I am paying you to do as I tell you". Yeah right.
2: My most recent type III experience was when we accidentally walked too far around a ridge above the Colo River and ended up having to descend a mountaineering track under encroaching darkness. Other people have fallen foul of the same track though so it doesn't feel too bad in hindsight.
3: Another good cognitive bias to read up on is the hindsight bias.
4: I may have accidentally caused a couple of major global publications to disappear for an hour due to some incorrect configuration options I set.

I won't belabour the point about active purging as other people online have covered it far more accurately and succinctly than I could. My aim is simply to reduce the amount of origin hits my server receives whilst simultaneously keeping pages in the CDN for as long as possible to heighten the chance of really fast delivery.

One thing I noticed a couple of days after publishing my last article was that the RSS feed (and thus the auto-tweeter) hadn't updated. I knew I'd been pretty aggressive with Cloudflare caches so I turned to Google to find out how Ghost could purge it.

Quickly enough, I came across Paolo's blog authored just a few days prior about connecting Ghost with Cloudflare Workers to purge the cache on site change. I followed the instructions and they worked perfectly, however I wanted to take his work a step further and:

1. Change the logic around authentication
2. Only trigger Workers on page publication or update
3. Only purge the cache for specific pages rather than my whole domain

Changing the authentication

As many times as I tried, I couldn't seem to get the Cloudflare Worker to authenticate with username and password parameters in the URL. With that in mind, I decided that I'd change the way that I was constructing webhooks to use parameters in the path itself. I constructed an arbitrary path that I could use to trigger different cache purges on the same Worker as well as checking the username and password were correct.

const publishPath = `/cf-purge/purge/publish/${WEBHOOK_USER}/${WEBHOOK_PASSWORD}/`;
const updatePath = `/cf-purge/purge/update/${WEBHOOK_USER}/${WEBHOOK_PASSWORD}/`;

While there are some obvious flaws using this technique (not least that the username and password are directly in the URL), we are at least POSTing over HTTPS directly from my server to my Worker. There was also a thread I found about how basic auth parameters were becoming less supported, so I'm currently comfortable with what I changed.

Triggering on publish or update

When I publish a post on this blog, the only pages that really need to be purged are the front page where the list of articles is, and the RSS feed which is what dlvrit.com uses to post articles directly to my Twitter account.

When I update a post, it's highly unlikely that the front page or RSS will actually need changing as it'll more likely be a typo or additional edit to the post. In this case, the only item in the cache that I need to purge is the post itself.

Rather than using a single webhook for any site change, I used two different webhooks that posted to different paths on the same Worker. The top is triggered when I publish a post, the bottom is triggered when I update a post that is already published.

Selectively purging

I try to be as defensive as possible about when I purge; not because I'm hosting mission critical material but more because I try to follow best practices at home where possible – practicing what I preach.

I did some digging into what Ghost sends in the webhook for posts and updates so I could find out what I could switch on in order to send to Cloudflare for purging.

My first instinct was to dump what came to the Worker itself, but that proved to take additional time with both my lack of JavaScript knowledge as well as deploying to the Worker. I could have set up ngrok to do it locally. I could have used wrangler dev. All I wanted to see was the POSTed body though so I found Pipedream which acts as a big endpoint to examine what is being sent to it.

The body content for the Published post updated hook looks similar to the above picture and has pretty much everything you'd want to use on a Worker. The key item for me was the body.post.current.url value as this is what I'd be purging.

With that captured, I could switch on whether the webhook path was publish or update and send different POST data to Cloudflare.

I've created a gist with my tweaks to Paolo's code for people who would like similar functionality with different URLs. The main changes are some code I stole from Cloudflare's documentation to read the POSTed body and the code that changes how I purge based on path.

As a final note, I did try to use the Cache API from the Worker to directly purge the cache object without having to undertake a separate API request. After trying a couple of times, the purge was coming back successful, but I was still seeing cache hits with my test script.

Turns out, other people had run into this as well. Long story short, the Cache API only works within the datacentre the Worker is based in and as my Ghost server is geographically distanced from me, I wasn't seeing the purge from my local POP.

This wouldn't have been a good path for me to pursue anyway as I would want consistent purging and caching regardless of location.

Testing

Testing this was working was the easiest part of this whole process and something that can be accomplished with only a terminal. I picked a handful of paths that wouldn't change as well as a handful of paths that would. I then wrote a quick bash one-liner to curl these URLs and check their status after I created new pages and updated existing ones.

# Testing after publishing a new page
$ for i in / /rss/ /about-me/ /public-keys/ /post/github/ /post/personal-resets/ ; do echo $i; curl -skILXGET https://www.adammalone.net$i | grep cf-cache-status; done
/
cf-cache-status: MISS
/rss/
cf-cache-status: MISS
/about-me/
cf-cache-status: HIT
/public-keys/
cf-cache-status: HIT
/post/github/
cf-cache-status: HIT
/post/personal-resets/
cf-cache-status: HIT

# Testing after updating the Github post
$ for i in / /rss/ /about-me/ /public-keys/ /post/github/ /post/personal-resets/ ; do echo $i; curl -skILXGET https://www.adammalone.net$i | grep cf-cache-status; done
/
cf-cache-status: HIT
/rss/
cf-cache-status: HIT
/about-me/
cf-cache-status: HIT
/public-keys/
cf-cache-status: HIT
/post/github/
cf-cache-status: MISS
/post/personal-resets/
cf-cache-status: HIT

Where can I improve?

While the quality of my JavaScript is definitely something that is left to be desired, there are a handful of things that I'd like to improve at some point.

• Detect if a post has changed its canonical URL and purge the old URL rather than the new one. My assumption would be that this is in body.post.previous but I haven't tested yet.
• There are a few other ways to read the request body that look cleaner than the code I've got in there currently. These would be interesting to explore.
• There has to be a better way to secure this than passing authentication parameters in the URL. While I will explore locking the worker to my server IP, I'd like to look at other mechanisms for security. Creating a tunnel directly from my server to Cloudflare would be ideal (and possible with cloudflared/Argo), but maybe not pragmatic for my efforts and budget.
• Extend the cache clear by also pre-filling the cache so users get both warm caches and new content.

While I can't speak for others, for me personal resets come in a number of different forms although usually over the course of at least a weekend. They take me out of my comfort zone and allow me to process information with a fresh perspective.

Recently, I read How to Change Your Mind by Michael Pollan, and I absolutely loved the following quote:

Mendel Kaelen, a Dutch postdoc in the Imperial lab, proposes a more extended snow metaphor:

"Think of the brain as a hill covered in snow, and thoughts as sleds gliding down that hill. As one sled after another goes down the hill a small number of main trails will appear in the snow. And every time a new sled goes down, it will be drawn into preexisting trails, almost like a magnet. In time it becomes more and more difficult to glide down the hill on any other path or in a different direction."

It is of course, completely obvious in retrospect that this is what occurs in our brains as we succumb to patterns, repetitive processes and the grooves we ourselves carve in the snow covered hill of our minds.

This effect has been inflated further with a pandemic that requires a reduction in travel and extraneous activity, so the need to reset is more important now than previously. Regardless of the amount of five minute breathing exercises or lunchtime walks that are taken, I believe they are of next to no use when the majority of the day/week is broadly the same – hence the need for more aggressive reseting.

How I reset

I like hiking, and I like yoga.

I've reset twice recently and used each method to take myself out of my comfort zone and the normal routines that occupy my day and my headspace.

Whilst I've been unable to attend an actual yoga retreat, I recently spent a weekend at home attending my own stay at home retreat. Three days and five sessions provided me with both the exercise and rest required to come back to the next week more renewed than normally I would.

Each of the active sessions were paired so well with stretching and remediation. The weekend culminated in guided meditation that provided me with an opportunity to step outside myself and observe my strengths and weaknesses. A chance to spend time introspectively examining the parts of myself I liked, and those I wished to discard.

More recently I spent a weekend hiking the Coast Track in Royal National Park. While not the most technically difficult hike, it is one of the most continuously beautiful. With the cliffs, beaches, and rocks of the New South Wales coast to our left over the two day expedition, I was bombarded, continuously, with natural beauty.

The Coast Track also features one of my favourite places to camp – near Garie Beach. Being away from the wider world, most other people, and alone with friends and nature is something I try to juggle a few times a year. Not only does this provide me with a dedicated opportunity for male bonding with close friends, but the physical removal is symbolic of the removal from my comfort zone.

Hiking equipment is probably one of the only things I'll lavish upon myself, so an excuse to use is frequently warranted.

How you reset

This one is up to you. Take yourself out of your comfort zone, and then keep doing it. I like to imagine the comfort zone in the same way I imagine the past.

Nice place to visit, but you wouldn't want to live there.

The Golden Age Fallacy teaches us that now is objectively the best time. The Rational Wiki explains it far better than I could, and I think it's important to treat your comfort zone with the same degree of wariness as focusing too much on days gone by. It's a safe place to visit when you need it, but don't get lulled into the trap of luxuriating in its stagnating comfort.

This blog should act as a PSA to others, but also a reminder to me.

Don't get stuck in your grooves.

The high level

My blog in its old invocation has been around since May 2012, using mostly the same technology and thematic components. Its age however definitely shows when its compared to more modern SaaS based blogging platforms (I'm looking at you Medium).

One thing I was passionate about back in 2012 and still remain passionate about now is open-source software and keeping my eye in technically. It would be out of character for me to:

1. Use proprietary technology to power my personal blog
2. Use a SaaS platform which takes all of the fun out of understanding the tech and learning something new

To keep my blog, and underlying server free of vulnerabilities to this point, I've been semi-regimented about updating Drupal 7 soon after each release. To keep myself free of technical debt in the future however, I needed to update to Drupal 8. Because this was an involved task, I waited long enough for Drupal 9 to be released and I honestly couldn't be bothered.

The other thing that I couldn't get past for years is how much the 'look and feel' of my blog stunk.

This yearning for a more basic platform as well as one that looks great out of the box put me onto Ghost. It's open-source, it doesn't really allow much customisation (so it's easier to update), and looks literally 1000x better than what I made myself.

The details

While I could have used the SaaS version of Ghost and paid for the convenience, my technical eye likes to remain involved so I went down the DIY route. I've documented the process I took below using Ansible to provision it onto one of my servers.

Looking at Ghost's requirements, I already had pretty much everything installed on my server. That said, I've been using Apache instead of NGINX, and I religiously use configuration management so I'm more safe in the event of catastrophe. I recently had a home server die on me and thanks to Ansible was back up and running 2 hours after I had a new USB stick.

My server's main.yml for ghost looks something like this (unrelated components have been removed):

# Apache configuration
apache_listen_port: 80
apache_remove_default_vhost: true
apache_ssl_protocol: "all -SSLv3"
apache_ssl_cipher_suite: "HIGH:!aNULL"
apache_mods_enabled:
  - rewrite.load
  - ssl.load
  - proxy.load
  - proxy_http.load
  
apache_global_vhost_settings: |
  ServerName localhost
  <VirtualHost *:80>
    <Location />
        Deny from all
        Options None
        ErrorDocument 403 Forbidden.
    </Location>
  </VirtualHost>

apache_vhosts:
  - servername: "adammalone.net"
    serveralias: "www.adammalone.net"
    documentroot: "/var/www/html/ghost"
    extra_parameters: |
            ProxyRequests Off
            <proxy>
            # Require all granted
            </proxy>
            AllowEncodedSlashes On
            ProxyPass / http://127.0.0.1:2368/ nocanon
            ProxyPassReverse / http://127.0.0.1:2368/
            
apache_vhosts_ssl:
  - servername: "adammalone.net"
    serveralias: "www.adammalone.net"
    documentroot: "/var/www/html/ghost"
    certificate_file: "/etc/ansible/keys/adammalone.crt"
    certificate_key_file: "/etc/ansible/keys/adammalone.key"
    extra_parameters: |
            RewriteEngine on
            RewriteCond %{HTTP_HOST} ^adammalone.net$
            RewriteRule ^/(.*)$ https://www.adammalone.net/$1 [L,R=301]
            ProxyRequests Off
            <proxy>
            # Require all granted
            </proxy>
            AllowEncodedSlashes On
            ProxyPass / http://127.0.0.1:2368/ nocanon
            ProxyPassReverse / http://127.0.0.1:2368/
            
mysql_packages:
  - mariadb-client
  - mariadb-server
  - python-mysqldb
  
mysql_expire_logs_days: "7"
mysql_root_password: 'foobar'
mysql_bind_address: '127.0.0.1'
mysql_key_buffer_size: "164M"
mysql_max_allowed_packet: "64M"
mysql_table_open_cache: "750"
mysql_innodb_buffer_pool_size: "164M"
mysql_config_include_files:
  - name: 'my.overrides.cnf'
    src: '/etc/ansible/cnf/my.overrides.cnf'

mysql_databases:
  - {name: ghost, encoding: utf8mb4, collation: utf8mb4_general_ci}
mysql_users:
        - {name: ghost, host: localhost, password: 'foobar)', priv: 'ghost.*:ALL', append_privs: 'yes', state: 'present' }

nodejs_version: "12.x"
nodejs_install_npm_user: "typhonius"
nodejs_npm_global_packages:
  - ghost-cli

My server.yml looks similar to the below

- hosts: localhost
  vars_files:
    - vars/main.yml
  roles:
    - { role: geerlingguy.apache }
    - { role: geerlingguy.mysql }
    - { role: geerlingguy.nodejs }

Challenges

One of the stumbling blocks I spent some time fixing were the MySQL configuration in /etc/ansible/cnf/my.overrides.cnf. I kept getting the following error when running ghost install.

Message: alter table `members_stripe_customers` add unique `members_stripe_customers_customer_id_unique`(`customer_id`) - ER_INDEX_COLUMN_TOO_LONG: Index column size too large. The maximum column size is 767 bytes.

Looking around online, I realised that I needed that I'd be able to fix this issue by changing the innodb_default_row_format MySQL variable to dynamic rather than compact. The documentation told me that dynamic did much the same as compact but allows for variable length column lengths i.e. those over 767 bytes long.

I think I could also have changed by default encoding from utf8mb4 to utf8, but doing so would have prevented me from being able to use the extended character set (hello emojis?).

The Ansible role I use to manage MySQL had no parameter that I could easily adjust to change row formats, but it does have the ability to add custom parameters by file inclusion. My custom override is simple and below.

innodb_default_row_format = 'DYNAMIC'

Another challenge I faced was how to configure Apache to both proxy requests to a node server listening on a local port as well as passing through the correct parameters in the right format.

The keys to solving that particular problem were to ensure that I had the right Apache mods loaded (rewrite, ssl, proxy, proxy_http) and that I used the right parameters in my vhost directives. I needed to set AllowEncodedSlashes to on and add nocanon to ProxyPass. Both of these allowed me to pass URLs (and slashes) through from Apache to the Node backend and get the right results from the Ghost API.

The final issue I had was in updating the injected scripts I was planning to use in the header and footer. My access to the API was blocked when I tried to add anything with <script> tags. Understandably my first (and correct) suspect was Cloudflare.

I adjusted my configuration to restrict my admin URL to my home IP and VPN. I also added a firewall rule to remove managed rules on those path so I could adjust the settings and save to the database. As an aside, I did also work out that I could manually alter the codeinjection_head/codeinjection_foot keys in the settings table before restarting ghost to allow the changes to take effect.

With these relatively trivial issues fixed, I ported my content across, added some far nicer images from Unsplash, and set up my site how I wanted.

The future

I've missed writing.

I've long said that creativity manifests itself in a larger number of ways than images, music, words, and pictures. I postulate that creativity also comes from tech architecture, some neat code to solve a problem, or pretty much anything that can automate something away or increase utility.

This blog has been a place for me to creatively speak about my creative endeavours, and I want to continue doing that. I'll try to write about the things I'm playing with and intersperse with my own ideas, opinions and thoughts where appropriate.

Looking at the Cloudflare interface, I can see that while there are white and black lists, none were able to be based on paths. So let's allow Varnish to come to the rescue.

Initially, I tried using the client.ip variable provided by Varnish to check against acls, but upon further investigation when it didn't work (including a deep dive into the Varnish source), I realised that Varnish was using the IP address garnered from the socket connection made to the server. With Cloudflare sitting between the user and Varnish, Varnish was seeing the client.ip as Cloudflare not the user.

From here, I attempted to compare the CF-Connecting-IP header sent by Cloudflare to the acls defined. Varnish didn't like this one bit as all headers are defined as strings whereas the client.ip (and what acls expect) is a special structure dissimilar to a string.

Even further investigation revealed that Varnish 4's included vmod 'std' includes a method which converts strings to this special IP structure. Putting all of these things together, we come up with the following snippet to block access to /user and /admin for users not accessing via the defined IPs.

Finally, and most importantly, remember to define your acls at the very top of your vcl; especially if you're concatenating multiple vcl files.

acl deloitte {
  "1.2.3.4";
  "2.3.4.5";
}
 
acl client {
  "5.6.7.8";
  "6.7.8.9";
}
 
sub vcl_recv {
  # Block access for the administrative part of the site for users not in Deloitte or client.
  if (req.http.CF-Connecting-IP) {
    if ((req.url ~ "^/user" || req.url ~ "^/admin") && !(std.ip(req.http.CF-Connecting-IP, "0.0.0.0") ~ deloitte || std.ip(req.http.CF-Connecting-IP, "0.0.0.0") ~ client)) {
      return (synth(403, "Forbidden"));
    }
  }
}
 
sub vcl_synth {
  if (resp.status == 403) {
    set resp.http.Content-Type = "text/html; charset=utf-8";
    synthetic( {"<!DOCTYPE html>
<html>
  <head>
    <title>"} + resp.status + " " + resp.reason + {"</title>
  </head>
  <body>
    <p>Error "} + resp.status + " " + resp.reason + {"</p>
  </body>
</html>
"} );
    return (deliver);
  }
}

Within the discussion, someone mentioned Toran Proxy which acts as a mirror for Packagist, GitHub and other repositories that store code libraries. Because I live in Australia, the available bandwidth to external repositories is sometimes extremely slow; this lead me to try Toran out.

My home development server uses Fedora 19 (Schrödinger’s Cat) and it's a place I frequently try out scripts, applications and other tooling to both verify it does what it says, and keep a technical eye in as my career drifts ever further away. I was able to translate the download/configuration instructions into a Puppet manifest and have Toran deployed on my server in relatively short time however ran into issues with ensuring BLT (which uses packages.drupal.org) downloaded packages from the right places.

In the end, the solution which worked for me was to patch one line in one file (src/Toran/ProxyBundle/Command/CronCommand.php) of Toran Proxy, whilst ensuring I continually ran Toran's inbuilt cron to generate the right resources for my local build to pull in. Prior to doing this I was running into dependency issues that lead me down seven or eight different garden paths. My definitive guide to getting Toran Proxy set up with BLT is as follows and presumes all initial instructions provided by the Toran Proxy team have been followed:

• Apply the attached patch
• Navigate to the /settings page and use the following image as a rough guide for configuring your instance

• Run Toran cron by executing php bin/cron -v
• Alter your BLT composer.json to use the following (changing the repo URL from toran.adammalone.net to the domain your toran instance runs on and removing the secure-http parameter if your mirror uses HTTPS)

"config": {
  "secure-http": false
},
"repositories": {
  "0": {
    "type": "composer",
    "url": "http://toran.adammalone.net/repo/private/"
  },
  "1": {
    "type": "composer",
    "url": "http://toran.adammalone.net/repo/packagist/"
  },
  "2": {
    "packagist": false
  }
},

• Cross your fingers and run composer install
• If any parts of the build fail, examine your app/toran/config.yml file and ensure that all the Drupal packages (except Coder) are tagged with packages.drupal.org and all non-Drupal packages are tagged with packagist.org.
• Create a new entry in crontab to run the Toran cron as frequently as desired so packages are continually updated.

Your mileage may vary, but I was able to reduce a 40 minute build down to around 8 minutes as my laptop was sourcing libraries from a server 3 metres away rather than the other side of the World. The only slow downs for me were packages tagged with '*' or '-dev' as they bypass Toran and don't get added to my local cache.

As I was using a StartCom free SSL certificate, it was in my best interests to migrate off and find a more reputable CA. I needed to replace my certificate in two locations to ensure I could enable 'Full SSL (Strict)' and protect not only my edge at the CDN but also my Origin.

Looking to see whether Cloudflare had documented Pound as an SSL termination point, I saw a gap that this blog post aims to fill.

1. Obtain private key and origin certificate pair
After completing the steps to generate the private key and origin certificate, download both the private key and origin certificate in .pem format. Concatenate the private key, any CA certificates and the site certificate into a single .pem file.

2. Copy the combined pem file to your origin server
Copy the concatenated file and move it to the directory on your server where you will keep your key and certificate files. Typically this is in /etc/ssl/certs.

3. Locate your pound config file
Pound’s main configuration file is typically named pound.cfg. Possible locations for this file might be /etc/pound.cfg or /usr/local/etc/pound.cfg depending on the operating system in use.

4. The default pound.cfg file can be amended to direct traffic to specified sites
You will need to create a Service definition with, at minimum, Backend and Port parameters. This allows Pound to direct traffic to a backend once it has received traffic. Optionally HeadRequire can be used within multiple Service listeners to separate traffic based on request parameters.

# Global options:
User            "apache"
Group           "apache"
LogLevel       3
 
# Check backend every 20 secs:
Alive          20
 
# poundctl control socket
Control "/var/run/poundctl.socket"
 
# Backend service for any domains matching *.adammalone.net
Service
  HeadRequire "Host:.*adammalone.net.*"
    Backend
      Address 127.0.0.1
      Port 80
    End
End

5. Add a ListenHTTPS block for SSL
Below is a simple example of Pound configured to use SSL. The entire ListenHTTPS block must be appended to the pound.cfg file to allow SSL. Optional parameters for adding headers and specifying ciphers further secure the application behind.

# SSL Termination
ListenHTTPS
  Address 0.0.0.0
  Port    443
  HeadRemove "X-Forwarded-Proto"
  AddHeader "X-Forwarded-Proto: https"
  Cert "/etc/ssl/certs/cloudflare.pem"
  Ciphers "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS"
End

Ensure the Cert parameter matches the location of your combined pem file moved during step 2.

6. Test your Pound configuration before restarting
Best practice is to check your configuration files before restarting Pound as Poundwill not start if there are errors in the configuration. The following command will test your configuration files.

$ pound -c starting... Config file /etc/pound.cfg is OK

7. Restart Pound

$ /etc/init.d/pound start

A while ago, I wrote an article about migrating a site out of a multisite situation into being its own standalone Drupal installation. A site might be separated out of a multisite if its functionality was expanding in scope further than what the platform should reliably be dealing with. Ideally, any shared platform would ensure the majority of functionality included in the codebase was utilised by all sites to minimise the possibility of code bloat.

What is code bloat?

Within the Drupal community, many pieces of code exist to connect Drupal sites with external services and increase the overall level of functionality of the site. Due to the architecture of Drupal, code providing functionality and content/configuration in the database, many sites can use the same codebase to run entirely different sites. It’s often a preferable idea to map functionally similar sites to the same codebase to allow one bug fix or patch update to be applied to multiple running websites simultaneously; lowering the development burden and reducing the maintenance time and spend. This should be contrasted with entirely different sites e.g. intranet vs eCommerce. Typically the functional requirements of the two sites would be completely different, leading to less code share and a reduced effectiveness in a shared codebase. In these instances, I typically recommend using separate codebases to contain the functionality and remove the amount of unused code per site.

How can I make development more efficient?

If two similar Drupal sites exist in different codebases, it can be a preferable option to allow them to run from a shared codebase. The process of migrating an existing site into a multisite arrangement is reasonably trivial provided the following steps are adhered to.

• Create a directory within the sites directory to house the site specific modules, files and database connection information e.g. sites/mysitename
• Copy across everything from within the old site code tree from sites/default to sites/mysitename.
• Ensure that all modules existing on the old site within sites/all/modules are present on the multisite codebase in some way. N.B. if these modules would benefit other sites on the multisite they should be added to sites/all, if they are custom or bespoke to the site being transferred in they should be moved to sites/mysitename
• If on another server, migrate the database from the old site to the database present on the server where the multisite resides
• Connect to the database by typing mysql -uUSERNAME -pPASSWORD -DDATABASENAME or navigate to the new site directory (sites/mysitename) and type drush sqlc.
• Run the following queries substituting in the correct name for your site directory and only changing path for the custom modules that have been placed in the sites/mysitename/modules directory

UPDATE system SET filename = REPLACE(filename, 'sites/all/modules', 'sites/mysitename/modules') WHERE name IN ('custom_module', 'mysite_feature', 'migration_module');
UPDATE registry_file rf JOIN registry r ON rf.filename = r.filename SET rf.filename = REPLACE(rf.filename, 'sites/all/modules', 'sites/mysitename/modules') WHERE r.module IN ('custom_module', 'mysite_feature', 'migration_module');
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules', 'sites/mysitename/modules') WHERE module IN ('custom_module', 'mysite_feature', 'migration_module');

• It's important to run the SQL statements in this order as the second query relies on a JOIN operation that won't work after the third query.
• Clear your cache with drush cc all (At this point you may also need to manually truncate cache and cache_menu and menu_router tables beforehand.)
• Finally change your filesystem path(s) variable in the Drupal settings from sites/default/files to sites/mysitename/files.

By default, drupal_http_request() does not verify the SSL certificate of sites it connects to; unlike command line tools such as curl. To have an extra layer of oversight, this may be undesirable, however because we're working with Drupal, we have the flexibility to alter this.

The following comment in common.inc provides us with a clue about how certificates may be checked.

// Create a stream with context. Allows verification of a SSL certificate.

The use of stream_socket_client() is key here, as it allows the modification of the stream context to pass in the expected certificate. We concatenate the private key, public key and any CA keys (unlikely if self-signed) to form a single pem file to use for verification. Then, we pass the location of this file into the context for drupal_http_request() and only receive information back if the certificates match.

$cert = '/home/website/ssl/example_com.pem';
$context = stream_context_create(array('ssl' => array('local_cert' => $cert, 'verify_peer' => true, 'verify_depth' => 5, 'allow_self_signed' => true)));

$request = drupal_http_request('https://example.com/', array('context' => $context));

Further reading on setting correct SSL contexts may be found on php.net.

To ensure that I'm keeping tabs on the health of the boxes, I run Nagios on my master server and monitor an ever increasing list of services across my collection. Since I've recently added a puppet controlled VPN to my repertoire, it was only natural that I should want to ensure the OpenVPN process was both online and responsive to connections.

Since I run OpenVPN on UDP port 1194, all the resources I managed to find online made reference to piping something towards the port via netcat or nc. Unfortunately, because OpenVPN is not sensible, binary information needs to be sent rather than a few ASCII characters I can read and understand. Similarly, the response is equally indecipherable.

Through testing however, I was able to identify that unless I gave OpenVPN a very specific string of binary, it would timeout on me. With this in mind, I was able to use the check_udp command that comes with Nagios, and a timeout to verify that OpenVPN was up and responding to VPN requests.

I could define the check_openvpn command for Nagios like this:

# We're not looking for a specific response, here. More that we actually get
# one and not a timeout or no data.
nagios_command { 'check_openvpn':
  ensure       => present,
  command_line => '$USER1$/check_udp -H $HOSTADDRESS$ -p $ARG1$ -E -s "$38$01$00$00$00$00$00$00$00" -e "^@^@^@^@^@" -t 10 -M ok'
}

I could then call that check from within my custom VPN puppet configuration like this:

# We're using 1194 for this service and that's the only argument accepted # by the openvpn check.
nagios::service { "check_openvpn_${fqdn}":
  check_command       => "check_openvpn!1194",
  service_description => 'openvpn',
}

When Drupal 7.32 was released and SA-CORE-2014-005 (CVE-2014-3704) was first made public, site operators had as little as 7 hours to upgrade before the hack attempts started.

With such a short window to upgrade, if websites weren't hosted with managed providers who could step in and provide mitigation and support, options to tackle the vulnerability were drastically limited. These delays were attributable to:

• Large numbers of sites to upgrade with resources available and capable of performing patching stretched thin;
• Low internal skill level requiring professional consultation to assist patching and deployment;
• Developers who do not follow the community or security advisories and were therefore unaware of SA-CORE-2014-005 or its severity;
• Slow moving or heavily bureaucratic organisations hampering agile development; or
• Those who just want to watch the world burn.

After the fact, resources were released to assist website owners who were not quick enough to upgrade and were concerned, rightly, that they may have fallen victim to a successful hacking attempt. User guides, flow charts, and code solutions were created with the aim to provide assistance to those in a difficult situation. The underlying message across all of these resources was clear:

If the site was not upgraded within 7 hours, assume it was hacked and rebuild.

Recently I was provided with the opportunity to work on non-Acquia hosted sites which had not been upgraded to Drupal 7.32 until 10 days after the release. I'm hoping that by documenting the steps that I and my colleagues took in response, it will serve as a guide for others in similar positions. Despite the caveat that there is always the possibility that a hack or exploit was undetected, our aim was to verify the state of these sites, purge any hacks/exploits we found and put the sites on new infrastructure.

Battle Plan

Every Drupal site comprises of least code, a database, and files. Each of these requires slightly different tactics when checking for potential exploits. Below, I've documented each of the steps taken against the various site components. Attached is a working document we created drawing on advice provided by the Drupal community, our own internal best practices, and tests at Acquia. As we progressed through the steps, each could be checked off as a way to measure our progress. I'd like to emphasize that keeping an offline forensic copy of a potentially hacked site is important and should be the first step in this process.

Working in conjunction with two other colleagues, we each took one of the code, database and files and rotated through until each had been looked at by three sets of eyes. Following all of these steps, each component was migrated onto new hardware where it happily resides today.

Database

Attempting to audit a database without a recent database backup to roll back to will be painful and exhausting. Without a recent backup to use, our example site needed to have its database checked by hand. The difficulty of this process was reduced by the following lucky facts:

• A database backup was available to compare against (albeit not a recent one);
• The database wasn't massive (~20 users & ~2000 nodes/associated field content);
• Content was not added at high rates making the database relatively slow moving.

While some areas of the database would need to be checked, there were a lot that could be ruled out with just a few command line snippets.

Truncate all transient tables

Any table that stored non-essential data could be purged to ensure nothing persisted past the audit. These included, but were not limited to, cache tables, logging tables, session stores and even search indices. Anything that could be rebuilt and did not contain canonical data was fair game.

In our case, using a database editor such as Sequel Pro made this trival, as it was simply a case of selecting tables and truncating them in the UI. However, if you have no UI, or just want to play on the command line then the following may be used. Additional tables may be added to the TRUNCATE array if necessary:

$ MYSQL_USER='username' \
MYSQL_PW='password' \
MYSQL_DB='db_name' \
TRUNCATE=(`mysql -u$MYSQL_USER -p$MYSQL_PW $MYSQL_DB -s -N -e "SHOW TABLES LIKE 'cache_%';"`) && \
TRUNCATE+=('sessions' 'watchdog' 'search_dataset' 'search_index' 'flood') && \
for table in ${TRUNCATE[*]}; do \
echo "Truncating $table"; `mysql -u$MYSQL_USER -p$MYSQL_PW $MYSQL_DB -s -N -e "TRUNCATE $table";`; \
done

Checksum the remaining tables against any backup

Once the tables had been truncated, each table in the database was checked for changes against the known backup. I scoured the internet for something that shows table diffs although could not locate anything conclusive. Diffing table dumps would have been eye-bleedingly-fun, so instead I opted to turn to the trusty percona-toolkit.

Percona-toolkit is easy enough to install with either brew, yum or another package manager, and it comes with a tool called pt-table-checksum. Whilst it is meant to be used for ensuring consistency across multi-master and master-slave database setups, it can also be used to compare two databases by using the following command:

pt-table-checksum --ask-pass -uroot --databases=my_db_backup,my_db_live --nocheck-plan

This command dumps a bunch of data in the checksums table of the percona database. This data can then be examined to determine whether any tables are different between the backup and the live database. In the example below, the watchdog table is empty, the first workbench_moderation table differs, but all other tables are the same.

Dealing with the remaining tables

It was likely the remaining tables would include the node, field and user tables. Any content change or user log in would, of course, cause the checksums of the tables to differ. At this point, the most thorough way of ensuring database sanitization was to import all tables from the backup not cleared by the above steps and then add in content manually, which was the approach we took.

However, as this can potentially take a lot of time, an acceptable alternative considered was to:

• Manually check recently added rows (new nodes / new users)
• Run queries to determine where unsafe filter formats are being used and examine them (especially important where PHP filter is enabled)
• Grep a database dump against common potential exploit code (base64, $_POST, eval etc)

The decision to start again from backup or attempt to clean an existing table is really one of effort versus risk, so it is one that should be made after careful consideration.

A useful snippet to use for detecting php filter fields in the database is the following. Again, this is not something to rely on 100%, but it provides an excellent method of finding the highest risk areas where exploits may be.

<?php

$formats = array('php_code');
$fields = db_query("SELECT field_name FROM {field_config} WHERE module = 'text'")->fetchCol();

foreach ($fields as $field) {
  $format_field = $field . '_format';  $field_table = 'field_data_' . $field;
  $result = db_query("SELECT entity_type, entity_id FROM {" . ${field_table} . "} WHERE $format_field IN (:formats) GROUP BY entity_id, entity_type", array(':formats' => $formats));
  if ($result->rowCount()) {
    $entity_ids = array();
    foreach ($result as $entity) {
      $output = sprintf('Entity type %s with ID %d contains the field %s with PHP format', $entity->entity_type, $entity->entity_id, $field);       echo $output . PHP_EOL;
    }
  }
}

Code

Because a recent copy of the code wasn't available and the code wasn't versioned, the following steps were followed.

We downloaded a copy of the Drupal core being used by the site at the time of the security risk. This was then be diffed for changes to Drupal core. Any additional patches were matched to the differences in the codebase during this step. It was important to check the potentially insecure codebase against a freshly downloaded copy of the appropriate version of Drupal to minimise the changes requiring investigation.

After that, contributed modules were diffed against the relevant version of the module to ensure no changes had been made. While the Hacked! module provided some ability to easily check modules for additions or deletions, there was no provision for checking if new files had been added.

Custom modules and features were the final, and possibly most difficult, piece of the codebase to check. This was because, in some cases, there may be no record of this code anywhere online, particularly where developers were working directly on production. In cases such as these, each line of each custom module would have to be checked to ensure no nasty surprises lurked within. Luckily for us, the example site had kept backups of their custom code so we were able to diff against those backups and confirm all was well.

The site we were working on was running a Drupal 7.28 codebase so had to be compared to a Drupal 7.28 core. Similarly, each of the modules were outdated, so we needed to ensure we were downloading the correct module version before we ran each check. In cases where a site has a make file to use, then it's simple to create a clone based on that. If the site you want to check does not contain a make file, then all is not lost. You just need a little more hacky drush-fu.

By placing the following in /path/to/codebase/auditdownload.php and running drush scr auditdownload.php will download all enabled modules of the correct version into /tmp:

<?php

mkdir('/tmp/audit/modules', 0777, true);
$x = module_list();
foreach ($x as $y) {
  $p = system_get_info('module', $y);
  $projects[$p['project']] = $p['version'];
}

foreach ($projects as $project => $version) {
  if ($project && $version) {
    echo sprintf('Downloading %s version %s', $project, $version) . PHP_EOL;
    if ($project === 'drupal') {
      system("drush dl --destination=/tmp/audit $project-$version");   
    }
    else {
      system("drush dl --destination=/tmp/audit/modules $project-$version");
    }
  }
}

The diff command can then be used to show any discrepancies:

$ diff -rq /tmp/audit/drupal-7.28/ /path/to/codebase
Files /tmp/audit/drupal-7.28/.htaccess and /path/to/codebase/.htaccess differ

$ diff -rq /tmp/audit/modules/ /path/to/codebase/path/to/modules
Only in /path/to/codebase/path/to/modules: old_ckeditor_version
Only in /path/to/codebase/path/to/modules: allmodules.zip
Only in /path/to/codebase/: files

Files

Where a recent backup of the files directory isn't available, running the following commands will do basic checking to ensure there aren't any PHP files in the directory.

$ find sites/adammalone/files/ -iname "*.php"
$ find sites/adammalone/files/ -type f -exec file {} \; | grep -i PHP

Other extensions and filetypes can be checked by altering the command, ie for Windows executables:

$ find sites/adammalone/files/ -iname "*.exe"
$ find sites/adammalone/files/ -type f -exec file {} \; | grep -i executable

Additionally, the .htaccess for files directories should include the following section to remove the attack surface in future by manually specifying the handler.

<Files *>
  # Override the handler again if we're run later in the evaluation list.   SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

As an additional step, an antivirus can be run over the files directory to ensure nothing exists there that looks suspicious. ClamAV was used in this instance and is simple to install, download the latest virus definitions and run. I found the following options to be favourable:

clamscan -irz --follow-dir-symlinks=2 --follow-file-symlinks=2

At this point, our work was complete and the site was restored.

In summary, running through these checks was a lengthy process that provided me with a far more complete understanding of the available attack surfaces once a Drupal site is compromised. While we were only dealing with small sites, a larger site would have required a lot more effort and produced far more tears.

While no one can predict when vulnerabilities will surface, the fallout (and tears) of these security vulnerabilities can be reduced with solid, regular backups, keeping code in VCS and ensuring servers are hardened. Additionally, in times of security crisis, another obvious alternative to implementing this yourself is to utilise the services of a managed hosting provider, which can provide you support and timely assistance.

I've been using the free Identity Provider (IdP) provided by Feide to remove the pain of setting up my own IdP. The only caveat to this is that I needed to ensure my Service Provider (SP) is accessible from the general web; not possible when running Drupal 8 on my laptop. The quickest way for me to get a Drupal 8 ready platform that would be accessible online was to spin up a quick Acquia Freetier site and work from there. Unfortunately I would then lose the use of PHPStorm and all the benefits a solid IDE brings to Drupal 8 development.

Enter sshfs

# OSX
brew install sshfs

# RHEL
yum install fuse-sshfs

# Debian/Ubuntu
apt-get install sshfs

Create a host in ~/.ssh/config to make life simple

Host myfreetiersite
  Hostname free-xxxx.devcloud.hosting.acquia.com
  User <acquia username>
  Port 22
  IdentityFile ~/.ssh/id_rsa

Create the mount point (I'm using /tmp although anywhere owned by the user is acceptable)

mkdir /tmp/freetier

Mount Acquia freetier with the correct path and flags (Assuming livedev has been enabled)

sshfs -o reconnect,follow_symlinks,compression=yes,volname="Acquia Freetier" myfreetiersite:dev/livedev/docroot/ /tmp/freetier/

Move on with your life when you're done!

umount /tmp/freetier/

After recently adding control of /root/.my.cnf to the manifests managing all my servers, I needed to look into something which could alter that configuration file without blowing away some of the other lines in there which weren't centrally managed - like the MySQL root password.

My /root/.my.cnf is structured as follows and I wanted to alter the port to 3306.

[client]
user=root
password=supersekretpassword
port=3306
socket=/var/run/mysqld/mysqld.sock

Augeas allows us to alter config from this file and rewrite it without clobbering any of the other details. Whilst there's already plenty of information about using Augeas on the documentation site and the puppet type reference page, there wasn't anything that immediately stood out to me when I had difficulty with the /root/.my.cnf file.

One of the key things to realise when dealing with Augeas is that it has preset configuration file types loaded into it. These preset config file styles are known as 'lenses' and each will only work with a set list of files at specific file locations. By default, the lens holding the information for MySQL config files (MySQL.lns) only acknowledges the existence of the following file locations:

• /etc/my.cnf
• /etc/mysql/conf.d/*.cnf
• /etc/mysql/my.cnf

Before we can make the augeas type alter the /root/.my.cnf file we have to register it with the MySQL.lns lens.

Understanding Augeas with augtool

From the command line, we can use augtool to investigate what Augeas is able to see and the files registered to each lens type. Using augtool is a great way to start understanding Augeas, the config tree and the ability to alter config files. To register our aforementioned /root/.my.cnf and alter the port number using augtool we may use the following steps.

# Load augtool without any files.
$ augtool --noload

# Add in the /root/.my.cnf file as a configuration
# file managed by the MySQL.lns lens and ensure
# we don't clobber any of the other include files by
# setting the include index as 1 greater than the last
# existing.
augtool> set /augeas/load/MySQL/incl[last()+1] "/root/.my.cnf"

# Finally load the files.
augtool> load

# Print the port directive from the [client]
# section in the /root/.my.cnf file
augtool> print /files/root/.my.cnf/target[ . = "client"]/port /files/root/.my.cnf/target/port = "3306"

# Set the port to 33306
augtool> set /files/root/.my.cnf/target[ . = "client"]/port 33306

# Save the changes back to /root/.my.cnf
augtool> save
Saved 1 file(s)

Implementing /root/.my.cnf changes with Augeas in Puppet

Once you start to understand how Augeas uses lenses for configuration file types and the way a configuration file becomes a tree, it becomes trivial to alter any config file in puppet with the augeas resource. The following snippet will ensure that, as above, the port directive in the [client] section of the /root/.my.cnf file is set to 33306. Without specifying the correct lens however, this won't work as Augeas doesn't register /root/.my.cnf to a lens by default so ignores it.

augeas {'/root/.my.cnf port change':
  lens => 'MySQL.lns',
  incl => '/root/.my.cnf',
  changes => [
    "set target[ . = 'client']/port 33306"
  ],
}

One of the key differentiators between those of us involved in Drupal development is whether we err more towards the backend or the frontend. There are of course those who excel in both but generally I've found people to specialise more in either module or theme development. Because I suck at theming (I mean have you seen my website?), I consider myself more of a backend specialist. For me, the backend begins with a bare server (and Red Hat based OS installed) and ends when Drupal starts to create markup for a beautiful site. In this exam however, backend doesn't delve further than the application layer.

The examination experience was a little different to the generic exam which I took at home. Instead of being invigilated by someone spying on my through my webcam, I was observed by the Acquia Learning Services team to ensure I didn't crack open a copy of 'Drupal 7 Module Development' when nobody was looking. I'd recommend this method of taking the test over the slightly more intrusive webcam watching. If you get a chance to attend a DrupalCon and you're offered the option of becoming certified there; do so!

Sections

Each of the sections being looked at for applicants is available on the blueprint page for the backend exam. The key areas to look at for the test itself are:

• Drupal core API
• Database abstraction layer
• Debug code and troubleshooting
• Leveraging community
• Performance
• Security
• Theme integration
• Fundamental web development

Each of these sections carries a certain weighting which directly relates to the number of questions that'll be asked about the topics. At 30%, a sound knowledge of the Drupal core API is definitely something you'll need to pass the certification.

Preparation

Based on the sections being examined and the percentages attributed to each section, I'd recommend studying up at least on the areas you identify yourself as weak on before trying. For me, I revised some of the intricacies of the Database API within Drupal. Whilst I often rely on api.drupal.org during development when I get unstuck, this test prohibits access to external resources. Being able to commit a few things to memory quickly just before the test allowed me to accurately answer questions I may not have been able to otherwise.

I also read up on some of the changes that PHP 5.4 and 5.5 brought in over the now EOL 5.3. Namespacing, traits, shorthand array syntax ($array = [];) and general OOP practices came up for me so do ensure you're aware of the new PHP hotness.

Tips

• Since the questions are either multiple choice or multiple response (select one or many), then for those questions you're unsure of there's no penalty in taking a good guess;
• Blast through the questions you're confident of and mark any questions you're unsure of so you can come back at the end with a fresh frame of mind;
• At 90 minutes and 60 questions you should be spending around 90 seconds on each question. If you find yourself staying on a question for over that, mark it and move on; and
• Settle in for the 90 minute stretch when you sit down. If that means getting water, food or taking a bio-break prior then do that.

Why you should take the certification

I don't want to repeat the already well written discussion about the merits of Drupal certification; I will however try to quantify why I took the certification. Being in the Drupal community, around amazing developers and those learning alike, the most I have to go on about how experienced someone is comes either from the number of commits on their Drupal.org profile or from speaking with them or their peers.

This same experience must hold true for people who've just met me and want to know where I stand in the community. Whether it's clients, other community members or even people who listen to me speak at conferences, none have an accurate representation of me as a Drupalist. With a general Drupal certification and now a backend specialist certification there exists a qualitative measure of my knowledge.

What I got

So I passed the test, but what did I get for each section?

I could certainly improve my scores in some of the sections and I should definitely touch up my understanding of how to leverage the community. That being said, my knowledge is improving all the time just by being a part of the Professional Services team and if you want to become a part of this amazing team then get in touch because we're always hiring.

A brief look at this chart from the Drupal 7 development cycle makes the effect of available contrib on core uptake really clear. If we as a community can ensure contrib is ready when Drupal 8 is released, then everyone has a greater incentive to jump in!

One of my favourite ways of learning and rapidly spreading ideas to many is to run a Hackathon. The amazing thing about Hackathons in general is twofold:

• Meeting with like-minded and passionate people who share a genuine desire to further themselves and Drupal;
• The sheer concentrated brainpower in one room, conducive to leaps in development.

What I experienced at the CI&T Hackathon in Campinas, Brazil was another great example of these.

Starting early on Thursday 26th June, the gathered attendees split off into six groups, each headed by a more experienced sensei. The aim of this Hackathon was to both increase the CI&T developers' grasp of Drupal 8 and get some modules ported while we were at it.

For the first hour, both myself and fellow Acquia technical consultant, Hernâni Borges de Freitas, presented an overview of Drupal 8. Not only are there new features to learn about, but also differences from Drupal 7 that are important to know about as module developers. With a collection of homegrown examples and code from the pants module, we were able to cover info.yml files, routing, configuration management, extending classes in Drupal 8 to leverage core, debugging tips and entities.

With this brief injection of Drupal 8, the attendees set about creating teams and deciding on their targeted contrib module to port. Each team was headed up by a senior CI&T developer to act as sensei and guide the learning of the team. Guiding the senseis was the job of Hernani and I. Acting as floating resources, we were on hand to unblock issues and provide both information and inspiration!

After consulting with each team and advising on module choice the teams selected the following to port from Drupal 7 to Drupal 8:

• Security Kit
• Language Icons
• Comment RSS
• 403 to 404
• Flood Control
• Filter Allowed Protocols
• Login Security

The choice of module was carefully considered and each selection adhered to a set of guidelines the Acquia team provided. Our end goals as Hackathon mentors were that all attendees helped port a module and all attendees learned without feeling overwhelmed. We recommended the teams choose modules that all members had used previously; the familiarity would save valuable development time by removing the need to work out how the module worked.

Additionally, while ambitiousness is by no means a bad quality, the teams only had around 12 hours to fully port their chosen modules. With this in mind, we recommended against larger projects and advised more for smaller, yet diverse modules to give each team exposure to as many new Drupal 8 features as possible.

With the modules selected, each team started to discuss module architecture, identifying tasks and key features that would be involved in the port. Prior to the Hackathon, the CI&T team had introduced us to a number of the different development methodologies they use day to day on projects. It was fascinating to watch each team continue to follow these methodologies throughout the sprint.

The main techniques I observed were Agile and Dojo. For those unfamiliar, the Dojo technique limits each team to one computer and 15 minute coding stints. Each team member spends their allotted time at the keyboard with the rest of the team either providing knowledge or absorbing information; this ensures potential distractions are reduced and allows for kinesthetic learning where each team member gets a go rather than be limited to just watching.

At the end of a day and a half of near constant hacking, the teams had managed to port seven modules to Drupal 8. To do so in such limited time is impressive by anyone’s standards and puts a good dent in the number of projects that needed the upgrade. After convening to discuss efforts we were proud to announce team’s Seckit and Login Security as joint winners. Not only had they teamed up on important contributed modules, but they’d done it in an inclusive manner where everyone learned. Overall though, we were really proud of the effort everyone attending put in.

As a Drupal 8 advocate, it’s my aim to spread the love of Drupal 8 to as many in the community as I can wherever in the world they are! Inline with this, it’s my hope that by empowering the CI&T Brazil team with Drupal 8 knowledge, they’ll be able to take on the roles of mentors themselves and spread that knowledge further.

In addition to the noise I make about the importance of getting an early edge on the latest and greatest Drupal, the D8CX initiative headed up by Lee Rowlands (larowlan) is something to follow. A cousin of the D7CX initiative, D8CX aims to provide promotion and assistance to port contributed modules.

However, what happens to all that caching goodness when you want to run your entire site over SSL? Out of the box, Varnish doesn't support it. While I've heard some mention that not supporting SSL is an oversight, there exists some very sound reasoning for why not.

So how do people terminate SSL?

• Nginx - How Acquia, my employer does it
• Stunnel - Software I'm fond of
• Pound - My preferred method
• Apache - mod_ssl

What is Pound?

Without copying exactly what's on the Pound documentation, or the Wikipedia entry about Pound, it's essentially a reverse proxy, SSL terminator and load balancer but NOT a webserver. It's small, easy enough to install and has minimal configuration. Stunnel is similarly simple, but since I have quite extensive experience using Stunnel, I decided to learn something new.

On my load balancing servers, Pound listens on port 443 and Varnish listens on port 80. When traffic comes in on port 443, it hits Pound, gets decrypted using my server certificate and then gets passed to Varnish on port 80. By putting all traffic through Varnish, I'm able to take advantage of its caching ability for both HTTP and HTTPS traffic.

It's almost, that simple. I had to make some minor changes to my VCL to receive and cache mixed mode traffic. Prior to these changes, I would sometimes deliver resources using the HTTP schema to pages delivered over HTTPS. This had the understandable effect of causing my browser to complain about insecure resources.

Getting Varnish and Pound to play nicely

Realising that we need to handle HTTP/HTTPS traffic differently in Varnish, even though it all comes in on port 80, I decided to use a separate cache hash key for each. Varnish uses hashes of the URI as a key to store and look up data by. My VCL implements the vcl_hash subroutine to detect HTTPS traffic and alter the hash key. We add a header in Pound to tell Varnish that the traffic came in over SSL and then watch the magic happen.

pound.cfg

ListenHTTPS
  Address 0.0.0.0
  Port 443
  HeadRemove "X-Forwarded-Proto"
  AddHeader "X-Forwarded-Proto: https"
  Cert "/etc/ssl/certs/adammalone.net.pem"
End

Service
  HeadRequire "Host:.*adammalone.net.*"
    Backend Address 127.0.0.1
    Port 80
  End
End

default.vcl

sub vcl_hash {
  hash_data(req.url);
  if (req.http.host) {
    hash_data(req.http.host);
  } else {
    hash_data(server.ip);
  }
  # Use special internal SSL hash for https content
  # X-Forwarded-Proto is set to https by Pound
  if (req.http.X-Forwarded-Proto ~ "https") {
    hash_data(req.http.X-Forwarded-Proto);
  }
  return (hash);
}

The hash_data function allows us to add further information to the hash. By adding 'https' to the host and uri information, we're altering the hash in such a way that it is different from just the host + uri that an http request would use.

I've also attached a downloadable copy of my full Pound config and the puppet manifest that generates it for people who are interested in replicating this functionality. I'm using my Pound puppet class located at typhonius/puppet-pound, a fork of mrintegrity/puppet-pound.

Drupal configuration

The final thing to do is to inform Drupal it needs to be in SSL mixed mode and to enter a small snippet in my settings.php so it can be turned on or off based on the incoming request. If Varnish is running on the same server as your Drupal installation, you'll need to replace www.xxx.yyy.zzz with 127.0.0.1. Otherwise it'll be the IP of your load balancing server.

// Varnish Settings
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array('www.xxx.yyy.zzz'); $conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR'; $conf['page_cache_invoke_hooks'] = FALSE;
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
  $_SERVER['HTTPS'] = 'on';
}

This is how I allow SSL through Varnish, if you do it differently, add a comment!

About the conference

Right now, the most up to date conference details are available on the DrupalGov conference pages of the DrupalACT website. The show begins from 9am on the 22nd August at the National Museum of Australia with sessions running throughout the day and a strong likelihood of further events in the evening.

We'll be running three session tracks with the hope of appealing to all registrants at the event.

For those into hardcore coding, theming and DevOps, we'll have a track available to discuss the latest Drupal techniques, continuous integration with Drupal and third party technology interaction.

If you run a department or a development team in Government, then I'm hoping the Gov track will provide insights into keeping an agile workflow, managing a multitude of shareholders, starting to use open source or advice on advocating for the cloud from a decision maker standpoint.

Alternatively, for those wishing to improve the architecture of their existing sites, future planned builds or just looking to pick up on the techniques of other site builders and architects we're running the Case Study track. Covering entire builds, content workflow and site management, there should be enough information provided for all seeking it.

With these tracks and the ability to pick and choose the sessions attended throughout the day, it's my strong hope that we're going to cover a huge amount of content applicable to Drupal in Government.

Why the conference?

Even with DrupalGov Canberra 2014 as a sequel to the successful DrupalGov Canberra 2013, it's likely that an event would be necessary anyway. Only late last week did I hear news of John Sheridan's trailblazing blog post on the departmental blog. This sparked off further comments on both The Delimiter and Computer World that provide additional commentary and analysis of the decision.

Long story short, Drupal and cloud are considered with high regard as an open source solution to Governmental needs for a CMS.

This is exciting for me for three main reasons:

• I'm a Drupal advocate/developer with a passion for open source
• I work for a managed cloud hosting company
• I currently live in Canberra

These three reasons combined mean that although I am not directly affected by a decision to migrate sites to a GovCMS​, many around me will be. Ensuring we have both a local Drupal user group and a best in class event to champion the use of Drupal within Government will provide those transitioning with more support as they get up and running.

Quite often around new technologies there exists a certain degree of fear; there's fear of change, the unknown and of obsolescence. While Drupal has been around for well over 10 years, it's still relatively new within Government circles, traditionally the bastion of proprietary and closed source. The community driving the development, use, training and support of Drupal is vibrant and active. Looking at an aggregate calendar shows 80 unique events spread over 6 continents globally with Drupal as the topic of discussion, this includes one such event in Canberra. The community exists, in part, to reduce the barrier to entry and inform in order to reduce fear.

One of the mottos with Drupal is:

Come for the code, stay for the community.

This is something I've found true, at least for me. The code was great, drew me in and allowed me to write code of my own. But the real thing that prompted me to stay, pushed me to develop more and allowed my passion for Drupal and open source to thrive was the community and the sheer force of effort that I observe others put into it.

So in summary. I want DrupalGov Canberra 2014 to inform those unfamiliar with Drupal, demonstrate the community driving Drupal and provide that same push I felt when I started to Government and private sector alike.

Moving In

In around November 2012 I started looking for a new place to rent so naturally turned to the relevant sources to find an appropriate place to live. On the face of it, all the property management companies look the same. Young, smartly dressed, bright eyed individuals filling our heads with imagery of wondrous homes that would be a joy to live in. With each viewing and each separate company the property managers followed the same format:

• Any problems would be fixed prior to moving in (chips/cracks/stains);
• There are numerous other people in queue so I had better move fast;
• The agent has had nothing but good reports from everyone else in the area.

Combine that with the feelings of inadequacy bestowed upon us by the property manager whilst talking to us and you have yourself the recipe for a property manager! In my head I'd tell myself that they were no different to I but for some reason most of PRD's property managers of the time appeared to think themselves on a higher echelon than the average human being.

Whilst moving in, my housemates and I learned a little more about the history of the property, including but not limited to:

• Previous tenants (Canberra Raiders) trashing the place;
• Other tenants skipping rent and fleeing the ACT;
• This was meant to be an investment property followed by a retirement home for the landlord;
• The landlord wanted no groups - something I was able to get past with a little talking

Since we were conscientious tenants all the paperwork was filled in and supplied to the property management company; PRD.

Living There

For the most part, I had an enjoyable tenancy although a few things struck me as odd about the way PRD operated for us. It was my understanding that a property manager was the point of contact between the tenant and the agent. Alas, we experienced five different managers over the tenancy. Couple this with a lack of communication between them and that's five times things have to be re-explained. A number of repairs and general tasks promised upon entering the tenancy were not completed after the year mark and repairs completed were done by the landlord after direct communication with us.

A key to the mailbox was not provided for a number of weeks and with that the only remedy was a phone call to the PRD Canberra CEO's mobile.

Moving Out

The move out procedure was fairly organised from our end. The place was cleaned, carpets steamed and inspected. PRD on the other hand, didn't provide us with much help or information without heavy prompting and I'm not they ever knew the exact dates of departure.

ACAT

​After being verbally informed we would receive 100% of the bond back after our final inspection, we considered that the end of an unpleasant chapter in renting history. However, as I came to realise, it's really important to get written confirmation as we were then sent an invoice for $2590 (coincidentally $10 short of the full bond amount). This was not acceptable for my co-tenants and I which caused us to take the matter to the ACT Civil and Administrative Tribunal in order to resolve the matter. I would strongly advise all tenants in similar positions to consider this a highly viable option. It turns out that rental law in this country, and the ACT is extremely favourable towards tenants, provided there is reasonable evidence to back up claims.

After providing a number of emails and documents curated during the course of the lease, the majority of the issues were turned over to PRD to deal with. Whilst I refuse to be walked over by unfair and underhand practices and I feel my co-tenants were of a similar temperament, it worried us that others could be taken advantage of in a similar manner. In short, if you're a tenant and it looks like you're stumbling into a similar situation as that I've described, it's free to seek legal advice.

If you're an incredibly proactive person who doesn't mind repeated follow-up phone calls to check things are being done then you'll do fine. If unreplied emails are your thing, then rent with PRD. If you like long walks to Kingston in order to speak with them in person then you've got the right company. If. on the other hand, you like efficiency and not being taken for a ride; PRD is not the right company for you.

Similarly, prospective landlords tempted by PRD as a management company should also think twice before signing up. My understanding of the matter is that PRD is as lacklustre an agent for landlords as it is for tenants.

So, in conclusion, PRD suck and I'll never use their services again. I look forward to either comments refuting my claims or a concerted effort from the company to not suck in future.

In early February, and with the clock ticking on an impending launch, one such customer got in touch with a bug that had stumped everyone on their team. One of the first steps we take when trying to get to the bottom of a bug for a customer is to attempt to replicate the issue. This allows us to start narrowing down and focusing in on the cause in order to head towards the process of finding a fix.

The problem with this particular issue was that replication was both unreliable and fluxional. On occasions, pages would timeout, return partial content and tokens would not be converted correctly. The best clues we had to go on was that these incidents occurred on cache clears and cron runs… sometimes. Attempts to replicate the illusive issues in the customer’s development and staging environments failed with no errors observed. Additionally, replication of the problems was similarly temperamental on a local clone, no matter how many clones were attempted. The overarching symptom, however, appeared to be related to tokens; with the page title remaining the unparsed '[site:name] | [node:title]'.

In addition to the problems above, we were hindered by two additional ancillary issues that got in the way of debugging:

• Pending database updates, each of which could have both caused or exacerbated the problems
• Huge numbers of notices in the log and appearing on execution of actions with drush. This made it hard to determine an obvious error (remember this for later).

Digging deeper

At this point in the debugging cycle, it was desired to create an environment that matched 1:1 with the production environment. Where production utilised dedicated load balancers, many webservers and highly available database servers; the staging and development environments did not. A replica environment was created in order to match exactly and provide the best route towards a successful replication. With more resources pulled in to assist in the debugging effort, and the urgency increasing due to the countdown to launch we were able to echo what was occurring on production to about the same level of reliability; on cache clears and cron runs… sometimes.

The combination of an exact replica environment, with more eyes on the problem, told us that with both cache flush operations and cron runs, certain caches were purged. The idea then, was that incorrect values were getting stored in the cache, after only a partially complete cache set. It was then decided to completely disable the cache on the replica environment. This would remove a variable we couldn't control, as well as follow our instincts to determine why cache wasn’t being set correctly. This was achieved with the following placed in the site's settings.php as directed in caching documentation.

$conf['cache_backends'][] = './includes/cache-install.inc'; $conf['cache_default_class'] = 'DrupalFakeCache';

This key step allowed us to reliably replicate all issues on every page load, a gold-mine in debugging terms, which brought us a lot closer to being able to get to the bottom of the issue. The decision was made to run through an entire bootstrap with XDebug to analyze the page load and variables.. This allowed us to observe all variables at every stage of the Drupal bootstrap; a task which paid off with no exceptions here. Next, we started looking from tokens module to core and the operations that happened early on in the bootstrap. Any time I'm debugging in module.inc or Entity API, I keep getting that nagging feeling that I've gone way too deep, then dive in to go deeper. Very much inception tactics of debugging.

Some of the variable enumeration that XDebug aided with showed me that when modules were initially loaded, only half got loaded successfully. One of the unloaded victims was system.module which contains token hooks. These hooks were not being placed in the cache so [page:title] wasn't getting replaced!

The Cause

When Drupal first loads all its modules in _drupal_bootstrap_variables() via module_load_all(), it runs through the list of modules and includes them for later execution. Drupal takes the functions and hooks from each module and stores them in the cache so hooks may be implemented at will later on without having to scan all the files again.

What if there’s some kind of error in the include of a module, when Drupal is running on a freshly cleared cache_bootstrap? Rather than completing the bootstrap, Drupal will divert to its error functions and stop execution of the initial bootstrap. Since Drupal can only get part-way into its bootstrap, it can only cache some of the hooks. This caused a number of modules to not be loaded correctly and as such, their hooks weren’t available later on in the Drupal page load when they were required. Remember how tokens weren’t being replaced in the page title, that was due to some implementations of hook_token_info not being discovered and cached.

On subsequent page loads, since there are already cached items (albeit incomplete items), Drupal will adhere to what it has in its cache. The problem that caused all of this was a simple error in a custom module although it was made far worse by the large number of notices flooding the logs. These hid the one notice that was causing this chain of errors. A single line including a file that didn’t exist with no additional error handling was the root cause of all the problems and commenting out the line fixed absolutely everything.

What we can learn from this?

This just goes to show how a small error can be made far more problematic when the actual issue isn't easily observed due to huge numbers of other errors. An apt saying at this point is that we couldn't see the wood from the trees in terms of notices to know which was pertinent. Another issue was that the file include was not wrapped in any sort of check to determine if the file existed. Nor was it preceded by an '@' which would have suppressed the errors in a similar manner. Additionally, the red herring of ~30 database updates that could not be completed served as a distraction to the ultimate goal of finding this issue. A clean codebase with up-to-date modules and themes spawning no errors would have had this resolved in a fraction of the time.

Defensive coding, here, would have helped but I'm just glad I got to work on another crazy Drupal issue!

I was lucky enough to be selected to present a session at the conference after submitting a topic that echoes what I deal with frequently. A lot of our customers launch new sites on our platform at Acquia, be that a simple DNS cutover from another provider or a whole newly developed site. Usually, we’ve assisted in preparing the site for launch well before the date of no return and the launch is successful and quiet. However, once in a blue moon, if launch is pulled forward dramatically, a timeline isn’t followed, code changes are pushed at the last minute, or just an unforeseen scenario occurs, we get called in.

One of the hats I juggle as part of the customer solutions team is the task of necromancy; bringing websites and servers back from beyond the grave. When sites tank, myself and colleagues from almost ten different time zones are available to jump in and get them rolling again. With site launches being a highly watched, increased pressure period in the lifetime of the site, it needs to be done right first time or it could spell the end of a project entirely.

The session I presented offered a basic rundown of sensible site launch tasks and timelines. It also acted as a showcase for some of the more interesting launches I've seen with examples of launch almost-failures and steps for mitigation. While the slides themselves may not be very revealing of the talk, I certainly plan to build on this and use it for future Drupal gatherings. Site launches are the sharp end of developing a site and everyone across the team has a role to play in making it a success. While web technologies and offerings come and go, I'd imagine a launches are fairly consistent.

Clearly, the obvious disclaimer of speaking as an individual, not on behalf of the company, applies here although it's probably a good idea for me to make that explicit.

The how

During DrupalCon Sydney, I met a bunch of Acquians. A sea of blue in the Drupal drop shirts easily distinguishable when observing the crowd. In turn, I was approached and asked if I'd like to check how good the website I was working on was, using instant insights. Apprehensively, I offered the address of the Federal AMA, the website we'd just finished migrating from Drupal 6, and waited with bated breath.

Luckily, the result came back as an A+ and suddenly my efforts of the previous months were not in vain. Additionally, the privilege of an A+ means a free T-shirt and who turns down free shirts!

A little while after the conference, contact was made and the rest is; not history, more, the recent past.

On joining

Joining the 'club' was a little daunting if truth be told, although absolutely not required. I was flown to HQ in Boston, onboarded with the company and made to feel very welcome by my new colleagues. I might have overdressed a little for my first day​; opting for the dress pants and shirt combo that adorned me at my previous place of employ. If anyone asks though, I'll maintain it was so I could style on everyone.

The whirlwind tour of the office was solidified by being introduced to all the members of my team, sitting with them while they worked, taking part in team meetings and generally starting to feel out my place and where I belonged.

On working

The role I'm in provides me with the opportunity to get hands on with hundreds of different codebases and attempt to find solutions to some of the most interesting Drupal problems/implementations. As well as this, I'm able to present myself in an advisory capacity on dedicated channels where specific expertise is required for either planning, implementing or troubleshooting a business/code arrangement.

The job really flies when emergency situations land. Perhaps a site has just launched and it tanks due to higher than expected load, maybe a coding snafu has brought a site to its knees, or it could just be malicious attacks. Any of these situations, in a myriad of contributing factors can occur, and it's a part of my job to fend off attackers, hotfix pain code and ensure Drupal is performing as well as it can. Some issues will literally have a number of team members collaborating for hours, sometimes days, to keep the sites up and we do it well, which is always a plus!

As well as deepening my knowledge of the ever moving drop, a lot of Acquia is about the infrastructure. Extending my comprehension of Varnish, memcache, server sizing, iptables, puppet, FPM, CGI and much more is a direct result of being around all of them every day.

If this is something you think you could see yourself doing, we're always hiring so do get in contact with me.

On the future

Since Acquia is indelibly tied to Drupal, the growth of Drupal within the Asia Pacific region directly affects me. I've made some of my own assumptions about the future of Drupal within the APAC. They may turn out to be entirely wrong, but it's good to have something on 'paper' that I can refer to in the future if they eventuate.

Australia

Compared to the US and Europe, Australia has a maturing Drupal ecosystem. The government has started using Drupal and open source has the backing from the right people. We have a bunch of really top rated Drupal shops evangelising the usefulness of Drupal to clients and a number of well populated Drupal user groups in the major cities.

Whilst Australia hasn't broken out completely in the same way that Europe and the US are continuing to do, it's on the edge which makes it exciting to be here with Drupal doing so well.

Singapore

With a number of companies and organisations on the island city converting to Drupal and a DrupalCamp this year, it's my opinion that Singapore will be one of the next key areas of Drupal usage after Australia. A relatively small country, with a number of the world's largest businesses holding major offices in a confined space, there is a density of technology that breeds itself to the rapid sharing of ideas and solutions. I enjoy working with Singaporean clients, all of whom are eager to lap up all the Drupal knowledge I can provide so this bodes well for the future of Drupal there!

China

Whilst traditionally China has typically been slow to react to recent developments in tech; all that's changing. Again, like Singapore, the DrupalCamp and user group scene has made me believe we'll be seeing some cool things out of the middle nation. A close friend of mine, and Drupalist, who himself hails from China receives frequent offers for work in start-ups in both Shanghai and Beijing. A sign that, like Australia, the jobs are there, but people with the expertise required are in short supply.

Japan

Similar to the above countries, Japan is developing a great Drupal culture, with a number of good services and well known names from the community working from there. The beginnings of a healthy community backed by user groups and events will bring Drupal to the fore, allowing more to become aware of the software, empowering companies to take the plunge into open source confident that there is support both in the community and the wider world ready to assist.

Anticipation

Overall, I'm very excited to be in the APAC sector of the world within this industry at this time. Like Adam Smith standing on the precipice of the industrial revolution, I can feel stirrings in the underlying structure of traditional content management. No longer are companies and individuals prepared to pay licenses for products of comparable (or lower) quality to those available without charge. With the internet and FOSS culture permitting anyone to learn about certain technologies, Drupal included, there is automatically a draw to study without fee.

As a self taught example of this very situation, I'm confident that others sharing my passion and drive not only exist, but are already picking up the vital skills and experience necessary to push Drupal to its activation energy (I'm a Chemist remember) after which follows, like an exothermic reaction, huge uptake and a boom in usage .

Much like those pondering an early investment in Google or Apple, throw yourself in with the open source ticket in APAC because things are going up.

Cannot redeclare class insertquery_mysql in /path/to/drupal/includes/database/database.inc on line 1774.

Whilst many of them provide work arounds like hacking core to include a class_exists() conditional, simply clearing the cache, disabling APC, upgrading to a (now non-existant) version of APC or just state that since it's not Drupal it's 'not our problem'; none really look to addressing the root cause of the issue.

This summoned a memory of my high school history tuition where I studied, and greatly enjoyed, the topic of Medicine through the ages. A saying that was first used by the Greeks and Romans in the time of Asclepius was that 'Prevention is better than cure'. Admittedly, they probably didn't use that phrase but the sentiment was definitely understood that a healthy, hygienic lifestyle would suppress and reduce the occurrence of illness. In the same way, it is a preferred method to find the root cause of a bug rather than attempt to work around the issue and increase obscurity.

By downloading and running a code sniffer over some of your custom modules, it's likely you'll turn up some interesting results.

Installing PHPCS

Most operating systems/distros will have their own way of code sniffing PHP for syntax, errors, coding standards and the like. A combination of either pear install PHP_CodeSniffer or brew install php-code-sniffer should be sufficient.

This will download the PHPCS package and allow you to use the code sniffer to tell you how bad your code and make you feel bad.

Tracing the bug

Whilst this isn't a certain surefire fix to the redeclared class issue, fixing this has on occasion made that go away. Since PHP 5.3, passing a variable by reference has been deprecated with PHP 5.4 removing it entirely. Passing by reference is now implicit so no additional declarations are required except for on the function declaration.

We can detect where these call time pass by reference issues arise with the following line for our code sniffer.

phpcs --extensions=php,module,inc,install --standard=Generic --sniffs=Generic.Functions.CallTimePassByReference /path/to/modules

This takes any files with the php, module, inc or install extension and runs the sniff for call time pass by reference notices/errors. This will output something similar to the following for an error that needs fixing:

FILE: ...path/to/my_deprecated_code.module--------------------------------------------------------------------------------
FOUND 1 ERROR(S) AFFECTING 1 LINE(S)--------------------------------------------------------------------------------
36 | ERROR | Call-time pass-by-reference calls are prohibited--------------------------------------------------------------------------------

From here it's trivial to alter the function call so my_function(&$var); becomes my_function($var); and with the errors disappearing, so too, hopefully, will the redeclaration errors!

What is Varnish?

Varnish is a reverse proxy HTTP accelerator that is often placed in front of Drupal sites to act as a first line of defense against the swathe of anonymous users who're likely wanting to view all the interesting content present. Because Varnish is a separate service, it doesn't matter whether the web server that the Drupal site runs on uses Apache, NGINX, Comanche, IIS or another piece of software, it'll just work.

Varnish itself acts as a transparent go-between between the users and the web server backend, with any content surfaced from the backend with the correct cache headers being stored for a limited time. The advantages of Varnish are many, with the main ones being:

• Serving content from an in-memory cache means no slow PHP execution and no slow MySQL queries;
• Varnish is capable of delivering at a rate that makes it an F-15 to vanilla Drupal's Cessna;
• The headers are respected entirely from Drupal so unless something is specifically overridden in the Varnish configuration, whatever Drupal says to cache, Varnish will cache.

All of these together make websites behind Varnish fast! Even though the effects are only felt by anonymous users, the majority of traffic for most sites is likely anonymous so the benefit would be great.

Alternatives

Whilst Drupal has a number of different potential caching strategies, it's arguably Varnish that provides the easiest to set up when balanced against speed benefits.

• Drupal's built in database cache system is locked to the database, a slow system compared to memory.
• The contributed module 'Boost' is generally an acceptable choice on memory poor servers but caches pages as files in the filesystem. This can lead to problems on network filesystems like gluster due to the high rate of file read/write operations performed.
• Memcache is a great choice that works well with Varnish although is primarily used for lower level cache (ie caching bootstrap modules and views). Memcache forms a cache backend that Drupal can interact with actively to set and get cached items where Varnish is a passive cache that Drupal does not know about.
• Alternative caches like Redis and MongoDB do exist, but in a similar way to Memcache, to act as an active cache the Drupal site can set and get items from. Drupal also requires a little work to get Redis or Mongo working which makes it a little more technical to implement.

Installation, configuring and VCL

Even though CentOS requires an additional repository, installing Varnish is trivial on Debian, Red Hat and OSX distributions.

(yum|apt-get|brew) install varnish

is enough to get Varnish on the server and ready to start. The default configuration options in /etc/sysconfig/varnish or /etc/default/varnish should likely be changed to listen on port 80 and have a memory limit sufficient for the server.

DAEMON_OPTS="-a :80 \
        -u varnish \
        -g varnish \
        -T localhost:6082 \
        -f /etc/varnish/adam.vcl \
        -S /etc/varnish/secret \
        -s malloc,256M";

The Varnish Configuration Language file can be used to route requests to the cache or the backend depending on logic defined in the VCL. Whilst the default VCL bundled with Varnish does an acceptable job of handling a cache and speeding up sites for anonymous users, a lot may be changed to make pages more cacheable. Following guidance provided by the fourkitchens VCL and with additional logic from the Varnish documentation pages you can ensure you have a cache that flies!

Shielding Drupal from the Internet

Whilst I'm a huge advocate and evangelist for Drupal, and the ease at which sites may be created and extended; it must also be said that when a Drupal site is exposed to the internet and the potentially thousands of users who hit the site, it can struggle. With this in mind, we need to shield Drupal from the anonymous users, bots and spammers so Drupal can go on managing content without the relentless barrage of hits.

The above picture shows a number of the backend connections that Drupal makes on a typical site. With data stored in the database, and cache stored in Memcache, these contribute to a lot of the network back and forth of the Drupal CMS. Occasional additional connections to Mollom to counter spam, Drupal's update service and Google services mean that each time a user request skips Varnish and makes it to the backend, there's more delay. Any additional interactions with a local or remote service will both increase the time taken for the response and potentially overload the server.

By stopping user requests getting to the backed we can prevent the execution of PHP and prevent slow queries to database and other services†

† Slow in comparison to fast in-memory caching from Varnish

Varnish Tools

If you're looking to provide a little proof to those who make the business decisions about implementing Varnish, if you want to compile some stats about the software, if there's debugging to be done, or if you just want to see some cool graphs there are a number of tools that Varnish provides for all these purposes

• varnishstat - Provides a live view of a number of stats provided by Varnish about the state of the ;
• varnishlog - Provides more information than is even possible to comprehend that can be grepped and processed to provide further information, usually for debugging purposes;
• varnishncsa - Gives an output from Varnish that mimics that of an Apache access log
• varnishtop - Varnish provides a ranked list of entries, especially useful when used with the -i RxURL / TxURL parameters to show top requests and top requests that miss Varnish.
• varnishhist - Best used with the '-d' flag, provides a histogram where the '|' indicates a cache hit and the '#' a cache miss; the units being hits vs time. An example varnish histogram is beneath for viewing enjoyment!

Checking Varnish works

One of the simplest way to ensure Varnish is working as expected is to query it using isvarnishworking.com, a quick and easy method of observing Varnish headers. This is a lazy way of either curling the site or inspecting headers using the browser which would produce the following results:

$ curl -kLsiXGET www.adammalone.net ...snip... Cache-Control: public, max-age=21600 Last-Modified: Tue, 17 Sep 2013 00:00:15 +0000 Date: Tue, 17 Sep 2013 09:32:36 GMT X-Varnish: 1607010525 1607008083 Age: 12741 Via: 1.1 varnish X-Varnish-Cache: HIT

Try Varnish out!

Since Varnish is so simple to set up and start using from a beginner level I'd recommend everyone try installing it to gain benefits from the speed boosts! All Acquia Cloud servers come with Varnish in front of Drupal so if you want the most hassle free way of seeing the benefits of Varnish then sign up to a free account and fly with the cache!

What happens though, when:

• A change is made on a production website that causes an irreversible database change
• You want to see which change made in the last two weeks caused a performance regression
• Management want to QA your work prior to release
• You want to dig deep into an issue that requires debug code out of your eyeballs
• Someone asks about your deployment strategy

As someone who has progressed from not knowing what HTML is to someone who pretends to know a little about Drupal I most certainly fell victim to the trap of coding on production for a while. I had no version control, no backup strategy and if the worst had happened, I would have lost ALL of my content.

Since I've started working at Acquia, I've become intimately familiar with developmental workflow employed by enterprise level sites, where QA is mandatory and releases have to be signed off. These are sites with their own development teams and internal issue trackers to fill. The tools on the Acquia Cloud are, to put it simply, fantastic. Although as a solo developer myself, I'm aware that they're also beyond the needs of a lot of experimentalists and hackers.

This is where a personal developmental workflow strategy comes into play, and where good habits may be picked up.

Drush

Standing for DRUpal SHell, Drush is a command line tool for managing Drupal sites. Most of the useful commands may be found by visiting the online man pages so I'll only touch a little on the commands and more on the configuration of Drush such that it may become a tool for locally managing remote sites.

Git

With Drush managing the Drupal site we'll also need something to manage the code that runs the site; this is where version control comes in. Version control provides the ability to ensure complete accountability at every step in the development cycle with the handy benefit of backing up your code! Whilst there is a light hearted rivalry between proponents of git and SVN, I feel that git comes more naturally to me. With this in mind I'll be focusing on git as a VCS over the course of this guide with SVN being, unfortunately, out of scope.

Workflow

The simplest way to explain good workflow for a solo/small team is with the following:

1. Use a local environment to make changes pertinent to a single issue;
2. Once the issue is thought to be solved, thoroughly test in an interim environment;
3. With testing complete, move the changes into production.

This isolation of environments ensures that there is no pollution of bad code into a place that could affect visitors to the site, which in turn could affect business. It also allows for a production site to stay stable whilst a myriad of changes can occur locally which is conducive to an agile development environment.

Expanding on the above bullets we can see why this may have caused consternation in a traditional non drush/git system due to each step being a time sink. Since I'm such an automation advocate, it's my opinion that a workflow must be efficient if people are to be expected to use it.

The old (inefficient) way

1. Write some cool code that fixes a bug and updates a database schema
2. Use mysql-dump tool on a remote server to back-up the database
3. Copy that database to a store locally
4. Move the codebase to the test environment
5. Navigate to update.php
6. Click the button to accept database updates... etc

With git and drush this can happen fast and without requiring pages of instructions to remember steps.

Setting up your local and remove environments

Assuming the user has access to remote servers via SSH, the first thing that's required is to tell Drush about the remote servers and ensure it is able to get to the Drupal installs. By utilising a drush aliases file, this becomes trivial. I've included my alias file here for easy copying and reference. Save your file in the ~/.drush folder as aliases.drushrc.php and ensure you alter the file to include your own server details. It's also important that the user that logs into the server has access to the docroot where the Drupal installation is and that Drush is installed on the remote server.

A simple test to ensure you can connect to your remote installation would be to run drush @alias status and see whether it returned the expected details. The elements of your aliases array defined in the aliases.drushrc.php file correspond to the identifier placed after the @ symbol in the above command.

It's also useful to set up a file to track custom Drush commands you find useful in ~/.drush/drushrc.php. I've included a snippet of mine here so any commands I refer to further down the page won't seem so unfamiliar.

For your codebase, the lowest barrier to entry into version control is to create yourself a free Bitbucket account, head over to the repo creation page and follow the steps there.

After adding all code from one environment to git and pushing them to Bitbucket, you'll want to ensure that this is echoed across however many environments you have. The simplest way to do this is to temporarily move your existing, unversioned codebase out of the way and to pull down your versioned repository.

cd /var/www/html
mv myawesomewebsite /tmp
git clone git@bitbucket.org:myusername/myawesomewebsite.git

If you're working with production sites, I'd strongly recommend placing the production site in version control and then doing the above operation on all dev sites. This will ensure that you're not moving a live site and in turn ensuring the site does not experience downtime.

Some workflow

From here, with Drush able to connect to the remote sites and with everything under git, it becomes trivial to make changes on a site whilst also using best practices in workflow. Taking the example of a single update to a single file (let's use the .htaccess), the following would be recommended.

# Backup your production database
drush @prod sql-dump > /path/to/local/backups.sql

# Sync your production database to you are working with the latest database across your environments:
drush @dev sync-dbs​
drush @test sync-dbs

# Add your changes to the git repository
git add .htaccess
git commit
git push

# Pull the latest commits and ensure the database is updated on your test environment
drush @test pulldb

# Utilise the test environment to check for errors and QA the update
# Switch production into maintenance mode (optional) and run the same operation as on @test
drush @prod offline
drush @prod pulldb
drush @prod online

Whilst this method won't have your production code on tags, it does reduce the barrier for developers to start using drush and git with speed and ease. Questions and comments should go here, get in touch with me over here and I'll be updating this post with any improvements should they arise!

DrupalGov Canberra was a day long event with speakers and attendees from all over Australia. With Drupal already having a strong foothold in the private sector as the go-to CMS/CMF for driving some of the most popular, highly trafficked sites online, and the US government already seeing a lot of exposure to Drupal it's only natural the Australian government would want in!

The aim of the conference was to introduce CIOs, web managers and government development teams that Drupal is both applicable for government use, as well as having a great community of companies and users to back the software and experience up.

On presenting

I was given the privilege of presenting a talk at the event and decided to discuss 'Best Practices and Workflow' within a Drupal development environment which is something I've grown to respect and advocate. Throughout my learning of Drupal, I have simultaneously picked up knowledge of good developmental workflow and tips for not breaking Drupal. It's an easy decision to quickly make a hacky change on production, but by introducing good workflow and using tools like git and drush it becomes easier to do things the right way.

I've made my presentation available online from Google Drive, or as a PDF download although it may not make a lot of sense without me talking on top of it. With this in mind, I've written up a summary of my personal development environment, workflow and included a git/drush cheat sheet for use in your own teams.

Now, since starting at Acquia, I've had a great deal more experience since each of our customers has their websites sitting behind Varnish.

With some of the initial knowledge learned at Agileware, some interim findings after researching Varnish outside of work and more tuition in the software at Acquia I've built up a good enough degree of knowledge to be able to pass that on to others interested.

Within this post, I've included a link to the presentation on Google Drive and downloadable slides in PDF format. Feel free to use and extend as you see fit, just remember to attribute!

Any questions can be sent to the email included in the presentation or alternatively left as comments so others may benefit from the answers.

How?

I always enjoy getting an enormous whiteboard, a number of intelligent minds and hashing out ideas to see what sticks. Visually, the whiteboard ensures both a coolness factor for documentational pictures after the fact as well as a method of allowing people to air their thoughts when words fail.

Optimum configuration would have a semi-circle of tables around a central whiteboard; lots of drawings and everyone using git.

When?

Similar to the Drupal Sprint Weekend, I can't wait to get stuck into creating a cool Drupal site with like minded people. With a concerted effort of developers, designer, site builders and end users for research purposes I'm confident we can knock it off in a weekend!

Why?

A lot of social networks are increasingly turning towards full identification of users although I think anonymity has a place in online society. Websites such as 4chan.org being one of those strongholds where identification is more than optional. If only proof of concept we'll take Confession sites off facebook and into a forum where users can post on the site with a guarantee of anonymity and without the need of a moderator to take anonymous emails and post them to the site.

Another reason to try is to aggregate all Confession sites under one name on one cohesive website. Similar to the google suite of products, rather than having sites sprinkled everywhere online, all sites will be in one location, ready for users to join and contribute to as they please.

So, here's to rapid building of sites and another blog post when we're done.

Disclaimer

Admittedly, the site wasn't built in a weekend; although the majority of the architecting was. Whilst the site itself, logic and tweak modules were ready there's a lot of tiny things that are for the most part mundane yet essential to operation.

• Setting permissions;
• Creating views;
• Writing text for basic pages on the site;
• Anything else remotely site building-y

These are getting slotted in whenever we have time, along with a theme since however nice it is, Bartik likely won't cut it with the cool kids.

What is feature creep?

As the simplest definition, feature creep refers to the myriad small changes that go beyond the initial approved plan, introducing unplanned additions and cause the project to drag.
As a freelance developer, when a client has a list of features and a brief is prepared; that contract exists to protect both parties. The client is protected with a list of tasks that are required to be completed and the developer is protected with confirmed payment on receipt of said tasks.

When the required tasks are extended like the Sahara creeping into Nouakchot, this is feature creep.

Feature creep can exist in a number of ways - from seemingly the most minor (creation of new views/panels) to larger features such as an alteration in site architecture.

My experience

It’s all too easy to fall into the trap of going beyond the brief to supply just one more thing in the effort of staying on the good side of the client.
With that however, comes the risk of continually being expected to provide just one more thing.
For companies on a budget, start-ups, or those inexperienced with brief writing there seems to be a risk of trying to get the most out of contractors.
Care should be taken not to fall into the trap of going along with it to appease the client.

With one of the first clients who sought my services to speed up and augment site experience I almost instantly fell into that trap, despite the fact that I was more than aware of the risk.

Although a brief had been created, with a list of requirements and tasks, the company (a start up) were developing rapidly and had big ideas with rapidly changing requirements. Tasks started off well enough with everything completed to specification. One by one, items were checked off the list and signed off on the client end.

Close to their launch deadline however, things were getting frantic for their team. Funders and investors were on their back and since our working relationship was good, their troubles were conveyed to me in our biweekly catch ups.
With this extra pressure on their back, I found myself stumbling into the unfortunate situation of agreeing to help where they were behind. I regretted it from a business standpoint almost instantly since there was no plan/brief to protect me. However, because I too, was excited about their launch after working with them closely and consistently, it served as a form of consolation that I was helping them out.

How it ends

At an estimate, despite contracting 40 hours I ended up working about 45-50 hours. Despite release being on time, those 5-10 were lost billable hours however you look at it.

Easy as it is to simply agree to more work off the cuff and take up a verbal agreement, I can’t stress enough the importance of getting any further hours contracted. Empathy is almost always a factor when developers agree to work reminiscent of feature creep. Getting drawn into the work isn’t a bad thing but it’s always worth taking a minute to check that you, as the developer, is covered for the work.
Luckily for me, subsequent to the completion of the project I was asked about the extra hours and compensated accordingly.

As a developer, it’s almost inevitable that you will experience feature creep in one of its forms. As long as work is agreed to in writing prior to continuing then there is no creep and you’ve done as you’re expected to do!

I like to customise my machine a little prior to developing and creating local sites to hack core, create new modules and generally contribute back to the community. Some of the changes are for performance and some of the changes are for vanity. An example of a performance change would be to install PHP-FPM and use it with Apache worker. A vanity change would be to have an ascii Druplicon in my motd; not strictly necessary but pretty cool.

One such change I made recently was to alter the hostname of my laptop since I had not set it on distro install. Unfortately I neglected to map the new hostname to my laptop in either /etc/hosts or /etc/sysconfig/network.

The first realisation

After installing Drupal sites on my local machine I'm accustomed to getting welcome emails. As it happened, I started to not receive any emails. This didn't really strike me as odd or annoying as all they did was serve as a method of speedily filling up my inbox; they were not missed.

However when writing and testing implementations of the subscriptions/notifications modules later on the need to send emails became rather crucial; they were then missed.

Fixing

Although rather confusing at first I eventually tracked down the missing mails in the maillog where I found a number of messages indicating postfix simply couldn't find the host typhonius-laptop. Rather sheepishly I pinged typhonius-laptop and waited an agonising number of seconds whilst slowly accepting what had happened; 'unknown host'.

Entering my shiny new hostname in my hosts file and a postfix restart fixed everything. So if ever I decide to change hostname and can't send mail immediately afterwards, I'll know what to do, whilst slapping my forehead over and over.

First contact

Towards the end of last month's billing cycle for my server I realised I'd actually overshot my bandwidth cap by a little bit. This wasn't anything unusual as I was always pushing it in previous months but decided to keep an eye on it at the start of the next month.

Two days into the next billing cycle and I'd used up half of my available bandwidth - oh dear, something is definitely wrong.

Investigation

I figured the bandwidth spike could be due to a number of things:

• My website is suddenly crazy popular and generating huge amounts of traffic - optimistic
• Someone is hotlinking images on my site to somewhere else really popular - unlikely
• My server has been hijacked and is being used as a reverse proxy - I hope not
• Spammers are attempting to post comments an inordinate number of times - possible
• There's an error in the reporting - unlikely

So to narrow down the options, I employed the assistance of MammothVPS's performance page, CloudFlare, AWStats, netstat, and IPTraf. I was able to see the huge amounts of traffic were on port 80 and at a fairly consistent rate of 250kb/s-300kb/s for the past few days. A couple of netstat commands allowed me to see that the majority of apache's workers were connected to by a limited number of IPs.

Further perusal of the awstats pages for my server displyed both the large spike and the narrow range of IPs from which the requests originated.

The first thing to notice is that most of the requests in the top 10 list come from either 120.43.0.0/16 or 27.159.0.0/16. From this, it doesn't take much to realise the origin was China and the Chinanet Fujian Province Network. What was also interesting was how ALL of the requests from this rather distributed attack were for a non-existent page on my site - another indication of malicious intent.

Unfortunately, with around 80000 pages visited and 230KB delivered for the 404 response of each request, there was an excess of bandwidth used, 17.5GB.

Dealing with it

The simplest method of blocking all these requests was not by adding the IPs to the banlist in Drupal (a rather ineffective method of restricting access), rather to add them to iptables or to my CDN/optimiser, CloudFlare.

A number of the following commands:

iptables -A INPUT -s 120.43.0.0/16 -j DROP

with all of the different ranges on both my server and CloudFlare configuration pages really quietened things down and I have to consider myself far less popular now as I've not got nearly the same volume of bandwidth per day.

Bye bye 400000 IPs!

A new lunchtime format allowed for a different audience to attend and I'm grateful to those who took the time out of their work day to show their support!

The format of the presentation was a brief introduction to the three key substituents I use to create distributions:

• Features
• Profiler Builder
• Drush Make

There's a small issue in Profiler Builder that is currently being addressed. If a profile is created using Profiler Builder without the Profiler library and Libraries API the subsequent installation will fail with a WSOD unless

!function_exists('profiler_v2') ? require_once('libraries/profiler/profiler.inc') : FALSE; profiler_v2('profile name');

is removed from the profile.install file.

I've included the files I used in the live demonstration so people may test the creation of distributions and usage of drush make themselves. The simplest method is to download drush.make.txt to a suitable location and then run:

drush make drush.make.txt <install location>

Navigate to the install location in your browser and install the distribution!

I've attached a PDF copy of the presentation to this post, as well as the google presentation and comments regarding it are more than welcome here!

The invitation (pictured right)

gave a tiny bit of information but no real details of Wenatex itself; much as was the case with the previous invite I received and blogged about.

Shortly before 7pm, I arrived at the venue, the Torrance Room within University House at the Australian National University. It was fitted out to banquet spec; twelve chairs in an 'L' shape with the focal point being a single bed and Wenatex branded display poster. My instantaneous reaction was favourable as it appeared a lot of time and effort had gone into attempting to impress event guests.

Totally, there were four attendees and the presenter; a man who made an effort to get to know us and to tell us a little about himself.

The night started with around 15-20 minutes of introduction to Wenatex the company. It covered who they were, what they did, information about how the company was founded and their mission. The presenter was knowledgeable about the company and seemed well practiced at the spiel. Although I had done some prior research into the company there was additional information that I garnered from the intro.

The dinner

Following the introduction came the free dinner, as offered. Wenatex are not the caterer so I don't feel it fair to besmirch the quality of the meal; they after all did not cook it. I was served some kind of chilli/rice dish with sides of corn and fresh bread. It was edible but even as a recipe following amateur I could probably create better. They also served a fried calamari/prawn tempura attempt with a side of chips and salad to other event guests. Again I don't think it's overly critical to say it was nothing special.

That being said, Wenatex are not in the food business and they change venue (hence food) with each event so your mileage may vary.

The talk

I can't say I learned a huge amount of information about sleeping from the talk itself. I got the feeling often that the questions posed by the speaker were leading with the sole purpose of making the participant think the Wenatex product is the only 'sleep system' appropriate for them.

• Would you spend a third of your life being uncomfortable on purpose?
• When you wake up have you ever felt tired?
• Has anyone woken up with aches ever?

My opinion of it was that there was a fair amount of pseudoscience and confidence play in order to get the eventual sale. There was a huge amount of information thrown at me and I had no access to fact checking sources so aside from the things that I knew were incorrect I had to take everything at face value. I found a link to one of their seminar booklets which I believe is available on their website. This should give readers an idea of the sort of information given out.

One thing I did notice about the talk was that from the start the emphasis was decidedly not on sales. The idea of the talk appeared to take the standpoint that the presenter is a 'sleep expert' and they're going to give tips on how to improve sleeping habits. Each person was encouraged to fill in a questionnaire which was then analysed and recommendations given on improving quality of sleep. Since I have no trouble sleeping with my only vice being that I regularly take less 4-6 hours a night I was encouraged to 'Make the most of the sleep with a better bed'. If an attendee suffered from temperature variation it was advised that the sleep system would remedy that. If there was disruption via snoring, the orthopaedic pillow would solve that. The audience were lead to draw their own conclusions from the evidence given and had that all been taken on face value as true; the obvious conclusion drawn would be that Wenatex are the only bed manufacturer to supply adequate beds.

The free gift

Temptations of $50 free gifts are bound to ensnare some people. The gifts offered were either:

• Knife sharpener
• Skin Cream

In addition the attendee was given a $30 voucher to shop at http://amazinggiftshop.com.au. My definition of a gift does not stretch to a voucher for money off but as an observer only interested in the experience it was not my place to stir, rather just to report back the facts.

The bed

I was able to lie down on the bed and test it toward the end of the seminar. The sheer length of time taken to 'learn' everything about sleep meant that by this time I was ready to sleep for real. It was no doubt a comfortable bed to lie in., but I would guess it all boils down to personal preference, and budget. My personal opinion is that there is a fair degree of snake oil involved with certain aspects of the entire package; namely the herbal inlay but I would not stand in the way of any person wishing to buy a bed; indeed a couple attending did buy one.

The prices were shown at the very end of the seminar. Again, I managed to find an online copy of the seminar price list for perusal. As it states, seminar prices are at a 25% reduction which is very compelling in a hard sell environment.

Thoughts

However interesting the talk may be to people attending I was strongly reminded of my Time = Money post. Spending four hours of my time going to a seminar on sleep is simply not worth my time for the '$50 free gift' and at a guess a $5 dinner. I do not however, believe that it is a scam. There is no requirement to buy anything and attending the event is obligation free. I ended up leaving 4 hours poorer, with a full stomach and a knife sharpener. If you're looking for a new bed consider this company in the same way you consider all others. The only major difference is how they market and sell their beds, with suspicion perhaps being gained by this slightly unusual tactic.

At present I plan on being available both days but pending potential attendee numbers that may change to just one day. Make your intention to participate known in either the comments on this site or on the g.d.o event.

Everyone is welcome; if you have built a site in Drupal, you can contribute. We will split into pairs and work on Drupal core issues. Bring your laptop. If possible, install git before coming and git clone Drupal 8 core. For new folks: you can get a head start also by making an account on Drupal.org and taking a look at the Drupal Ladder.

The code sprint will take place at the Australian Medical Association on both days. Since it's a weekend the building will not be open to the public so attendees will need to call 0430365015 to gain entrance.

I'll be present from 9am until late on both days so feel free to drop in and participate whenever.

How much caching are we talking?

With a heavily optimised site, it's likely Memcache will be installed, Apache will be tuned and Drupal will have all the boxes ticked within the 'admin/config/development/performance' settings page.

The combination of these factors will in itself require the cache to be cleared when altering JS/CSS or even content on pages (since they are cached for anonymous). If the fantastic authcache module is installed, there are implications of cached pages for authenticated users too!

If APC is enabled there is the further risk that changes will not take effect until the next time apache/PHP is restarted. The documentation is accurate when advising the user to take care when changing the apc.stat setting. With apc.stat = 0, the files themselves are stored in the APC cache. So even if you make changes to files, they simply will not show the changes until either the APC cache is cleared or apache/PHP restarted.

Keeping files in APC cache can lead to issues and questions as to why changes are not taking effect; but in my experience production sites which do not require changing gain in performance such that the setting is worthwhile.

The right way

• Develop then optimise the server. Don't burden yourself with having to clear caches and restart things with every little successive change. Not only would it massively explode the length of time it would take to develop anything; it'd be damned annoying.
• Always have site optimisation in mind. Just because you're developing and creating a site, doesn't mean you can fill pages with enormous views chock full of JOIN queries. If you do that, you're going to have a bad time regardless of however you try to optimise the server.
• Optimise for the site in question. Plenty of other people have written about how to optimise Drupal. Use the resources but target them to your site; a small blog site with limited readers will not likely gain anything from CDNs, varnish and memcache.

• 960px - commonly used on desktop sites.
• fluid - more often seen on mobile sites for full width display.

I recently participated in the creation of a site using Omega as a basetheme with the following theme architecture:

Since it was desireable to have a 960px grid for the desktop site and fluid grid for the mobile site yet also both desktop and mobile subthemes had to inherit basic CSS from the Default Site Theme (background colour, text colour, margins/paddings etc) the default theme must have CSS files for the subthemes to inherit from. A fluid theme will not inherit anything from the custom basetheme if there are no fluid CSS files in the custom basetheme. The same is true of 960px subthemes.

For Omega subthemes the answer is simple, yet sparsely documented. At the very minimum include within your overall Default Site Theme the following files:

• custom-themename-alpha-default-normal.css
• custom-themename-alpha-fluid-normal.css

The default (960px grid CSS file) can also have -wide and -narrow derivatives, responsive to @media queries.

It should also be noted that using the global.css files in subthemes can cause non-inheritance of parent global.css unless the following is adhered to:

• Subtheme global.css are renamed to custom-themename-global.css
• Any declarations of css[global.css] in the subtheme .info file are renamed to css[custom-themename-global.css]
• Within the settings for the subtheme, under 'Toggle Styles', the css file is ticked to be included.

As usual, comments and questions below!

As usual many of us are busy making predictions and new years resolutions that inevitably we shall not keep to. I've made a few of my own and will document them here as a record to look back upon at the end of the year.

The first such resolution is tied to this belief that I will still have this blog and will continue writing. It's both a good outlet and a fine repository for my ideas; lest I forget what I work on.

With this blog and server comes more Drupal, another thing I'm keen to remain ontop of in 2013. I'll be attending DrupalCon in Sydney soon, which will be a fantastic boost to my knowledge and understanding. Perhaps acting the same way that that Drupal DownUnder did last year, as a catalyst that promotes passion for the subject and keeps me hungry to learn more!

There are modules I'm still working on, ideas I'd love to make into contrib and of course Drupal 8. Plenty of things to keep me occupied until at least 2014.

I also have two domain names that remain underutilised; it may be a little unlikely due to other pressures but typhonius.com and glo5.com deserve a little love. Ideas for how I can use them are always appreciated!

Finally, and almost like an aside, I feel it appropriate to proclaim my intention to (re)start learning another language. For one semester at University I started studying Chinese; a less than trivial language. It would be remiss of me to not admit a small reason for continuing is the ability to respond accordingly when I'm being talked about in hushed mandarin. A larger reason, however, is my enjoyment of languages and a desire to lose my monolingual trait.

I'd be interested to hear if other people have resolutions they wish to keep. I offer the comment section of this blog post as a record to prove your confidence, especially if it's the same as one of mine!

Whilst being involved with Drupal, I've been employed in a number of roles, each with different responsibilities and tasks.

• A web shop developing numerous sites for clients with very particular requirements and to a strict deadline.
• Under the employ of NFP sites for friends, family, local clubs and organisations I'm affiliated with.
• An organisation that runs many large, multi-thousands of users, multi-thousands of nodes websites. The ongoing maintenance, management and upgrades, enhancements and general oversight of which is a mammoth task in itself.

I've found that the more I learn about specific topics, the more specialised I become and with that falls the risk of at some point being obseleted. By diversifying my knowledge it's my aim, and indeed personal duty, to remain up to date and relevant to whatever the current trend is.

With this in mind

It is with this in mind then, that I have decided to allow the skills I have developed to be used for freelance purposes outside of work hours. Drupal is something you really have to immerse yourself in to even start to understand. By being involved with all kinds of sites from many different clients you start to appreciate both its scope and gain great knowledge in contrib modules; a skill much underrated!

By the end of January I'll have contributed to around 4 independent sites. The owners/developers/managers of said sites have reached out and engaged me, occupying my already rather full schedule. I'd rather not sit around doing nothing over the xmas break and Drupal 8 can only keep me occupied for so long!

Wish me luck with my endeavors and advice is always welcome in the comments!

Happy holidays everyone!

The lease of my previous place of residence ended on the 10th of December and as such the ten days prior were devoted to removing objects, cleaning and sanctifying the earth in and around the house. Sufficed to say it wasn't a very pleasant task but indeed somebody had to do it.

Whilst scrubbing individual kitchen floor tiles and polishing both nooks and crannies I was afforded an amount of time to think. One thought kept reentering my consciousness and surfacing; Is this the best use of my time?

How much is your time worth?

Whilst I was in VI form fellow students and myself were discussing wages earned at our Saturday jobs. Our Biology teacher; a universally adored and respected man named John Wrighton rather brazenly, we thought, exclaimed how he would not get out of bed for what we were being paid, ~£5.50 an hour.

Now, however, neither would I.

In a post I've written concurrently, I talk about diversifying my abilities and skills. This is not, for the most part, a simple process. Learning new things takes time; time I do not have if I'm cleaning cobwebs from guttering. However that time and the skills learned can lead to jobs in which the position requires broader, more varied or a deeper skillset. These positions invariably come with an attractive pay rate befitting the smaller pool of applicants with requisite abilities. Hence, slightly indirect although possible reward for putting in hours to learn.

I spent around a week in total cleaning, with some crazy late nights all in the hope of a full bond payout. In hindsight, I think my time would have been better spent doing almost anything else and the cost of hiring a professional cleaning outfit to whip through the property would have paled into insignificance in the grand scheme of things.

I feel almost arrogant in saying that my time is more important than the cleaning of a house prior to ending a lease but at the same time, I'm an ineffective non-professional cleaner. Is my time not better invested becoming more effective and more professional in my current career?

My caveats

It should be noted that while it seems like the easy way out, often, to pass on tasks to other people in return for a little cash. One should take the time to assess if their time is worth the money transferred for tasks. My time is not worth so much that I can dine out every night - notwithstanding the fact I enjoy cooking. My time is also not worth having a maid service my apartment every week. However, the once in a fairly long time movement of my entire life... I think I can ask for help with that!

A revelation

Even more recently whilst in the git log searching for when a particular issue was committed, I decided to search for my username; just in case I had missed something.

Oh!

A quick search of that wondrous commit key revealed the commit in the Drupal git repository where I am now immortalised as helping out a little bit. The issue addresses the problems arising after enabling themes that require functions from nonexistent base themes. Downloading Rubik and setting it as the theme without having a copy of Tao is a demonstrable example of what the issue aimed to address.

The unfortunate and slightly bittersweet thing is that the patch committed as a resolution to the issue didn't quite resolve it entirely as I explained in this comment. Hopefully it'll get a bit more attention soon and I may even get another commit credit to my name.

Until then, I'm happy to be able to count myself amongst the legion of Drupal core contributors.

As long as there is time in the day and I haven't fallen asleep at my desk I find it hard not to learn something, fix things, break modules and experiment with other people's inventions. Whether it's Drupal or something else I like to take things apart (metaphorically when talking about code) and see how it all fits. Even if I don't understand it for the most part the general gist stays with me.

So after seeing that the module required someone new to take the reigns I stepped forward and was offered the opportunity to show what I could do!

So if you're new to Drupal, have written some custom modules of your own and want to start contributing back to the community there are a couple of good pathways:

• Think of a unique concept, write a module for it and get yourself approved as a maintainer.
• Write a few patches for an active module, slowly become ingratiated with the maintainer and offer to co-maintain.
• Find a dead module and request the ownership of it in the Drupal webmasters issue queue.

I'm a huge advocate of giving back to the community and paying it forward. If nobody shares then we all limit the next generation of people who share which in turn limits the evolution of the project.

The future of the Block Title Link module

I've blasted through a few of the Drupal 7 RTBC and 'low hanging fruit' issues which are now fixed in the latest dev release. These will shortly be released in the 7.x-1.4 release of the module.

I've mentally planned how to solve the remaining issues in the queue and will do so for Drupal 7 first before the new year. Following this I'll branch the Drupal 6 version of the module and create a backport from the Drupal 7 version so the features are as similar as they can be with the only differences likely to be API based.

It's a module I've used, it's useful, people rely on it, so why don't I finish adding all the random features that users want!

Watch as my bold claims to finish this soon turn around and bite me!

In the space of almost three days I accrued a wallet full of business cards. I can only imagine some were interested in me as a client, others as an employee, perhaps some wanted to expand their twitter following and I'm sure there must have been one who just wanted me to have their number.

As if to personify the well known saying:

It's not what you know, it's who you know.

The business card is the old fashioned way to sequester another soul into your network. To create a connection which could have the opportunity of developing into a symbiotic relationship to rival that of rhinos and oxpeckers.

Does the business card still matter though? Can we not do away with these wallet fillers and instead connect on linkedin, twitter, google plus or simply by email? In so many ways but perhaps the most important when it comes to meeting people, we can. I would venture to say the only thing holding the business card's existence in its hands is the face to face.

Hiding being a monitor with faceless emails flying between parties can make it hard to gauge a person; to really get a measure of them. Tiny afflictions visible only when within the two metre comfort zone; true passion in the words being spruiked or merely a façade displayed in an effort to deceive; detection of 'chemistry' between parties. All of those and more are a result of the face to face.

Unfortunately, being in front of others does not come easily to some people so this rather intimate method is their bane. I'm a fan of it and enjoy the spotlight however, so perhaps I'll allow the business card for a little longer; its days are numbered though.

Of course the easiest method is to let views do this for you; one of the preconfigured views is indeed a monthly archive block, perfect for displaying all the posts for a particular month-year combination. Views also provides a page version of this functionality which I have taken the liberty of enabling here.

This is all right, but what about having some kind of jQuery interaction, instead of a full page load to drill down into further detail what if all the posts were accessible in a dynamic list that expanded when the user clicks on the month.

Implementation

The functionality I've described above is represented exactly, at the time of writing, in the Blog Archive block in the right sidebar. Rather than repeat the methods I've learnt (and modified/expanded upon) describing similar functionality here or in this blog post, ironically about Drupal and written on Blogger. I will instead simply provide readers with two files that should enable them to quickly implement the same block on their site without following a number of finicky step by step instructions.

I will however provide steps:

1. Import this views export into views.
2. Place this javascript file in your theme folder. NB - change the file extension to .js before doing this. The file has .txt extension for security reasons.
3. Ensure the javascript file is used by the theme by including the following in your theme info file.

scripts[] = path/to/archive-block.js

One thing I wanted especially was for non-node pages to expand the most recent month and for all node pages to expand the month the specific node was posted. Of course, if you have some js/jQuery knowledge the sky is the limit!

Update

In your views configuration for the 'Content: Post Date' field in the rewrite results section ensure the box that says 'Rewrite the output of this field' is ticked and within the box check it reads:

<span class="collapse-icon">►</span>

If you can't do that then comment here with tales of your woes, if you can then let me know if you like it!

There's a module for that!

And actually know the module and functionality. It's even cooler when you can say you're a co-maintainer of the module you're recommending; and say it with pride!

My latest experimentation was with the Invite module. The purpose of the module is to allow a site to organically grow by a system of invitations. Existing users of the site are allowed to invite their friends thus creating a sort of viral growth similar to the way gmail and facebook used to work.

After installing and having a look around I came across what I thought was a bit of an obvious limitation of the module; invitations are only granted to roles rather than individual users. This is fine if you want to allow an administrative role to have unlimited invites, or if the desire is to just give all users x invites full stop.

However, it seemed to me to be more a limitation than a useful feature. In good Drupal style I decided to write a patch. Bearing in mind the issue I attached it to is over five years old it seems either nobody else wanted the feature or nobody put aside the time to write it.

It didn't take too long to write and seems to do the trick. If the 'per-user' mode is selected in invite configuration, users may have invites granted and rescinded on an individual, per-user basis.

It may not be for everyone and it doesn't look like the patch is getting committed any time soon but sometimes I just can't help but make things better! If you're keen on seeing this functionality built into the invite module post your thoughts on that issue. If you have similar Drupal stories of module improvement or want to comment on this post do so here.

Learning in the traditional sense of primary, secondary and tertiary education; some certificates and a degree by the time you're 22 can be unhelpful to a surprising number of students.

Whether they're pressured into the wrong field by external factors (read: parents); study something they end up having nothing to do with after graduating (see me), or perhaps deciding later on in life that they wish they had stayed in school rather than leaving early. There seem to always be people whose education did not sufficiently prepare them for the path in life they ended up travelling.

Is there no recourse?

Actually there is. Some people decide to become mature students; indeed there were a couple of students partaking in my degree who had decided to do such a thing.

I however, have stumbled upon something almost entirely different, with one of the most appealing offers in the world; it's all for free.

Enter edX, a collaborative effort between some of the most well known and respected universities in North America to offer free education in a number of subjects to prospective students. Presently offering nine courses I have opted to take two of them; to fill in some of the gaps in the self taught nature of my prior education and to offer me knowledge I may use in future.

• CS50x offered by Harvard
• 6.00x offered by MIT

It is my hope that I'll learn python to a reasonable and practical level as well as boost my web development skills to higher levels. Since they are free courses there is no financial incentive to study requiring me to motivate myself. However the passion I have for all things tech seems to be enough to get me through them in conjunction with work and other responsibilities for the time being.

Give their free education a go and learn something new! You never know where it might take you.

The topic then came up about those who have 'sleep-struck' or in any way assaulted a partner lying next to them. This is where we reached a juncture.

To remain completely neutral from a storyteller and question asker perspective I won't divulge which of the two following opinions was my own.

The set up

The scenario is thus:

• Two related people lie in a bed.
• One of the pair physically assaults the other whilst both are sleeping

For this question we must now lay out our assumptions:

• We must assume both participants are 100% assuredly sleeping.
• Also we must assume both participants are of sound and clean mind. (No alcohol/drug influence and no prior undiscovered psychological issues)
• Finally, we must assume that this was an act not caused by pre-existing fasciculation.

The question

Because the couple were sleeping, does this excuse any assault that has taken place? Is this of comparable incidence to 'pleading insanity' or is the assault of one human by another itself grounds for legal repercussions?

One could argue that the assaulter had prior intent and although sleeping was not adverse to the occurrence. If anything, following the event they were glad since being asleep is as good an excuse as any.

Despite sleep being a state of semi-consciousness are we as humans in control of our bodies? Should it be left to the sleeper to account for their actions or is it someone else's responsibility to?

I suppose the true question would be 'Who is liable for the assault?'

Stop value judging

Does the scenario change in your mind if we alter some of the value judgments you, the reader, has already constructed about the two imaginary people in this scenario?

Remember your answer to the previous question and now answer honestly, does your answer change if:

• The victim was a man and the assaulter was a woman?
• The victim died as a result of their injuries?
• Either victim or assaulter was a minor?

Quite often in law the punishment will attempt to reflect the severity of the crime. Compare battery, GBH and '1st degree' murder, all offer increasingly severe adjudication dependent, for the most part, on the crime being seen as more severe. However if the person committing the assault was not even aware they were undertaking such a task, does the severity of the resulting injury come into play at all?

Although not something you would think about every day I challenge you to honestly ask yourself firstly, if you were a judge, how would you rule? Now, sequentially, place yourself in the position of the victim and the assaulter. Ask yourself how you would like the judge to rule.

I know where I stand, tell me where you stand.

Since I moved to Australia in the last financial year, this has been the first time I've had to complete a tax return properly. Prior to this I was a student or working small casual jobs in England where the tax system is slightly different. I can't say it was a very enjoyable experience but as the saying goes:

...but in this world nothing can be said to be certain, except death and taxes.

Unfortunately I have neither the assets, nor the deviance to enable me to avoid either of the above so I'm restricted to doing my duty and paying up. If only coffee were a deductible and non-renewable asset that I could claim deductions for. Complete with a different formulae dependent on the strength, brand, cost and style of coffee drunk which will calculate the applicable offset. That is however, perhaps a task for another blog post.

One thing that I did struggle a little to comprehend whilst filling in forms was exactly how my semi-ethereal assets are defined. Working in the industry I do and taking that work out of the office during the evening and weekends means I'm dealing with data and the cloud on a deductible basis.

How do you define data?

The hardest part of the tax return however was putting a value and an asset class on some of the less physical items I purchased over the past year; specific to my industry. It started to really make me think about things when I put domain names down. Sure, they're a form of asset but when you really think about it you're just paying someone to use letters in a specific order. I must be an enormous mug as I'm paying for more than one set of letters!

Data too, is hard to quantify. Since it's not really an asset that you own, more a consumable item for which a fee is paid to use said item every month; all very confusing. After a couple of quick skype calls to accountant friends and several hours trawling through various pages on the ATO website I feel like I made an accurate, if conservative judgment.

What will happen with the rebate?

Since I filed with e-tax I've been advised to expect a 12 day wait (not too bad for bureaucratic  standards) before I can start splurging. Unfortunately since I am a mature adult with responsibilities and bills to pay I'll be splurging on sensible boring things. If you've got anything cool/unusual lined up for your rebate let me know in the comments!

This is bad.

The page touts intelligent cron modules such as elysia cron or ultimate cron as a solution to ensure that the tasks that need to run very often do so without simultaneously running the tasks that require more grunt, wipe the cache, cause high loads and kill your site.

After whiteboarding all of the implementations of hook_cron (These functions run when cron does), I ordered them in order of importance and set about writing the cron script to place into the elysia cron settings. I also wrote an external script to call elysia's cron.php every 5 minutes instead of using the automatic cron provided with drupal 7, as the minimum frequency of calling it was once per hour. To ensure we had an active site responsive to reader feedback I decided to run it a little more frequently than default.

Doesn't running more frequently have negative effects?

Elysia cron runs intelligently. For each implementation of hook_cron a threshold may be set. If cron fires every minute and the threshold for system_cron is once a week then nothing will happen and no sites die!

The more important processes to run often are those which provide the user with action based feedback. If a user is directed to a post and sees it rise in the 'Popular Content' section of the site or notices hot topics posts fluctuating with new content posted regularly they will be more inclined to stay and return to this obviously active site.

Running cron this frequently on a normal site would have some slow down implications but elysia cron allows the administrative user to manage them. Taking slow background maintenance tasks and running them less frequently. It's not really too much of a problem to clear old log records from watchdog once a day/week. Checking for module updates too, can be left to a daily process.

So everything works now?

Once I had arranged the modules into groups to execute on the quarter of the hour, every six hours, every day and every week (depending on their importance) I ran into another issue. Every day/week there'll be a time, when all of the cron hooks run causing a momentary, but noticeable drop in performance.

This was brought to my attention by newrelic, a performance management tool I've used a few times to ensure I'm not writing inefficient code and to track where Drupal is slowing down sites.

I could see these regular, albeit infrequent blips in the performance graph accompanied by a reduction in apdex and a report showing cron.php to be the biggest hog of memory, time and processing power. Seeing these regular peaks made my mind jump instantly back to college math. Rather than endure these peaks, could we somehow spread the load out more to get more frequent, yet smaller peaks? It was my idea that this would result in an overall lower average apdex and a more responsive site overall.

The short story is, it worked.

The longer story, with pictures saying a thousand words shows lower overall site loads. The peaks are indeed more frequent but at the same time is on average lower with average load times being under 400ms; good by any website's standard!

An extract of some of my elysia cron timings is included below and available in an attachment for download. I'd be interested to see if people think my settings are too lean and stringent or if I could cut back even further. I'm aware of how important cron is for a healthy Drupal site, but perhaps some implementations of hook_cron are more equal than others.

aggregator_cron 10 3,9,15,21 * * *
apachesolr_cron 0 */6 * * *
captcha_cron 4 1 * * *
morning_news_cron 00 07-09 * * *
dblog_cron 50 4 1 * *
field_cron 40 0 * * 2
node_cron 4 2 * * *
poll_cron 4 3 * * *
radioactivity_cron */15 * * * *
redirect_cron 40 0 * *
rules_cron 30 * * * *
scheduler_cron 40 * * * *
system_cron 10 0 * * 6
update_cron 4 0 * * 0

I've been to a couple of events in the last couple of years. One that I organised, whilst I was Minister for Social Activities at the University of Nottingham Wing Chun club and a few that other people organised in various locations. I even went to one my college organised whilst I was still there; I'm fairly sure I went as 'Doc Brown', a lab coat and white hair are not at all hard to come by when one spent numerous hours in the chem lab.

Over that time I've learnt a little about what works and what doesn't. It's basically the same as any other social gathering insofar as the key to its success is in the name - social. Since these situations often bring people from differing social circles together it's likely that people will stay in those cliques for the duration of the party, unless forced otherwise.

Much in the same way that The Sims have 'Killer Parties', I'm going to have to buy 20 or so pizzas, light several grills, play some music and schmooze my guests with flattery and constant admiration!

As yet my costume isn't fully planned and I will take recommendations for what I'll wear as long as it's within safe for work standards. Off the menu are previous costumes of:

• Doc Brown
• A jedi
• Bond, James Bond
• A ghost (yes it was just a sheet)
• An attempt at Jason Voorhees

An outdoor grill is being provided and food in great abundance is already preplanned. The cobwebs will go up along with spiders, candles, and pumpkins. The lights will be dimmed and Hallowe'en music played, my way.

If I can make this party better I'd sure like to hear ways to host the perfect Hallowe'en Party in the comments.

For users of my generation and those of prior generations working in the IT sector, everything seems so natural and I feel at home in browser, command line or app. Whereas for my parental units, a browser is called an internet, a command line is hacking and apps are kitchen appliances.

Let us not write off those of advanced years however, their wisdom gained from years of life experience deserves to be heard; at least give them the chance to broadcast their musings.

Following my blog post detailing how to create subsites easily, I've been more inclined to spawn new sites on whims or whenever I drop my hat. So when I was approached by parentals coveting my blog and desiring the opportunity to have their own platform I decided to set up a quick site for the over 40s; The Over 40 View.

The challenge for me in this project was to architect a site simple enough for my parents, their friends, colleagues and anyone not familiar with the internet to use. The site needed also to be easy to browse by those interested in what's written and offer a welcoming community aspect which would encourage like minded individuals to sign up and share their thoughts too.

I tried to keep the number of modules to a minimum which would help keep the site simple; perfect for the target audience.

A selection of modules I enabled are as follows:

• Blog - The simplest way for low maintenance multi-user blog sites;
• BUEditor - I like the simplicity of the WYSIWYG editor on drupal.org and simplicity is key here;
• Color - Ideal for altering the appearance of the contributed sky theme;
• Fivestar - Allow site visitors some interaction and feedback with the content written;
• Google Analytics - Important to grab some demographics about the site users;
• Pathauto - Friendly URLs won't scare people off so easily, even the word node can be foreign;

I have opted not to enable comments on the site as moderation can be a bit of a time sink sometimes and I plan to be as hands off as possible. Similarly, I've not set up any database logging, I'd hope there'll be limited errors anyway! Currently the site is administrative invite only but I hope to pass some of that responsibility on to the Over 40 View community to manage their own authors at some point.

If you, or someone you know is over (or at least near) 40 and wants the chance to espouse their views, opinions, and just day to day thoughts either comment on this post, or contact the Over 40 View admin.

Happy blogging and remember: You're never too old to learn the internet.

The file_managed table is where records are stored and retrieved from. file_save and file_load being the operations to save/update and retrieve data about files from the database respectively.

When a file is loaded the $file object contains the following information:

• fid - The unique identifier of the file (similar to a node ID or user ID);
• uid - The user ID of the user who owns the file (usually the uploader);
• filename - The name of the file without any paths;
• uri - The path to where the file is stored in the filesystem;
• filemime - The mimetype of the file
• filesize - The size of the file in bytes;
• status - In the simplest terms 1 for permanent, 0 for temporary (removed at cron);
• timestamp - A UNIX timestamp signifying when the file was added.

Whilst writing modules I've had to alter the uri, the filename and the filesize properties of the $file object. In doing so there were a few repercussions I didn't expect which I've had to resolve.

Why are you messing with the filesystem?

Ideally you shouldn't mess with files. Drupal does an excellent job of managing everything from updates, moves, copies, deletes and even renaming should you have a duplicate.

But.

When using another system that Drupal does not control, nor see operations performed, it is useful to be able to keep any changes made updated within Drupal. Programmatically creating files or requesting and downloading files (Drupal 7 Module Development) requires such knowledge.

Why bother telling Drupal

Altering the uri of the file will cause two major issues.

• The user will not be able to download the file through Drupal
• Drupal will error out if the user attempts to save a file of the same name.

By changing the uri of the file, the path referencing where that file is stored is also changed. When the user clicks on a link to download the file Drupal will look in the place the uri tells it to and return 404.

When Drupal is saving new files to the filesystem it checks to see if there is one there with the same name. If there is, the standard behaviour is to rename files thus:

my_uploaded_file.txt -> my_uploaded_file_0.txt

Picture this scenario:

1. User saves the file foo.txt.
2. File is moved (manually) to bar.txt (but the uri in the database will remain foo.txt)
3. A new foo.txt is uploaded.
4. Drupal will run a file_exists($uri) returning false as foo.txt does not exist in the filesystem (since it was moved to bar.txt). This means it thinks it does not need to rename the file nor change the uri to match said change.
5. Drupal will attempt to insert a record in the file_managed table but as the uri is a unique key Drupal will not be able to insert foo.txt as the old record from the first file still exists.

Changing the filesize of the file can cause downloads to end prematurely as the browser is provided with a Content-Length parameter in the header. If it only expects 20kb it's not going to keep downloading after that!

What if I really want to alter files

If none of this has put you off then the best advice I can offer is:

If in doubt, file_save.

This will update (via drupal_write_record) the file_managed table and hopefully assuage any potential problems!

The Backstory

As some may know I spent a lot of time whilst studying in Nottingham involved in the University of Nottingham Wing Chun Club. Whether it was participating, learning, teaching (or at least attempting to), marketing or developing the site, it took up my time. Clearly, with such a large portion of time and effort invested one could say I am a little attached to the club being the best it can be and looking the most appealing; at least in an online sense.

It was one of the first Drupal websites I ever developed (and I learned a lot from it). I made some absolutely terrible coding decisions that when I evaluated a couple of years later gave me a real shock. However, it is nice to see progression from my dark days of hacking core, ramming random PHP files into the web root and storing additional data in an adjunct SQLite database (and no, the database details weren't added to settings.php). I promise it's all changed now, really!

When I was first given ssh access to the student website server I had a little bit of a look around and remember being significantly underwhelmed by the lack of anything remotely modern. The antiquated hardware was the prime reason I started actual module development on Drupal 6 rather than Drupal 7 (even though all the books I'd been studying from used Drupal 7).

I recently logged back into the server to update some modules and decided to make a list of all the improvements that could be made and where it fell short. It was my intention to offer it as guidance for the University so the server could be improved benefitting all the clubs hosting on there.

• No git/SVN - my backups and version control consists of logging on when I remember and creating a tar archive of the web root and a mysqldump of the database.
• No drush - Have you tried developing without drush recently.
• PHP < 5.2.5
• No reason why PHP 5.3 can't be used but instead it's on 5.1.
• Drupal 7 will not install on PHP < 5.2.5
• No uploadprogress support.
• Apache configuration is non-negotiable.
• The website is located at http://su-web2.nottingham.ac.uk/~wingchun/ - easy to remember right?
• Clean URLs cannot be enabled. This is a semi-follow on of the previous bullet with the only requirement being mod_rewrite enabled.
• Keep alive (a big favourite of mine) is disabled.
• A quick look in the /home directory shows ~170 user directories, each with its own website.
• The server has < 1GB RAM. Vastly underequipped for the number of sites hosted.
• One cannot download to the server. Any commands like wget, curl or services that make requests from external sites like the Update module DO NOT WORK.
• Although the web roots are kept in user directories, logs are kept out of reach where users may not use them to debug.
• I'll go out on a limb and guess the stack is likely unconfigured.
• A noticeable amount of downtime makes it tempting to abandon the server, even if it is free.

Unfortunately, all attempts to contact the University, by way of tweet, to their main account and their student union account (both of which are active) went unheeded; leading me to believe that the University simply does not care about providing quality infrastructure for student run groups. instead opting to ignore requests to open up a line of communication in the hope that nothing will come of it.

In the information age where contact can be made with the click of a mouse and information freely shared I see no reason why I was ignored. Surely, with reputations liable to get damaged by negative feedback the onus is on companies to listen where such feedback is offered.

A Contrast

Through 100% fault of my own whilst booking a brief stay in Meriton on Kent Street, I overlooked a coupon code for 20% off. I read an email from them offering the discount rate and just went ahead and booked, presumably assuming they would just exclaim:

"Oh look it's Adam! He's clearly forgotten to apply his October coupon code. Let's just assign that for him."

Alas this was not the case.

A brief call sorted everything out and I commended Meriton on their service by way of tweet. Receiving a reply, although not much effort on their part, appealed greatly to my very human nature of wanting to be heard. It's simple things like this that cause consumers to stick with particular brands and the development of brand loyalty is important to business.

I'm aware that prospective students to Nottingham will not think twice about whether or not they study at the University based on a blog post discussing servers. But regardless of the content, the attitude displayed speaks volumes.

I've decided to keep the test site up for the near future so people can check out some of the Node.js features I presented:

• Dynamic users online block
• Node.js Comments
• Online Node.js Chat

I've attached a PDF copy of the presentation to this post (click here to download) and comments regarding it are more than welcome below!

Rather than trawling through my digressions I'll place the steps for setting up Drupal sub sites at the top of the post. I will demonstrate how I made http://typhonius.com a sub site of http://adammalone.net

• Point the DNS at the IP of the server.
• Ensure virtual hosts point to the Drupal web root of your pre-existing Drupal site.

NameVirtualHost *:80
<VirtualHost *:80>
  DocumentRoot /home/drupal/public_html
  ServerName adammalone.net
  ErrorLog logs/drupal-error_log
  CustomLog logs/drupal-access_log common
</VirtualHost>
<VirtualHost *:80>
  DocumentRoot /home/drupal/public_html
  ServerName typhonius.com
  ErrorLog logs/typhonius-error_log
  CustomLog logs/typhonius-access_log common
</VirtualHost>

• Create databases for the sub sites.

CREATE DATABASE typhoniussite; GRANT ALL PRIVILEGES ON typhoniussite.* TO 'typhonius'@'localhost' IDENTIFIED BY 'password';

• Create directories for the sub sites in the sites directory. (A useful tip is to make the directory names the same as the domain names)mkdir sites/typhonius.com
• Copy sites/example.sites.php to sites/sites.php

cp sites/examples.sites.php sites/sites.php

• Alter sites.php and add in the directory names and associated domain names.

  $sites['typhonius.com'] = 'typhonius.com';

• Copy sites/default/default.settings.php to sites/[site name]/settings.php

cp sites/default/default.settings.php sites/typhonius.com/settings.php

• Navigate to newsubsitename/install.php and install your new subsite!

Hopefully these steps are reproduceable enough for another person and if not submit a comment and tell me why not!

The long story

I acquired a couple of additional domains a short while ago and as yet haven't decided what to do with them. I'm not just hoarding domains so perhaps desist from linking me to the next meeting of Domain Campers Anonymous. Like many who've spent a portion of their life online I have a pseudonym since being called by my real name online is just so uncool. This was the name I signed up to Drupal.org with.

Since typhonius.com was not in use I decided to nab it with the intention of making a simple one page site giving people a little bit of information about me with reference to that name. Until today http://typhonius.com simply pointed towards http://adammalone.net so anyone navigating there would end up on this site. I didn't feel a one page site deserved its own unique Drupal install and didn't feel much like making a web page from scratch so considered a Drupal sub site as the solution. This was twinned with the fact that although I've worked in Drupal installs which are sub sites ,I've not actually set one up before.

Enter the challenge

After looking online for a number of instructions in setting up sub sites from scratch I found nothing of immediate value. A little bit of intuition and looking through bootstrap.inc I worked out the methods detailed above which appeared to succeed. The advantage of running sub sites is twofold. Not only does it keep the codebase small (vital for a small server like mine), but as each site runs from the same core and contributed modules they only need to be updated once.

The code enabling sub sites in bootstrap.inc is elegant to say the least and I recommend people check out the conf_path function. Checking the current URL and matching against configuration in the sites.php file will alter the configuration path hence which settings.php the request uses.

This applies to things from the manufacturing and services industries to content management and data manipulation. To an extent this is already happening, yet quite often it comes to my attention that tasks are still done by hand.

I'm guilty of this too, but perhaps to a lesser extent. Maybe I could put ssh keys everywhere to eliminate the requirement to take time to enter my password but by the same token, perhaps I cannot be bothered.

Therein comes the other factor involved in automation; the initial investment, be it time or money, to set up. If it takes many hours to set up a system that saves a few seconds, this normally would be too much of a time investment to bother. However a system that saves hours and hours per month of work and only takes a little initial time investment is definitely a wise move.

This extends into the territory of short one liners that someone who works on the command line often will be familiar with. Using tools like sed, awk, grep and rename combined with a working knowledge of vim (or your preferred text editor) can turn an undesirable slog into an effortless task. One particular example this would be when I made a Drupal subtheme and had to rename all the associated CSS files to the appropriate theme name.

rename "s/base-theme-alpha(.*)/new-sub-theme-alpha\1/g" *.css

Not too much time saved with this one liner but it prevents the necessity of altering the name of each file one after the other.

I was taught in high school physical education classes about the principle of SPORT (Specificity, Progression, Overload, Reversibility, Tedium) and how it can be used to train better. This same acronym can be equipped in part to training and work in general. If an employee has to, almost ritualistically, complete a repetitive and mundane task they'll suffer tedium, get bored and distracted leading to a reduction in effectiveness and work rate.

Let scripts and code take care of the uninteresting, repetitive work. Free yourself and your employees from those shackles to be more productive thinking up things that AI is currently not advanced enough to think up. A certain amount of what I, and a lot of others in my industry do, is inventing. I create new modules, find new ways of solving problems and fix things to work more efficiently and save time. Learning that database records and updates were being entered manually and HTML was formatted in the same way every week was a clear sign to me that I could automate and the inspiration for writing this post.

I received an email granting me the Australian visa I applied for in July 2012. This means all restrictions imposed on me by the previous visa (travel and work) were lifted and I have indefinite leave to remain in the country. Something I believe is referred to as temporary residency. It looks like I have around two years to wait for permanent residency but it's all just part of the process and I'm glad it's all proceeding.

After posting exactly the same message on all the social networks I tracked responses and compared them to the audience reached in an effort to determine where my most active 'friends' reside. A minor caveat being that some people overlap social networks so could have, but would not necessarily want to have, commented in more than one network. I'd like to do some further graphs showing which people share networks, perhaps a Venn diagram?

The following google chart is a nice way of viewing the data collected. Although facebook appears to be the leader in terms of percentage respondents, and indeed is (5.71% compared to 4.44% from G+), it should be noted that 66% of facebook respondents are also in my Google+ circles. Perhaps then, it is the case that friends with high sharing/posting tendencies do so on whichever social network they use most, see the post on first or perhaps because others have commented.

I was slightly surprised at the lack of responses from twitter but I suppose twitter offers the least in terms of managing complex interpersonal relationships as Google+ and facebook do.

In summary, it appears my active contacts use both main networks with facebook leading, albeit only slightly.  The proportion of friends responding is similar enough though on both main networks inspiring confidence in me that there is hope yet for the alternative social network. Also I learnt twitter friends don't feel the desire to respond. Either that or they've made their feelings known elsewhere.

Now it must be remembered that a lot of restaurants are good, excellent in fact. However I've always felt a little let down by some minor intricacy where I'm left feeling wanting. It's almost not enough to just cook excellent food anymore.

Food & Menu

Although The Perfect Restaurant shouldn't focus solely on food, that's not to say that the menu isn't important. I hate menus with more than a single page. It's hard enough deciding what colour shirt to wear in the morning sometimes so having the choice of four mains makes life that little bit easier. The other advantage of a smaller menu is that the chefs will be able to cook those four dishes exceptionally rather than being able to cook fifty dishes adequately.

Having regular menu change though, wouldn't be undesirable. If it's going to be the place I want to regularly go, I don't want to keep having the same dish twice. Why stick with X when Y could be so much better?

A lot of the dining experience exists in the general ambience of the place; a theme is always good, especially when twinning the food and atmosphere. The music however, should not be too loud, nor too soft. Far too often I'll either only catch a waft of notes as I wander to my table - or - that'll be the only thing I hear for the duration of the meal. Ideally, each table would have directional speakers with an ability to control the volume for the leisure of those dining.

"Too loud? Let's just turn the volume down!"

The summon

Another thing that could be independent to each table is the ability to waiter-summon. I've seen a number of innovative methods of the waiter-summon. When I dined in Fogo de Chao they used coloured tabs to denote whether you desired attention or not. If the tile was green side up, a waiter would attend your table promptly. If the tile was red side up, the table was bypassed. Curb your Enthusiasm featured bells on tables as a summoner, perhaps a little obtrusive but the general point still stands. Perhaps even having a small switch near each chair similar to those used on aircraft. This would bring even more granularity in terms of which diner requires service.

Having a signal is the optimum method of obtaining service in a busy (or quiet) restaurant. Having repeated asks of "Are you ready to order yet?", not being able to attract attention or simply being ignored would be eradicated in one fell swoop! A coup for the awkward/polite diner and an efficiency tool for the overburdened server.

I'm a huge fan of the round table.

Seating too, is more important than a lot of places understand. Not only the comfort of the seat (firm but soothing), but both the orientation towards other diners and geographic location.

King Arthur had it right when he selected the round table for Camelot. As one who enjoys entering into the foray of animated dinner conversation with friends or colleagues, the absolute worst place I can possibly be is in a corner. I have an effective audience of about three people. This causes table fracture and disjointed conversation requiring double the time to tell stories and forcing some listening to do so twice. The round table prevents people being forced into the corner and allows any diner the conversation spotlight should they so desire it.

Airlocks, on Earth

Sitting next to the door on a cold night is for sure a sustenance ruiner. The food may be fantastic but if the draught is chilling me every time another patron enters or exits it does kill the mood rather. This is possibly on the higher end of alterations a restaurant could make but I'll say it anyway: airlocks. An antechamber that nulls airflow from the outdoors and warms said air would create a stable atmosphere indoors not ruined by the passage of an angsty Antarctic southerly.

It would also remove doorslam from the restaurant equation; one of the leading causes of my discomfort.

The star rating

Finally, because I don't want this to go on forever, the bathrooms are one of the most important, yet simultaneously underrated areas of the restaurant. Some of the best restaurants I've eaten in have had shoddy bathrooms which unfortunately removes a notch or two from my internal rating system. I shall use one of Gordon Ramsay's restaurants, maze, as my benchmark for good bathroom practice.

• Dimly lit, candles and warm bulbs. The ambience of the restaurant continues.
• Paper towels for hands, hand driers may be environmentally friendly but the noise generated is aurally unfriendly.
• A selection of hand creams and lotions to make even the gruffest of men feel pretty.
• Excellent decoration. The bathrooms should not be an afterthought, but integrated into the overall design. Wood panelling on the outside well my cubicle better have that same effect.

It's a small internal game I play to rate the bathrooms of places. Points may be attained with scented candles and a man offering to spray cologne yet lost for cigarette burns on the porcelain. It's a dangerous game to go cheap on the smallest room.

I'd be interested to see if others share my opinions or have their own ideas on what would make The Perfect Restaurant. Comments are below!

As I explained in this forum post, the development of a module that enables anonymous deletion arose from the desire to instantly remove spam comments that bypass any spam filtering on the website. A lot of emails notifying me of comments being posted arrive in the email box on my mobile phone. Since this isn't continuously logged into my site, having to log in every time I want to delete spam is a pain. By having a callback, secured with a hash, that can delete individual comments without logging in I am able to delete any comments with ease.

/**
 * Implements hook_menu()
 */
function mymodule_menu() {
  $items['comment/%/fastdelete/%'] = array(
    'title' => 'Fast Comment Deletion',
    'page callback' => 'mymodule_comment_fastdelete',
    'page arguments' => array(1, 3),
    'access callback' => TRUE,
    'type' => MENU_CALLBACK,
  );
  
  return $items;
}

/**
 * Authentication function for menu callback determining if the
 * comment should be deleted
 */
function mymodule_comment_fastdelete($cid, $hash) {
  $comment = comment_load($cid);
  // First check to see if the comment actually exists
  if ($comment) {
    // Add in a timeout so the comment can be deleted only in the
    // first 24 hours after posting.
    $timeout = variable_get('user_password_reset_timeout', 86400);    
    $current = REQUEST_TIME;
    if ($current - $timeout > $comment->created) {      
      drupal_set_message(t('You have tried to use a comment delete link that has expired. To have the comment deleted please contact the site administrator.'), 'warning');
      drupal_goto('contact-me');
    }
    else {
      // Load part of the user object of the node author for a secret string to send to user_pass_rehash
      $author = mymodule_node_author_pass_from_cid($cid);
      if ($hash == user_pass_rehash($cid, $comment->created, $author->pass) && $current >= $comment->created) {
        watchdog('mymodule', 'Comment Autodelete link used', array(), WATCHDOG_NOTICE);
        comment_delete($cid);
        drupal_set_message('Comment successfully deleted!');        
        drupal_goto('node/' . $comment->nid);
      }
      else {
        drupal_set_message('You have tried to use an invalid comment deletion link.', 'warning');
        drupal_goto('node/' . $comment->nid);
      }
    }
  }
  else {
    drupal_set_message('You have tried to use an invalid comment deletion link.', 'warning');
    drupal_goto('');
  }
}

/**
 * Generates the deletion link for a specific comment.
 */
function mymodule_comment_fastdelete_link($cid) {
  $comment = comment_load($cid);
  $author = mymodule_node_author_pass_from_cid($cid);
  // Combine a number of variables to construct a private hash that will be validated in order to delete the comment.
  return url("comment/$cid/fastdelete/" . user_pass_rehash($cid, $comment->created, $author->pass), array('absolute' => TRUE));
}

/**
 * Returns the hashed password of the node author the comment is posted on.
 * Used for an unknown part of the hash that an anonymous user could not guess
 */
function mymodule_node_author_pass_from_cid($cid) {
  $result = db_query('SELECT u.pass FROM {comment} c JOIN {node} n on n.nid = c.nid JOIN {users} u ON n.uid = u.uid WHERE c.cid = :cid', array(':cid' => $cid));
  return $result->fetchObject();
}

/**
 * Implements hook_token_info_alter()
 */
function mymodule_token_info_alter(&$data) {
  $data['tokens']['comment']['comment_fastdelete_link'] = array(    
    'name' => t("Comment Delete Link"),
    'description' => t("A link to immediately delete a comment."),
  );
}

/**
 * Implements hook_tokens()
 *
 */
function mymodule_tokens($type, $tokens, array $data = array(), array $options = array()) {
  $replacements = array();
  if ($type == 'comment') {
    foreach ($tokens as $name => $original) {
    switch ($name) {
      case 'comment_fastdelete_link':
        $cid = $data['comment']->cid;
        $link = mymodule_comment_fastdelete_link($cid);
        if (isset($cid)) {
          $replacements[$original] = $link;
        }
        else {
          $replacements[$original] = '';
        }
        break;
      }
    }
  }
  return $replacements;
}

I've allowed anonymous users the permission of deleting their own comments on this node as a proof of concept for people wishing to test out the functionality. I'm considering creating a separate module for this functionality and releasing it for other Drupal users. This is all dependent on responses to this post, if they're good I'll make a proper module out of it!

A couple of additional things I'd add into a module would be the ability for the administrative user to allow/disallow the functionality on certain nodes/content types. I'd also add in some kind of alteration if the comment has child comments beneath it. Perhaps instead of deleting the comment a better way to deal with it would be to replace the comment body text with [deleted] or similar.

I'm currently writing a module in my spare time with the emphasis on providing the integration of Drupal and seedboxes. More a proof of concept module than anything else. In doing so, I've ran into a couple of limitations of Drupal when it comes to storing files of large size.

The first limitation is storing filesizes greater than 2GB. The system module within its hook_schema declaration for the file_managed table casts the type of field to be that of 'INT':

'filesize' => array(  'description' => 'The size of the file in bytes.', 'type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE, 'default' => 0, ),

For general use this isn't too much of an issue, however since MySQL's signed INT fields have a maximum value of 2147483647 bytes, trying to put any value larger will result in an error. This occurs whenever file_save occurs with a $file->filesize larger than the threshold.

It's not too hard to change this but we must change it in the correct fashion so it does not get overridden in future and so the rest of the system is aware of what we've done.

Within the module I am writing I've added a few things to hook_install and hook_uninstall as well as putting in a hook_schema_alter

/**
 * Implements hook_install()
 */
function seedbox_install() {
  db_change_field('file_managed', 'filesize', 'filesize', array('type' =>   'int', 'size' => 'big',));
 }
 
 /**
  * Implements hook_uninstall()
  */
function seedbox_uninstall() {
  db_change_field('file_managed', 'filesize', 'filesize', array('type' => 'int', 'size' => 'normal',));
}

/**
 * Implements hook_schema_alter
 */
function seedbox_schema_alter(&$schema) {
  if (isset($schema['file_managed'])) {
    $schema['file_managed']['fields']['filesize'] = array('type' => 'int', 'size' => 'big', );
  }
}

The first declaration has the effect of changing the structure of the filesize field from INT to BIGINT, hence raising the largest storable value to around 9.2EB which should be able to cater for files way into the future. We also must change the field back when we uninstall the module which is where hook_uninstall comes in.

The hook_schema_alter is simply a polite way of letting other modules know what we've done!

Downloading large files

Unless you're lucky enough to have gigabit speed internet to your home, or unless you're storing large files in Drupal on a LAN the connection speed is likely to be limited. In a private file system, any download is done so through PHP which has a maximum execution time. I was finding that when attempting to download large test files after a period of a few minutes the download would cancel with the rather confusing error of 'size mismatch'. A little bit more looking through logs and file.inc in general revealed the most likely cause was PHP execution time being exceeded.

I didn't want to change the execution time globally as this could have further repercussions on other sites on the same server or just on the operating of the site in general. The other option was to amend file_transfer and place a set_time_limit(0); directly before the file was transferred to the user. Since hacking core is hacking core I decided to find the relevant hook and place my declaration there.

The reason I limited to the streamwrapper I implemented was to limit the number of times PHP's execution limit was removed.

/**
 * Implements hook_file_download()
 * Due to the large size of some files it is necessary
 * to remove the restriction imposed by PHP on the length
 * of time it takes to execute this transaction.
 * Currently set to unlimited time, this could be altered
 * in an admin interface potentially
 */
 function seedbox_file_download($uri) {
   if (file_uri_scheme($uri) == 'seedboxdownload') { 
     drupal_set_time_limit(0);
   }
 }
 
 /**
 * Implements hook_file_download()
 * Due to the large size of some files it is necessary
 * to remove the restriction imposed by PHP on the length
 * of time it takes to execute this transaction.
 * Currently set to unlimited time, this could be altered
 * in an admin interface potentially
 */
 function seedbox_file_download($uri) {
   if (file_uri_scheme($uri) == 'seedboxdownload') {    
     drupal_set_time_limit(0);
   }
 }

I generated files using the dd command, specifically:

dd if=/dev/zero of=filename bs=1 count=1 seek=1048575

After running a

yum install nginx

I found that not all modules the NGINX Drupal configuration files required were present. After downloading the latest NGINX source and recompiling a few times to add in dependencies I skipped prior to this I found the following compile options worked for me.

One caveat is that the NGINX upload progress module should be downloaded first and placed in the /root/ directory (for the following compile options as that's the location set for the --add-module option!)

If PCRE is not installed, it should be, to allow URL rewrites:

yum install pcre-devel

Similarly, the compile options will require openssl for SSL support:

yum install openssl-devel

path=/usr/local/sbin --with-http_ssl_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-cc-opt="-I /usr/include/pcre" --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --conf-path=/etc/nginx/nginx.conf --with-file-aio --with-http_flv_module --with-http_mp4_module --with-ipv6

After making and installing I moved the existing contents of /etc/nginx to a backup folder and cloned the Drupal settings from perusio's repository into /etc/nginx

git clone git://github.com/perusio/drupal-with-nginx.git

I did make a few alterations to suit my system more appropriately but these may be omitted in other usecases:

• Renamed the user from www-data to NGINX
• Allowed access to NGINX status to an external IP address (my own)
• Changed ports for PHP CGI server (as I had another service operating on port 9000)

Other than that, I created the myself a site config file within sites-available by copying the existing example.com.conf and inputting my own values. The most important values to check and/or change are:

• server name (The vhost NGINX should be listening for ie adammalone.net)
• Log locations (debugging one large error log on a multi-site install is a major pain)
• root (where the website is installed)

The only caveat with the above is that NGINX will only allow access to index.php as standard. To allow access externally to cron.php and update.php then the line including additional configuration will need to be uncommented:

include sites-available/drupal_cron_update.conf;

I use Drush for cron and update so this was not an issue in my install.

After all the time it took learning about NGINX configuration and after having used apache for years prior I decided to change back to apache for a number of reasons. The primary reason was the site experienced a few random lock ups. I'm unsure whether this was attributable to NGINX or PHP CGI, but having limited knowledge in the two I was unable to do much better than restart both services to clear the issue.

I did, however, find that NGINX config files were a little easier to understand at first glimpse over apache. Simple declarations and not a lot of them mean a site can be raised very easily without a great deal of worrying about

</VirtualHost> without matching <VirtualHost> section

or

Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

NGINX also seemed a little snappier using default untuned configuration compared to default untuned apache configuration. This may just be due to the server I was using being more suited to those defaults but it sure did seem more responsive from an end user perspective.

My overall conclusions would probably be to try it out, as it may work nicely for differing uses however for the time being I'll stick with apache. It does serve most websites after all!

I'm not going to repeat too much what this site says about Baader-Meinhof but I will give my own experiences of it in relation to Drupal. I have to keep this blog vaguely relevant right?

Over the past few days I've been doing a little more work on ​another​ contrib module. It's currently still in sandbox but when I, and some of the community, are satisfied with it I'll promote it to a full project. Writing README files isn't really my idea of a good time but I'm aware of how necessary it is. README and INSTALL files like those linked are some of the most downright unhelpful things to be included in modules when you can't accomplish what you set out to immediately.

Within that module I decided that rules integration would be an excellent idea. I gave ​The Tiny Book of Rules a whirl and set out to write the custom events, conditions and actions that would give the module some much desired automation. It must be said that I've not really paid a lot of attention to rules before. Sure I'm aware that you essentially have to use it for anything Commerce related and I've heard tales of its uses but I've never really dabbled in it personally.

So here's the twist. Today whilst discussing methods to allow certain users instant access to auth-only material, rules seemed the perfect choice. I was able to explain how to implement something and​  I could even use complex words like 'action' and 'event'!

To the pre-Baader-Meinhof ​Adam Malone​ that's a spooky coincidence! I only learned about it a few days ago and suddenly it's useful, however I must now accept the more mundane answer. There have probably been a hundred or so other times prior to this where rules could be used to solve some issues that were plaguing us. However, because I was unaware of its power I did not suggest it. Now that I know of rules, sure enough, a use case appears and it seems like magic that I only learned about it the other day.

It's a sign!

The article linked above really is worth a read and I can guarantee you'll start experiencing your own personal Baader-Meinhof phenomena soon.

Perhaps it's my fault for allowing anonymous comments but without allowing any form of reader feedback the flow of content is one way, not the greatest idea for the website of someone who advocates transparency and sharing of information. I don't want to make people register to comment either, as:

• People don't want to register to sites to comment and will more likely not comment than register.
• The spam created will now be in user registration rather than comment and I'll have to filter through them instead.

What options do I have for dealing with spam?

Luckily, the Drupal community being the way it is,

There's a module for that!

In fact there are several. They can all be vaguely categorised into one of three categories:

• Protection against bots
• Prevention of posting advertisements/medication
• Quality control

To take a huge chunk of the spam filtering modules out in one hit the CAPTCHA module has most covered. By including a field at the bottom of comment forms CAPTCHA includes a variety of techniques for deterring/rebuking spam posted to the site. From the very simple math captcha to a more complex pictorial captcha this really is one of the simplest ways to prevent spam.

CAPTCHA and assorted modules like Field Hidden are best targeted against bots. Spambots are getting better at solving captchas yet they have a tendency to want to fill every field. If they fill a hidden field that a human would not normally be able to find; caught!

I even wrote my own form of spam protection module, Unique Comments. It is however, not an attempt at preventing Zopharin (or whatever drug it is) being advertised. Rather, an attempt to ensure that as the site matures, users take a requisite amount of care in the comments they add.

Similar to the concept spawned on the xkcd IRC and explained in the subsequent blog post, the module ensures that no two comments (either site-wide or on a node by node basis) are the same. As time goes on, the amount of possible comments diminishes until users have to be constructive and use more than one word!

Unique Comments therefore probably falls closer under a quality control banner than actual spam protection. This puts it in the same category as half of mollom. The other half of mollom falling under actual spam prevention, it's a good service on the whole from my experience but has the downside of sometimes being too efficient in judging comments as spam.

​Further spam prevention

​An ever increasing number of spam comments is written by humans. This makes hidden fields and captchas ineffective since humans are ​able to fill in the number of copy the letters. This then gives rise to more intensive methods of blocking and banning users who contribute spam. By blocking a number of users in iptables (around 8 IP addresses) I've stopped the majority of spam arriving at my site. This is possible for site administrators who are not so savvy by using drupal's inbuilt IP blocking mechanism and by adding the offending IP addresses to the block list (admin/config/people/ip-blocking).

All in all spam is an unfortunate thing we appear to have to deal with. Here's hoping for more botnets fall leaving more webspace for us legitimate users.

It was my turn to DD recently and thought it would be a fairly early night so wasn't too bothered. Opting to go to a fairly popular cocktail bar at around 10 and then home by before midnight. At least, that's what I presumed.

By closing time, around 1am, we were invited out further by colleagues of a friend I was with. Thus began the saga of me entering a club, Mooseheads, entirely sober.

It was a mess.

That being said, it's an experience I'd recommend people try out, if only for the sheer morbid curiosity.

Being sober isn't really what clubs were invented for. They were created for the purpose of getting people drunk, then presumably laid (depending on the prowess of either party and the level of inebriation). To the person under the influence clubs are wild, exciting, dance-inducing blurs of intensity. Unfortunately for me, on that night, it was a sticky floored, sub thumping, dazzle-eyed, kind of stinky area of massive over-stimulation.

I'm not talking about first years getting over stimulated either; that was me. There was so much going on I could hardly keep a track of it. From the guy who took his shirt off and bared his enormous belly to the world, to the guy who used his bottle as a phallic object spraying beer on people, to the guy who walked up to the girls next to where I was sitting to chat them up. I could hardly take it all in; and I loved it.

I have a greater respect than ever now for the door staff. Where there are nine incidences of guys play fighting there is one actual squaring up. Maybe they can smell it, but I was impressed at the speed and accuracy with which they were able to differentiate.

The point of my story is to try it out, deprive the clubs your payment for just one night and experience what it's like to club sober.

So I put it to you, humble anonymous readers, rename this website into something other than my name and allow me to flourish into at least B-league.

A few caveats, I'll be ignoring suggestions with titles including but not limited to:

• Anything that will put me in prison/legal hot water
• Names advocating actions outside of/in contravention of the Geneva convention
• Things you wouldn't say to your mother

Play nice and rename me!

However, this does not manifest itself in the same way as it does for conventional creativity. What I assume most people think, as this is what I previously thought, was that to be creative you had to be fantastic at art, writing, music or dramatics. Those who painted, sculpted and wrought masterpieces from paint, pen, clay and iron were the true creatives. Those musicians who trilled, acciaccatura'd and crescendo'd their performances with great flourishes were the true creatives. The dramtists who created imagery through the characters they portrayed and conveyed what could be taken as true and genuine emotion were the true creatives.

To be fair to myself, I have dabbled in the aforementioned arts somewhat. I played a musical instrument throughout the majority of my pre-university life, performed in a few of the projects the high school's drama club wrote (although I wasn't a drama student) and have in the course of my lifetime written to a number of blogs. We'll leave the art category out of this as I peaked at stick figures.

All this being said, I never got very far with any of those creative pursuits. Sure I managed to pass level 1 but when the max level cap for acting is level 99 I wasn't even close. On a scale of 0 to Gary Oldman I fall towards the lower end of the spectrum.

The more I've thought about what it takes to be creative, the more I consider the work I do to be a creative pursuit. Writing code and styling sites, making decisions on workflow and using drupal to carve out successful websites is to some extent a creative process. Draw inspiration from here, imagine up a few additional details here, gain advice from dreams over there and code up a storm from around there.

All that digression aside and coming back to the point of this post, I was recently directed to this tumblr site. To some it may just seem like a few pictures of cartoon things​ but to me it was 151 artists' impressions of my childhood. I ​breathed​ Pokemon for a number of years, buying games, trading cards, having battles, watching the anime and generally talking about it with a number of friends at every opportunity.

• I remember when my Grandfather bought me a booster set of cards and inside, the fabled Charizard shiny.
• I remember when I took that same shiny to school and someone ran off with it only to be chased down by my friend group and I who demanded they give it back.
• I remember playing Pokemon Snap on my Pikachu edition N64.
• I remember defeating Pokemon Red, Blue & Yellow.

The list of Pokemon related memories I have is almost beyond writing and those memories don't even require strain to remember. In all likelihood I could probably still recite, off the top of my head, at least 130 of the first 151 Pokemon.

So when I see some of this art, with knowledge of my own artistic limitations and now that I am no longer an impoverished student I feel it's acceptable to treat myself. Although I've been ridiculed by a couple of close friends for desiring some of these I felt vindicated when revealing my ambitions to other friends who had the same love as me when I was younger.

Although the exhibition has ended and the prints are no longer for sale I've since been in contact with one of the organisers and followed her advice. This lead me to contacting Jane Mai and Erik Krenz who created a couple of the pieces I liked the most. Wish me luck for my first foray into the art world, if all goes to plan I will have things to hang in my study that make me smile when I look up during my own creative escapades.

I was at a friend's house a couple of nights ago when we were shown a letter that came through their door. It was an invitation to an obligation free dinner and seminar hosted by Wenatex for a couple of weeks from today. The invitation also included 2 x $50 gift certificates to be redeemed on the night.

After reading through the extensive documentation that accompanied the letter I uncovered a couple of key pieces of knowledge.

1. The lack of information about exactly who Wenatex were and what they do was so obvious they may have well stamped it on the envelope.
2. Basic details that seeming to check out were that the dinner was at the Hotel Kurrajong in Canberra and that it was most definitely free and without obligation.
3. Something vague about sleep and sleep products.

As anybody who has heard of a 419 scam or indeed has ever received any​ form of marketing ever this instantly screamed out to me ​TOO GOOD TO BE TRUE.

Thinking that I'm extremely tech savvy (Come on I own my own domain!) and that I am a child of the Internet generation I decided to delve into the murky world of information gathering with a quick Google search.

After finding their amateurish website and taking a good seven minutes clicking links I found next to no information about their products and absolutely no information about their prices. Personally, if I wanted to sell my wares, which are highly sought after, I would at least advertise them slightly better on my site than Wenatex.

The website was almost no better at giving me information than the aforementioned documentation accompanying the letter so I decided to look at 3rd party blogs and forums to see what others in my position had to say.

After reading posts from here, here, here and here the rest of the picture was fleshed out and I gained a more full understanding of who Wenatex are, what they do and what these seminars are,

By ensnaring people with a free meal at a nice establishment it Wenatex employees ​allegedly​ then enter into an exercise in hard selling. With beds and bed products costing thousands of dollars attendees are allegedly​ pressured into buying the products with tactics such as "We are offering this <reduced but still damned expensive> price for one night only!" as well as a lot of implausible information about how sleeping on a bed of dried herbs or using a goat milk mattress benefits sleep. I've read they also show magnified images of bed bugs which I'm lead to believe Wenatex beds are immune to.

The psychological effect of these tactics leads people to believe that Wenatex beds are better for their general health and wellbeing. Take also into account that they're reduced for one night only incites the sale.

Since the meal is free and they state multiple times that it's all no obligation I feel there's no harm in taking advantage of their generosity and acquiring a free meal in the process. I'd like to believe I'm resilient enough to resist the hard sell; even if I'm not I doubt my bank account would acquiesce quite as easily.

My advice to anyone else who has received an invitation to a Wenatex event offering free meals, gifts and the like is to go to dinner but treat everything they say with a healthy degree of skepticism. Don't be taken in by any marketing ploy and trust your instincts when they unreservedly tell you herbs belong on food, not in blankets.

In summary:

• Acquire free meal
• Acquire free gift
• Ignore hard sell
• Leave happy

I'll have a few side projects on the go at any one time which makes accomplishing other things difficult. Each of them competes for my time in ways that, alas, cannot fulfill another. In a way they are the four base categories I can fit any part of my life into if asked at any point.

For example, this blog post would be considered a side project as it's something I like to do but is non-essential to daily living. It has the benefit of allowing me to vent, as well as giving me some writing experience and improving the SEO rankings of my website, hence my brand.

Other side projects would include developing drupal modules and general personal research and development. My justification being that I'll need to stay at least towards the head of the curve so I can be ready for the next best thing.

I also have to give an amount of attention to she who must not be named and to work.

Once all of these are taken into account I am able to put time into the final category: sleep. This doesn't mean that I will receive no sleep, it does however mean that my sleep time will not be the full amount I need to ​feel refreshed.

It has become quite obvious that out of these four categories, I really, truly only have time to accomplish three. This is unfortunate as more hours in the day or some kind of time dilation device would really help. However, these are currently impossible, so I guess I'm sleeping when I'm dead.

Since I like to think of myself as a man of the internet having a good connection for every waking moment. It makes me happy to see places embrace the online-always culture and offer free wifi to their clients. Companies like QLD Rail, Delta and even the London Underground have, or are soon rolling the service out.

What annoys me is how narrow minded a lot of hotel chains still are when it comes to providing online access to guests. The mentality is that online access is a luxury that guests must pay top dollar for low quality service. I could understand a little more if this were the early 90s where it would have been expensive for the hotel to be online and relevant technologies were sufficiently new to demand paying a premium. However, in 2012, is it too much to ask for free, high speed internet whilst I stay in hotels?

Having been a business customer a few times, and hopefully more in future, internet access is necessary for pre-meeting preparation, general worldly awareness and even just to stay in contact with people. As a pleasure user, heck I just want to read some blogs and browse Reddit!

Since the advent of mobile phone wifi modems it's all too easy to simply set my phone to broadcast and connect a laptop and tablet to browse late into the night, as I did last night!

I was able to stream video from vimeo, read a few articles using pulse/Google reader, post last night's blog article and yes I could even fit in one round of Draw Something.

With all this in mind you might ask why I'm complaining about hotel wifi when it seems I am adequately prepared to deal with no access by simply tethering.

There are two main reasons:

• Sometimes you just don't got good signal
• Stop being technology dinosaurs, get with the times and realise that offering it could make the difference between guests staying at your hotel or not. More and more so into the future. If you do not adapt, you will fail.

At present it seems almost impossible to imagine the end of the search giant. It being present in my life to the extent that I use it every day, to say the least. My workplace (and my own domains) run on google apps, and after the pain of running my own mailserver, having google take over lifted the load considerably. On Monday I'll receive my new Nexus 7 which will accompany the Galaxy S2 and Asus TF300 I have. All of which run android and utilise the play store, provided by google.

The thing a lot of people seem to forget is that google is, at its heart, an advertisement company; not unlike facebook. The difference that leads to this omission in peoples perceptions what I like to refer to as the 'iPod Effect'.

When I was younger, in high school, and worked retail on Saturday mornings at a local consumer electronics shop I would get the same question over and again.

Would you recommend I get an mp3 player or an iPod?

The way Apple's marketing team, or Steve Jobs himself, or a combination of all had advertised the iPod made it seem like an alternative to the mp3 player; whereas in fact, they are one and the same. Or, more accurately put, an iPod is just a subset of the generic mp3 player category.

This same effect is still prevalent and only a couple of days ago my, quite obviously Asus, tablet was repeatedly referred to as 'iPad'. Almost as if one can purchase either a tablet OR an iPad.

Bringing me in a wide circle back to why Google has 'Apple Effect'. Perhaps it is to do with their motto or just how it they are perceived as a generally philanthropic company by providing all these amazing free products for users.

Either way, the perception that they are not out to do harm has, in part, made them highly successful and has acquired them a HUGE number of service users who in turn have developed the kind of reliance on them I admit to having seemingly making them too essential to fail!

However, as is often the case, things must run their course. Like the tide coming in and then retreating I find it hard to believe a company will last ad infinitum. I made it clear to my friend that I doubted any 'ungooglication' any time soon, however when they would inevitably be replaced as they , in the beginning, replaced others (Yahoo, Alta Vista, Ask Jeeves) the replacement would inevitably be an improvement as was the case when google initially took over.

In summary, After Google (whenever that is) won't be the end of days it would seem if that day were suddenly tomorrow. Like the slow, yet constant take-up of alternates to IE, it'll be a trickle rather than a torrent and more likely than not we'll not even realise it's happening, until we're all using the AG Alternative.

I have been working on a firewalled (remember this for later) development server over the last couple of weeks at the AMA. With entries into host files, .htaccess files and firewall rules to prohibit those not developing the updated site from accessing it we considered it pretty locked down.

Development was going well with custom and contrib modules almost finished and the theme pulling together well. Drupal requires a few extra configuration options be set such as user permissions, metatags, labels on fields and things like sitename/slogan. One of the final things on the checklist was to turn clean URLs on. After navigating to the clean URLs page I ran the check and it failed;

Detective Work

ok this has happened a few times before, let's just revisit the handbook and go over the steps.

• Ensure mod_rewrite is on.
• The server is debian so a quick apachectl -M showed rewrite_module (shared) so that was fine.
• Ensure the httpd.conf file allows the Drupal .htaccess file to overwrite it?

<Directory /home/amalone/web/ama/>
AllowOverride All
Order allow,deny
allow from all
</Directory>

• Looks good to me.
• Check the .htaccess is even being read by putting some junk text in there and see if it breaks the site.
• Error 500. Check that off the list.

At this point I decided to give up for a while and assume some weird magic would allow me to enable clean URLs at some point in future since I was at a loss.

Eventually I got back round to it and did some more investigation. Looking at the code in the system module (system.admin.inc) I could see that when the user wanted to check if their site was ready for clean URLs drupal does a drupal_http_request to itself at an address of http://example.com/admin/config/search/clean-urls/check which would return http code 200 (OK) if clean URLs can be enabled and would fail if it could not be enabled.

Thinking on my feet I immediately requested that URL in my browser and received the following json output:

{"status":true}

So where is the issue?

​The Solution

Remember at the very top of this post when I said it was a firewalled server due to it being under development? Turns out the server could not access itself from outside, so a relative link as a menu callback would have worked but the absolute link which involved Drupal calling itself from external to the server was blocked by the firewall.

Obviously I could have altered the core code or opened up the firewall so clean URLs worked but that's not advisable for a number of reasons.

I decided the best thing to get clean URLs working without altering anything on the server was to change the variable in the database with the following:

update variable set value = 'i:1;' where name = 'clean_url';

URLs were clean, the site wasn't broken, one step closer to site release.

Good Morning,

I have noticed through a whois query that you are the administrative contact for the adammalone.com domain. I've also noticed that the domain is not currently being used. I am just emailing to query the possibility of negotiating a domain transfer at some point in the future.

Many Thanks,
Adam Malone

It should be noted that the email also contained my Australian telephone numbers and my .net email address as a standard footer.

I received a prompt reply asking whether I'd like to point the domain at http://malonelaw.com or some other site. What had occurred instantly became obvious to me as I remembered an incident that occurred a few years ago when I first got onto the internet and decided to google my own name. It revealed that somewhere in the world was a lawyer namesake. Being a mischievous scamp I decided to email the guy and pretty much say "We have the same name". To which he responded with an email along the lines of "You must be a pretty cool guy then."

Clearly he owned the .com address and the administrative contact thought I was him (as we share the same name and thus by definition are pretty cool guys). After thinking for all of 13 seconds about whether I should continue the charade and have him point it at the IP of my server, I considered it a bad move to attempt to take, by subterfuge, a lawyer's property.

I let the contact know the small error to which he seemed thankful and went on my way. A couple of days later, the .com domain was pointing towards the law site.

Thus ends an uneventful story where I could have had the pleasure of my name's .com but didn't because nobody really wants to get into fisticuffs with a lawyer; wherever the balance of truth and law are.

Where web services fail

Any task that could affect the user's experience on the website due to latency as a result of the web service call is undesireable. With the possibility of users or content being stored externally and relying on web services to store data or verify user credentials, there would be a few key hooks upon which the user could notice slow down:

• User login - hook_user_login
• User save - hook_user_update/hook_user_insert/hook_user_presave
• Comment creation - hook_comment_insert
• Node creation - hook_node_insert

Taking the example of updating an external database with node details every time a node is inserted and assuming a slow connection taking perhaps 10 seconds per node. Clicking save on the node page would provide the author with 10 seconds of painful waiting. An alternative to running on each node insert would of course be to make the database transactions occur on cron.

The default cron time limit is 240 seconds (4 minutes), which in our hypothetical situation allows for 24 nodes to be updated externally (provided no other cron tasks need to run). What happens if we have 30 nodes that are required to be updated?

Cron will time out and won't run fully.

Now, taking the example of user login to either authenticate credentials or update user profiles. Having to query, and wait for a slow web services call has the potential of diminishing user experience. Even though any services provided are supposed to be always on, there is a positive, non-zero probability that it will be unavailable eventually, however good the SLA.

Do users simply get denied authentication or details not get updated?

The Queue API

A much underrated and less well known Drupal API is the Queue API.

The queue system allows placing items in a queue and processing them later. The system tries to ensure that only one consumer can process an item.

By putting all of the tasks we need to process into a queue and working through them one by one we can ensure they all get taken care of and cron doesn't time out. This means that any hook_cron implementations that we expect to take a really long time can be put into Queue and will be processed.

Thinking outside Drupal

Although Drupal is, of course, the answer to all life's problems. Sometimes it just isn't.

It can be tempting to think of Drupal as the hammer to every single nail-like problem. Sometimes for cases with huge computational requirements it's best to keep Drupal completely out of the picture. In our example of user details being managed outside of Drupal and updated every time a user logs in. A better method may be to write a script to transfer data from the target server to the Drupal server. After which, it may be imported into a database table and processed by Drupal. Alternatively, the script may directly update the Drupal database.

Not only does this cut down any latency caused by data transfer, but in the case of the web service being inaccessible, data is available locally. When service resumes, the updates too will resume and users may continue logging in regardless of external downtime.

These are but two ways of thinking outside Drupal. There are numerous other novel ways to work with/around Drupal and web services. It's just up to the site administrator to find the best way that suits the problem at hand.

Fast forward four weeks and I started to wonder at what point a welcome is overstayed.

Open Discussion

Due to the nature of the friendship the overstayed welcome was discussed and the unavoidable predicament of having to reside with me whilst searching for their own place made it easier to extend my welcome rather than rescind it. A welcome, we found, is variable to cirucmstance and not a set value.

Trading Welcome

Perhaps welcomes are comparable to karma and could be a tradeable commodity. With Ⱳ being my new international symbol for welcome, I feel there could be an excellent system, albeit honour bound and based, for people to track their welcome (Ⱳ) and ensure they do not overstay it.  Welcome (Ⱳ) may be curried by enduring someone overstaying their welcome and lost by overstaying yourself. I might even allow the ability to incur welcome (Ⱳ) debt provided it is paid off promptly.

With this in mind I can only imagine how much of a welcome (Ⱳ) millionaire I am right now.

Welcome Repaid

With an incurred welcome (Ⱳ) debt subsequent to moving out, my venerable houseguest has accepted his fate and offered me indefinate stay at his current place of residence should I require it. I feel the most appropriate course of action is to incrementally spend my welcome (Ⱳ) until he and I are square, repaid, all debts settled.

Saturday

The first sprint day saw myself, petercook and rli starting early at 9am with jrsinclair and a colleague arriving a little later. We were some of the first in the world to start sprinting as our position in the river of time is more advanced due to geographic location; in other words 'woo timezones'.

Although the fact that I organised the sprint meant that I was mentoring some of the newer contributors and ensuring sufficient levels of caffeine, I managed to rattle off a patch to this issue to convert user signatures into their own field. It'll require a reroll in the near future after some changes to how the user entity is displayed in comments/nodes however. petercook started off the weekend strong with a comprehensive test of this issue in MySQL, PostgreSQL and SQLite before adding his own additional documentation and rli tracked down and reported a new bug existing when translations and multilingual were enabled.

Numbers dwindled and we officially finished around 5pm. I decided to pursue some further issues and left the building towards 9pm after a brief hangout with John Heaven and the team at Comm-Press and Berdir.

Sunday

Another day another sprint and rooby, petercook and I sprinted until late again. I decided to take time off core to focus on some of my conributed modules. Poll needed a few changes to make it compatible with the latest Drupal 8 changes. I therefore spent the day both helping out other issues, triaging Poll and fixing some of its issues. The other guys got on with their own issues and we finished late again.

Overall it was great fun to sprint with other Drupalers and something I'd be keen on doing again with more of the DrupalACT community!

Although I have attended a number of local Drupal events and camps, this was a little different. Not least because it's the first DrupalCon in the Southern Hemisphere, the first in APAC and of course the first in Australia, but  also because it had a distinctly global feel. Swathes of people from all over the world attended, shared their ideas and tweeted up a storm.

Much in the same vein as Drupal Downunder 2012 in Melbourne, subsequent to the event I'm even more bouyed up and immersed in the Drupal community. Being surrounded by so many like minded Drupal people who share both similar interests and experiences is an invigorating experience to say the least!

So what now?

With all of this additional energy, I will be volunteering my time for the next DrupalCamp Canberra and DrupalACT. My next public contribution will be at the DrupalACT March meetup where I'll be presenting on Drupal distributions, a topic I've been interested in for a while. The full write up of distributions, how they work and best practices will be available shortly after the 14th March so until then; anticipation!

This is the reason my bitbucket profile appears so empty; everything is private.

Enter GitHub

Since I actually do an amount of personal work outside of Drupal, I can't place all the fun things I make on drupal.org, much to my dismay. However, GitHub allows me a place random Perl/Bash snippets as well as entire non-Drupal projects. Since  lot of people lend credence to a developer's experience if they have:

• A drupal.org profile
• A GitHub profile

I feel it's only logical for me to follow suit with everyone else. Seeing also, as I'm an advocate of open source, Drupal and sharing (it's how I learned) I've created a GitHub account to which I'll push work I've done that's fit for public consumption and snippets (Gists) in the hope others will be able to benefit from my work!

There are still some semi-private repos on bitbucket that need some love before GitHub can have them but until then enjoy some of the things I've placed on there already and I invite everybody to fork me!

But what happens when, for whatever reason, you want to move that site away and stop it from being a subsite.

Subsites can use modules and themes from a number of directories. In the same way that a standard Drupal install may use modules and themes from the module and theme directories under sites/all and sites/default/. So too, the subsite may use modules and themes from both the all folder as well as its own subsite folder as detailed in the image.

We must therefore ensure that both shared resources (such as those taken from sites/all) and subsite only resources (sites/mysubsite in the image) are copied to the new single site. Before doing any file or database altering it is strongly advised to backup your filesystem and database!

1. In your new single site directory grab the latest version of Drupal or use drush dl drupal if you have drush installed
2. Ensure modules and themes from both sites/all and sites/subsite folder are moved into the sites/all directory within the new single site directory.
3. Take the sites/subsite/files directory and move it to sites/adammalone/files in the new directory.
4. If you have modules using libraries stored in sites/all/libraries, be sure to copy the libraries to the new single site directory.
5. Move sites/subsite/settings.php to sites/default/settings.php in the new directory

This handles all changes and movements in the filesystem. Since Drupal utilises a database to store the majority of its settings we must make a couple of amendments there too.

Drupal 7 introduced the code registry whereby the location of files can be stored and only loaded when needed rather than on every page request. The system table stores filenames and other details about modules in a Drupal site, the registry table stores filenames, names of classes/interfaces and which module the class/interface belongs to, the registry_file table stores the name of the file and a hash of the file to ensure the data is up to date. Because as a subsite the database would store filenames thus:

We must ensure that the new site has the filename field altered to the new filename location for all three of the system, registry and registry_file tables. The difference in the database can be seen here.

Since going through things manually is dog work we can use a couple of SQL queries to alter everything for us.

1. Connect to the database by typing mysql -uUSERNAME -pPASSWORD -DDATABASENAME or navigate to the new site directory and type drush sqlc.
2. Run the following queries substituting in the correct directory:

UPDATE system SET filename = REPLACE(filename, 'sites/mysubsite/modules', 'sites/all/modules');
UPDATE registry SET filename = REPLACE(filename, 'sites/mysubsite/modules', 'sites/all/modules');
UPDATE registry_file SET filename = REPLACE(filename, 'sites/mysubsite/modules', 'sites/all/modules');

1. Clear your cache with drush cc all (At this point you may need to manually clear cache tables.)
2. Finally change your filesystem path(s) from sites/mysubsite/files to sites/adammalone/files.

You may need to alter some DNS or apache settings to reflect the changes but after following the above instructions there is nothing more in Drupal to be done!