My much-loved NAS from 2015 died quite painfully at the end of 2016, due to the use of the ASRock C2550D4I. This isn’t ASRock’s fault in particular, but more the integrated Intel Avoton C2550 which has some show-stopping issues that are causing problems in everything from Synology storage devices to Cisco routers.
There was very little available in the low-end server market that compared favourably with what I bought, so I ended up splashing out extra for the following:
Situation I recently ran into some issues at work with building some new Mapserver servers we’re building. Using an UbuntuGIS repo we had a perfect Mapserver and GDAL build for 99% of the products we deliver on a day-to-day basis (with greater reliability than our old system) however it GDAL doesn’t handle the proprietary ECW format out of the box. It can be brought in but there is some strict licensing terms and we didn’t want to risk running afoul of them, nor did we want to have to run the arbitrary, closed source blobs in the current ECW SDK version.
So it came to pass, that all hardware was doomed to fail in time for it was crafted by men who were afflicted by the same curse.
My fileserver has served (giggle) me well for the past 4-5 years but it had been showing its age. I had recently had to remove one old drive that had failed and knew at least one other drive had some file sector issues.
While this incarnation of my personal website has been set up and served using only static components for some time, it was still limited to the capabilities of the virtual server it was hosted on. So I finally took the plunge and (along with the ScorpInc website) moved all the files into Amazon Web Services (AWS) various platforms for ultra-responsive static sites and assets. This includes hosting the files in a Simple Storage Service (S3) bucket, pushing DNS through Route 53, and using the CloudFront Content Distribution Network (CDN) service to distribute my site at various edge locations around the world for low-latency response times, regardless of where the request comes from.
If you’re running your own installation of GitLab and you’re suddenly getting a redirect loop when you’re going to the homepage, go directly to the sign-in page (eg: http://gitlab.example.com/users/sign_in) and log in as an account with administrator privileges. From here, go to the settings for the application (in the admin area) and if you have the GitLab install’s homepage in the “Home page url:” box, remove it. Otherwise (not-logged-in) users are visiting the home page which is telling them to go to the homepage which is telling them to go to the homepage, etc.
Herein you shalt find the hardware that currently (+/- time) acts as the base for the various parts of my life that require servers not provided by places of work and/or education.
A new year has landed and already it’s first month has left those remaining with the cheque. In keeping with my capricious nature, I am often struck with the need to re-do my setup of local and remote servers/hosting. One of those times is now upon me and I’ll likely use this post to document the happenings.
Remote Setup My existing remote setup consisted of a $20/month DigitalOcean instance (snowy-old) running most services, a $10/month instance for a friend’s static site and another $10/month instance designated for use by two projects on which I volunteer.
I got to spend some time this weekend setting up a mailserver for my personal domain (adamogrady.id.au) and thought I’d jot down some points on this blog. In particular my mail setup uses a Postfix MTA that forward emails from all addresses to a single user, stores messages in the Maildir format and forwards a copy of everything to my Gmail account (which I use for the web interface and which has been my primary address for some time).
As part of a re-hash of my home servers and development environment, I’m focusing on containerised app/software installation in server environment. In particularly I’ll be focusing on Vagrant for the setup and configuration of quick dev environments and Docker for running software securely in it’s own containers.
Below you should find a short list of the steps required to set up a server with Docker, install Gitlab, PostgreSQL for storage, Redis for caching, and nginx as a reverse proxy to serve requests to your Gitlab instance.
I’m sorry Ops blog, I know I’ve been neglecting you lately. It’s just I haven’t had many projects recently that would fit in with this blog or be worthwhile making a post about. However that’s changed a bit since the past weekend.
Although I’ve been preparing for and busy with a new job, I found some time to develop a small journal-keeping project that I’ve aptly named re:mind Journal that’s properly available online in all it’s glory.