Insync: The Powerful Google Drive Client For Linux

Insync

Insync is a very powerful and full featured Google Drive client for Windows, Mac, and Linux. I ran across Insync when I was looking for a Google Drive client for Linux after I kicked Dropbox to the curb and switching over to Google Drive for all my cloud storage needs.

In all honestly, if it wasn’t for the Insync client I do not think that I would have made the switch at all, as Google does not even offer a basic GUI client for Linux. Really Google?

PSA: The integration that Google Drive provides into Google Photos, Google Music, Google Docs, and Gmail is well worth the switch from Dropbox in my opinion, and 1TB for only 9 bucks a month is hard to beat (100GB is only $1.99 a month). Just having a Gmail account gives you access to 15GB of free space… so there is no reason not to give it a try.

Ok now back to the topic at hand.

Note that a personal license of the Insync Google Drive client is not free, rather it costs $15. However you can download and try it risk free and without entering any credit card info. This one time fee for a personal license allows you to run and install Insync on multiple machines. Currently I have it installed on 4 separate Linux workstations/laptops. Its well worth cash.

Installing Insync is very easy and well documented so I am not going to go into that topic here. Rather lets talk about using Insync on Linux.

Continue reading

How to Fix the Buffalo Linkstation NAS – Partition Not Found Error

Buffalo-LinkStation-220-1024x576-e90e950d78fb74df

Recently I picked up a Buffalo Linkstation 220 to play around with at home as I felt that I could use a bit of additional storage to play around with. Note that this previous statement is pretty much a lie. I have tons of storage, and was really just looking for an new toy to play around with. Basically I just had a few disks laying around that I wanted to put to use.

However, much to my dismay the I was unable to configure the device once I shoved in the disks, powered it up, and connected to it with the Buffalo Smart Phone Navigator. I figured that this was not a big deal however, so I tried the installable Windows App from my Windows 7 Vm. The Buffalo NAS Navigator was also able to connect to the device, however the device showed that it was currently booted in what was called “Emergency Mode”. Not sensing a real emergency, I did not panic.

See borrowed image below.

buffalo_unbrick_001

Fortunately the site that I borrowed the above image from (here) and this site (here) give advice on how to fix the issue. First step is to download the Buffalo Linkstation Firmware Updater that you can get here. Both pages advise you to modify the LSUpdater.ini file. However their instructions did not work for me. The exact changes, and the LSUpdater.ini in its entirety are below.


[Application]
Title = BUFFALO LinkStation Series Updater Ver.1.62
WaitReboot = 1200
WaitFormat = 600
WaitFileSend = 600
WaitDiscover = 120

[Target]
ProductID = 0x80000000
ProductID2 = 0x0000001D
ProductID3 = 0x0000300D
ProductID4 = 0x0000300E
ProductID5 = 0x00003011

Name = LinkStation

[Flags]
VersionCheck = 0
NoFormatting = 0

[SpecialFlags]
Debug = 1

At this point you launch the updater again, and select “Update“. This fully partitions the drives and then updates the firmware. This process takes a while, so be patient. Now you can launch the NAS Navigator and configure the device.

How to Remove Deactivated or Invalid Nodes from Puppet Enterprise via the CLI

puppet-logo

Apparently just deleting a Puppet node from the Puppet Enterprise Console does not actually delete the node from the Puppet database, and free up a licenses… or at least in my case it did not. I ran into this issue tonight after removing a few of my test boxes in preparation of building a new node that I wanted to ensure was properly managed via Puppet.

As many of you know when running the free version of Puppet Enterprise you are limited to 10 managed nodes. In my Lab I am actually running only 7 nodes, however over the past few months, I have build several test VMs as part of testing my Centos 6 kickstart and Puppet bootstrap scripts. However even after deleting these nodes manually from the WebUI I noticed that I was not freeing up any licenses.

Below is the process that I had to run to manually remove nodes from my PuppetDB. First lets list all managed VMs and look for nodes that we know do not exist any more.

[root@puppet puppet]# puppet cert list -all

+ “batman.localdomain” (SHA256) 4C:76:04:38:CE:D3:4A:E0:C9:2A:C8:E6:BB:4A:92:0C:6B:39:D9:4B:7C:E4:D1:9D:0F:E2:06:FD:97:CC:72:AF
+ “robin.localdomain” (SHA256) A9:08:E8:09:B6:68:65:81:92:FC:82:93:DB:83:82:D9:A5:A2:EB:6D:DD:6E:C5:F0:45:55:A5:39:47:DB:A1:27

