How things get restored in Google Drive after a big delete

Imagine this:

– You have a Google Drive folder that’s receiving daily builds. This means the previous day’s build gets deleted.

– Then one day you delete the folder accidentally. You know Google Drive keeps backups of everything, so you just go in to your Google Drive trash, find the folder and then right-click > Restore.

Well, you get your stuff back, that’s for sure. All of it. All of the files that had ever been in that folder. Heh. And it takes a good several hours for them all to eventually show up, and they appear gradually over that time.

Now, how many people are syncing the folder? Hah. Full hard disks a-plenty. You kind of have to just sit there refreshing the web view of the folder, deleting all the old files.

Really, I’d recommend creating a new folder and selectively restoring the specific files you need. That should be a much faster solution. Now if you have apps or something pointed at the URL of the actual folder, then, well, you’ve got a long day ahead of you. Just keep deleting the files as they show up. It’ll work.

Robocopy can’t find the path when run via TeamCity Agent

You have a network share mapped as a drive and you want your TeamCity Agent to copy files to it when it’s done building. But it doesn’t work. Your users are fine (run “whoami” in TeamCity script and look at the output to make sure).

In the TeamCity build logs you’ll see something like this:
ERROR 3 (0x00000003) Getting File System Type of Destination

The annoying part is that it works just fine when you run it via the command prompt.

In short, the issue is likely that when Robocopy doesn’t use the interactive user session, so even if you’re logged in with the user under which the TeamCityAgent service is running, and you have the network drive mapped just fine, Robocopy won’t be able to see it. So, you could put a “net use” command just before your robocopy command, but then you’ll have to remove it again afterwards, which would be prone to failure… though maybe remove-then-add just before? Anyways, just point it directly at the network share for your robocopy command. That way, you only have to make sure your TeamCityAgent user has permissions on the network share.

l2tp support in Ubuntu 16

Here’s the best step-by-step:

L2TP / IPSEC VPN on Ubuntu 16.04

Here’s another step-by-step that had some mismatched text strings that kind of wrecked stuff:

Meraki doesn’t have much in the way of documentation on setting up the client VPN on Linux servers. They have something for a Linux distro running a GUI:

Here is something about gettig the l2tp vpn client to work in a clean way on a Linux GUI. Again, not applicable for pure Linux servers though:

Here’s my step-by-step that works on a fresh Ubuntu 16 install and pointed at a Cisco Meraki MX64. It includes a means of keeping the connection alive by using the monit utility:

Install the packages we will need
You’ll have to sudo up to root to install all this stuff

apt-get update
apt-get install -y strongswan xl2tpd

Configure strongswan
Note: this “cat >…..” method replaces the file with the contents that follow. You can kind of script the whole config part that way

cat > /etc/ipsec.conf <

Configure the preshared key
Note: you could just edit the file, so we don’t have the shared key sitting in a Google doc history
In that case, just add a line in/etc/ipsec.secrets that says:
nano /etc/ipsec.secrets
: PSK “pskgoeshere”
You may have to redo the double-quotes… google docs tries to be helpful
And, yes, that colon at the beginning of the line is necessary

cat > /etc/ipsec.secrets < /etc/xl2tpd/xl2tpd.conf <
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes

cat > /etc/ppp/options.l2tpd.client < ” > /var/run/xl2tpd/l2tp-control
Redo the double-quotes. Google docs screws these up bad

How to [un]format the Google Docs "Smart Quotes" italicized quotes

When this works you should see a new interface when you look at the local routing table
route -n
The first one resolves DNS; the second doesn’t
You should see something like this:

Notice the middle one, and on the right-most column is has “ppp0″…. That’s what you want.
If you don’t see it, wait 5-10 seconds and check again, then rerun that above “echo…..” command again.

When this works, you should see another connection in ifconfig
You should see something like this:

Notice the “ppp0” connection. It’s not there until after you run that above “echo…..” command. This is the actual VPN connection

Set up a route so we actually use the VPN interface
A few steps here, and I’ll show things with what I actually saw
The goal is to set a route that sends all traffic destined for addresses through the VPN connection.

Get the IP address of the local VPN interface
You need to get the IP address listed right after “P-t-P” in the “ppp0” interface

Add the route
route add -net gw
This makes the OS send all network traffic destined for any IP that starts with “10.x.x.x” through the interface, which means it goes through the VPN tunnel and to the Meraki VPN server, which then routes it as needed.

Disconnect the VPN
echo “d meraki-vpn” > /var/run/xl2tpd/l2tp-control
ipsec down meraki-vpn

Connect the VPN
ipsec up meraki-vpn
echo “c meraki-vpn ” > /var/run/xl2tpd/l2tp-control

Making sure the VPN connection stays active
Latest: monit seems to be a viable means of making sure the vpn connection is stable.

Install monit
apt install monit

Create a config file aimed at monitoring our VPN connection
nano /etc/monit/conf.d/monitor_vpn
In there use the following:
check network ppp0 with interface ppp0
start program = “/bin/bash -c ‘/p4proxy_bh/'”
stop program = “/bin/bash -c ‘/p4proxy_bh/'”
if failed link then restart

