Derek Neely

...notes for thyself, but useful for all...

Transferring Google Compute Engine (GCE) instance to another project


Jan 17, 2017 by derek

On the Google Cloud Platform (GCP) there's no straight forward way to move a server from one project to another. We've been cleaning up and organizing some of our servers into their relative projects as they grow. This includes projects we own as well as moving some of the systems over to projects owned by the relative clients. While moving a server from one project to another isn't very straight forward its really not that hard to do. Only caveat is that you'll lose the IP of the current server. But, with this solution you're able to keep the current server up and running, stand up an identical machine in the new project, then all you need to do is cutover the DNS. Ready?

  1. Create a snapshot of the server you want to move
  2. Create a new disk from this snapshot
  3. Create an image from this disk (images can only be created from a disk that is not attached to an instance)
  4. Jump on over to the new project and create an instance from the image you created.

Done and done!

Google Compute Engine (GCE), Google Cloud Platform, System Administration, Cloud

Prevent Postfix from sending root email outbound


Jan 13, 2017 by derek

We recently noticed an issue where Postfix was sending our system's root emails outbound to root@ourhost.com. Our mail relay was not delivering these, but they should have been delivered locally and not going out of the system in the first place. The issue had to do with the fact that our server's Postfix was configured with:

myorigin = myhost.com

All in all this was a quick fix to handle. Just need to add a new config directive. Add the config file and enable it.

Edit /etc/postfix/main.cf and add the following line (I added mine just below the other 'alias' configs):

virtual_alias_maps = hash:/etc/postfix/virtual

Now, edit this file we're referencing (/etc/postfix/virtual) and add the following line:

root     root@localhost

Run postmap on this file:

$ postmap /etc/postfix/virtual

Then for good measure, bounce Postfix:

$ service postfix restart

Golang with AngularJS 2 using Gin (Updated)


Jan 10, 2017 by derek

As of late I've been trying to learn/vet some new technologies to stay up to date with what all is going on. I don't like being behind the curve on things, but I also don't like to jump on every tech bandwagon that comes along. Family, company, and other hobbies don't lend a lot of time for all of that. I also like to watch and let them marinate a bit and see what sticks around and what doesn't. I know Golang is not new, nor is AngularJS. They've proven to be solid, powerful tools and now I've set out to learn and use them in my project(s).

I've been playing with Golang for a bit now, using it for APIs on some simpler apps on the mobile side. During early development, a buddy of mine showed me Gin (a HTTP web framework - a really, really fast one by the way). Being early on in my development/learning I concluded to switch over from the standard net/http lib and then from Gorilla mux. I re-worked my code (not a lot involved there) and have been off to the races since. The API, also using Google's datastore, and the iOS app are just about done. But I still have more to do here as I'm also going to wrap this app into Docker containers and a swarm (again for some additional know how). Anyhow, I wanted to take a small break from these. Once you get comfortable with one thing its time to learn something new...right? So, I wanted to try and re-build an interest in web development. Particularly a web app for this same experimental project of mine. So, I'm picking up some AngularJS.

Long story short, I wanted to package my Golang APIs (backend) with a rich web application framework all in one nice little bundle. Yea, yea, yea, I could have had one system serve the static AngularJS stuff and another running the Golang APIs, but I just didn't want to. I wanted to stack it all together...for whatever reason.

So, here is how I went about doing it. Only showing the solution here and not the hours of trial and error. The overall issue I was having with Gin was serving a Restful API (particularly the GET request) but also serving AngularJS files as the root of the site which are also GET requests. The mapping of "/" at first was conflicting with the "/api/lists" GET request because with Gin (or at least how I was orignally trying to map the routes) GET "/PATH/TO/GO/ROUTE" routed back to "/" so was getting a conflicting route on some tries and 404s on other attempts. The final solution is dirt simple (despite the hours of hair pulling and googling to get here)

Site/app directory structure:

project_name
| - main.go
| - ng
    | - [AngularJS Files]

main.go

package main

import (
    "log"

    "github.com/gin-contrib/static"
    "gopkg.in/gin-gonic/gin.v1"
)

func main() {
    router := gin.New()

    router.Use(gin.Logger())
    router.Use(gin.Recovery())

    router.Use(static.Serve("/", static.LocalFile("./ng", true)))
    router.LoadHTMLGlob("ng/*.html")

    // ** See update below 
    ng := router.Group("/", Index)
    {
        ng.GET("/")
        ng.GET("ngRoute1")
        ng.GET("ngRoute2")
        // ... Additional Angular routes here ...
    }
	
    api := router.Group("/api")
    api.Use(AuthAPI)
    api.GET("/lists", GetLists)        
	
    router.Run(":8080")
}

func Index(c *gin.Context) {
    c.HTML(200, "index.html", gin.H{})
}

func AuthAPI(c *gin.Context) {
    log.Print("AuthApi - Validate some headers/tokens, etc.")
    return
}

func GetLists(c *gin.Context) {
    listContent := map[string]interface{}{
        "status": "success",
        "lists": []string {
            "list 1", 
            "list 2", 
            "list 3", 
            "list 4",},
    }
	
    c.JSON(200, listContent)
}

See? Freakin' simple isn't it? With this I can now have my nice AngularJS site running off the "/" of the site and still serve up some content via the "/api" route with no conflicts (with GET, POST/UPDATE/DELETE were fine as they didn't conflict with the GET of the "/"). 

** UPDATE: Original code 'worked' but had a flaw when it came to handling the AngularJS routes. Patrick Parkins vetted the original code and we were able to sort out the additional code (now added in above) to handle both Golang and AngularJS routing. Thank you PattyP!

Development, AngularJS, Web, Golang
Page 1 of 8 >>>

Social


Tweet Tweet Tweet


© 2016 Derek Neely