In the example above, I found two test VMs… Batman and Robin, which I know are no longer valid, so lets remove them and free up a couple of licenses.

[root@puppet puppet]# puppet node deactivate robin.localdomain
Submitted ‘deactivate node’ for robin.localdomain with UUID 54267132-1c23-4cf7-96f4-d6f3ff13a684

[root@puppet puppet]# puppet node deactivate batman.localdomain
Submitted ‘deactivate node’ for batman.localdomain with UUID 160d9f7c-734c-4830-8faa-23f331218b90

Once you have set the node to deactivate, lets clean out the certs.. rinse and repeat for each node to delete.

[root@puppet puppet]# puppet node clean batman.localdomain
Notice: Revoked certificate with serial 17
Notice: Removing file Puppet::SSL::Certificate batman.localdomain at ‘/etc/puppetlabs/puppet/ssl/ca/signed/batman.localdomain.pem’
batman.localdomain

Now when we return to the WebUI we should have two free licenses and can add new managed nodes without issue. Note that according to puppet themselves “that in some cases, the PE license count in the console will not decrease for up to 24 hours, but you can restart the pe-memcached service to update the license count sooner”

HomeLab: How to Resolve Supermicro x8dti Fan Revving Issues

Supermicro-Hyper-Speed-6027AX-TRF-Front-Straight

Its Winter here in the Atlanta area, and the temperatures have been dropping down close to freezing. Likewise, the temperatures in my basement Homelab have been dipping below 66 degrees Fahrenheit, and apparently this makes my Supermicro Servers a bit unhappy.

A bit of background. When I set out to build my lab I decided to transfer my Supermicro X8DTI boards out of their stock rack mount enclosures (like what you see above) and into Standard EATX Towers. Running my boards in these towers allowed me to use large 120mm and 140mm fans for cooling. Sound wise this is a huge improvement over the stock 80mm fans used in the default enclosure as these larger fans can spin much slower than stock and still keep the system cool.

On several occasions I have been working in my office and have heard the fans in my lab servers revving up and back down again. At first I thought that maybe a fan was failing, and that one of my systems was overheating. Or that one of my systems had sucked in a bit too much basement dirt and dust. However neither were the case.

Specifically what was happening was this… The systems were running cool, so the fans would spin down to a low rpm and the system would then throw a low rpm threshold alert and spin the fan back up.When this occurs the system switches into some sort of “Critical Cooling Mode” and spins all the fans up to 100% for a few seconds. Rinse and repeat a few dozen times and you hear what almost sounds like an intoxicated neighbor playing with his new weedeater.

Using the IPMIitool command from my Linux desktop first logged into IPMI controller on my systems and checked to make sure that the fans were actually working properly. SDR is short for Sensor Data Repository

# ipmitool -H 10.1.0.104 -U admin -P <password> sdr list
Fan2 | 2176 RPM | ok
Fan3 | 340 RPM | ok
Fan4 | no reading | ns
Fan5 | 544 RPM | ok
Fan6 | 340 RPM | ok
…truncated…

Fan6 above is spinning mighty slow. Slow enough to drop below the Lower Non-Critical Value threshold. Rather than increase the speed of the fan as I have seen others do, I decided to lower the thresholds for this fan with the command below. Since Fan5 is also a bigun’ I decided to preemptively adjust its thresholds as well.

ipmitool -H 10.1.0.104 -U admin -P <password> sensor thres Fan4 lower 100 200 300
ipmitool -H 10.1.0.104 -U admin -P <password> sensor thres Fan5 lower 100 200 300

How to Add Users via the CLI to a Thinklogical Secure Console Server

7050Since the Thinklogical Secure Console Server is running a variation of RedHat Linux, it is very tempting to try to add users via the command line using the useradd command as you normally would on a Linux machine. Please note that you probably do not want to do this for several reasons.

First off your users will be unable to connect to any serial ports and possibly be unable to log into the webUI at all.

So here is the first thing you need to know about adding users or changing passwords on the command line. Do not create any passwords over 10 characters. Do this, and your users will be unable to log into the webUI.

Even worse, do this to your root account, and you have now locked yourself out of the web interface.

Second thing to note is that if you use the useradd command your new user will not be have the correct permissions to connect to any of the managed serial ports.