Create the referenced scripts
nano /p4proxy_bh/
ipsec up meraki-vpn
sleep 5
echo “c meraki-vpn ” > /var/run/xl2tpd/l2tp-control
sleep 5
route add -net gw

nano /p4proxy_bh/
echo “d meraki-vpn” > /var/run/xl2tpd/l2tp-control
sleep 5
ipsec down meraki-vpn
sleep 5
route delete -net gw

What this does:
The first “ppp0” in that monit config file is actually the name of the monitor…you could name it anything (used with “monit start ppp0” to manually run the monitor)
It’s saying if there is no interface by the name of “ppp0”, as would be the case when the VPN connection is down, then “restart”… in monit terms, “restart” = run the “stop program” and then the “start program” specs. It then also sets the route, just in case.

Monit wakes up and runs all the configured monitors every 2 minutes

monit status
Shows the last result of each monitor
This worked to successfully and easily detect that the VPN tunnel interface was down and automatically restart it.

Biggest Fail
All the “meraki-vpn” strings refer to each other. Some guides had inconsistent string names. The “conn” name and the “[Lac]” had to use the same string, in this case “meraki-vpn”.
Google Docs changes double quotes to fancy italicized ones, and when copied and pasted into a Linux terminal, they are technically *not* double-quotes, so your commands fail in all kinds of fun and interesting ways. Disable it:
There is a package you can now install that makes l2tp stuff much easier on Ubuntu desktop-with-a-GUI, but that won’t really work on command-line-only servers.

Here’s a message seen in “journalctl -xe” when nothing happens when you try to start the l2tp part (the “echo c….” command):
Aug 23 09:42:09 vpntest charon[1296]: 02[NET] sending packet: from[4500] to xxxxxxxxxx[4500] (60 bytes)
Aug 23 09:42:14 vpntest xl2tpd[1702]: Maximum retries exceeded for tunnel 3074. Closing.
Aug 23 09:42:14 vpntest xl2tpd[1702]: Connection 0 closed to xxxxxxxxx, port 1701 (Timeout)
Aug 23 09:42:19 vpntest xl2tpd[1702]: Unable to deliver closing message for tunnel 3074. Destroying anyway.
Aug 23 09:42:38 vpntest charon[1296]: 15[IKE] sending keep alive to xxxxxxxxxxx[4500]

A reboot of the VPN server on the MX64 resolved this.

Helpful debugging commands to use on the client
journalctl -xe
“Charon” messages are from ipsec (strongswan)
“Xl2tpd” messages are from xl2tp

/usr/sbin/xl2tpd -D
Can show xl2tpd-specific things

Background a long-running Linux task

Background a shell command that’s taking forever to complete, and you don’t want to open up a new ssh session to the host:


Pretty useful, especially if you’re manually running something like a backup process that takes a long time that, if you were to just close the ssh session, would just stop in some unknown state of incompletitude.

VmWare the operation is not allowed in the current state

I had tried to put a host into maintenance mode so I could reboot it. But it seemed to get hung up, but I didn’t see any outstanding tasks, so I just rebooted it. After it came back up, things seemed alright, and I started up the various VMs on it. Later, I started a migration task to change the storage of one of the VMs on that host. At the very end it said “the operation is not allowed in the current state” and failed. It happened again when I tried to deploy an ovf template to that host.

This post from VmWare gave a number of things to try. For me, it was disconnecting the host from vCenter and then reconnecting it (all right-click operations, so it was easy and quick). When it reconnected, the host was shown to be in maintenance mode, which was not the case before disconnecting and reconnecting it. Things seem happy now.

Running a different Perforce version with p4dctl than the latest (16.1 or whatever)

If you want to run Perforce with p4dctl since it’s so handy, but you only have a license for some older version of Perforce, here’s how you can have p4dctl point at that version:

Put the p4d binary into /opt/perforce/sbin/ and name it something descriptive for its version, like “p4d.2012.1”

Change the symbolic link in /etc/alternatives/helix-p4d to point at that instead of the p4d version that installed:

rm /etc/alternatives/helix-p4d
ln -s /opt/perforce/sbin/p4d.2012.1 /etc/alternatives/helix-p4d

Done. You’ve just swapped out the version of p4d that p4dctl uses. But, this is global for the entire machine, so it’s something to consider. I think it’ll auto-upgrade an existing p4 instance, but it can’t go backwards to lder versions, just to mention that. You’ll get weird errors.

Easiest Way to Run Perforce

Install Perforce according to this:

Then run the configure script mentioned in what comes out after the installer ran.

That script essentially just sets up a .conf file in /etc/perforce/p4dctl.conf.d/

You can edit that thing directly or add another one if you want to have another perforce instance running on the same machine.

Note: you cannot use p4dctl with replication, as best as I can tell – it clobbers any “p4 configure” things that may have been set in the master-configured stuff ro the replica.

Start and Stop all perforce instanced mentioned in /etc/perforce/p4dctl.conf.d/:
p4dctl start -a

p4dctl stop -a