Instead, Thinklogical has created a wrapper script for useradd, called adduser. This custom command creates your user and adds it to the proper groups and required configuration file. When added properly each user ends up with their own config file in /etc/lsi/conf.

In this example I created a user named “admin” using the add user command. In order to connect to serial ports you must be a member of the “scsusers” group. To monitor (or view) other user’s active connections, your user will need to be a member of the “monitor” group. Below you can see my new user’s group memberships.

[root@scs config]# id admin

uid=500(admin) gid=701(scsusers) groups=701(scsusers),702(monitor)

Now even though my user id a member of the correct groups, I still need the a config file in /etc/lsi/conf. Since my userid is admin, my config file will be /etc/lsi/conf/admin.conf.

ESCAPE_SEQ=&quot;\x1bA&quot;
BREAK_SEQ=&quot;\x1bB&quot;
ALLOW_CLEAR=1-48
ALLOW_CONNECT=1-48
ALLOW_MONITOR=1-48

Configure Syslog Logging Levels on the Asus RT-AC66U Router


4614_WizardStressToy_1

So here is a quick little one that I figured out the other day. Having just setup a Splunk server at home I wanted to make sure that I was not going to hit the data limit of 500mb a day for the free version of Splunk. I figured out pretty fast that my ASUS RT-AC66U was a very chatty-cathy when it came to syslog… sending me all sorts of very raw data that I was, at least at first, not so sure I was interested in indexing. So I hit the cli and started poking around.

First off, before we jump in, let’s make sure that we are all on the same page. First thing to note is that I am running the custom Merlin firmware, however that doubt that the stock firmware is much different. Second, let’s make sure that we all know how to configure syslog on our Asus.

To setup forwarding syslog to a remote syslog server, you first client on “Administration” in the “Advanced Settings” panel on the left. Then select the “System” tab near the top of the page. Scroll down to “Miscellaneous”. This section is shown below. Enter the IP address of your syslog server (or Splunk server in this case) in the “Remote Log Server” field.

syslog_asus

Now lets get down to the business of adjusting our logging level. First you need to ssh into your router.

Note that it appears that by default the log level is set to 7.

admin@RT-AC66U: # nvram show | grep log_level
log_level=7

Now before you get too excited, I am actually not sure that the main log level adheres to rfc5424. I have yet to find any published documentation from Asus to confirm this. However, according to this guy’s blog, this configuration might be a bit less chatty. Note that there are a few additional settings here which you can play around with. With these settings, I am assuming that 1 is on, and 0 if off. I am still experimenting.

admin@RT-AC66U: # nvram set log_level=2
admin@RT-AC66U: # nvram set log_enable=1
admin@RT-AC66U: # nvram set log_rejected=1
admin@RT-AC66U: # nvram set log_dropped=1
admin@RT-AC66U: # nvram set log_accepted=0

Now lets save our change and reboot

admin@RT-AC66U: # nvram commit
admin@RT-AC66U: # reboot

Note that there also is a vpn_loglevel=3 setting that can be configured via nvram. This setting might be useful to those running a VPN server on their router.

Thinklogical Secure Console Server Super Quick Start Guide

SCS480R_F_B500

Today we are going to dive into how to setup and use Thinklogical’s line of Secure Console Servers. What I like about these devices (available in 8-, 16-, 32-, and 48- port models) is that they are actually running Linux, so the setup and configuration is a breeze via the command line for anyone comfortable on a Redhat based system.

Initial Device Setup and Configuration.

There are two pretty simple ways to connect to your SCS one you have unboxed it and have powered it up.

The first is via IP. The default ip address of the device is 10.9.8.7. So plug one end of an Ethernet cable into a network port on a laptop or desktop. Plug the other end of this same cable into the first network port on the SCS and configure your workstation so that it has an IP address on the same network as the SCS. In my case I set the IP address of my laptop to 10.9.8.8.  No Netmask or Gateway needed when connected directly. This method enabled me to either ssh directly into the device or connect to it via web browser.

The second method is via a serial connection to the SCS’s console port. In this case I fired up minicom (hyperterm or putty will do as well if you are running Windows) and configured it to use /tty/USB0, which is the device number associated with my USB to serial converter. If you have an serial port on your laptop you can skip the USB to serial adapter and just plug right into the serial port on your workstation. This method allows you to login directly to the device’s console. In this scenario,  I used a Cisco console cable to connect the two devices together.

The initial login and password are root/root. It goes without saying that you need to change this password ASAP.

Continue reading