Version Control Systems

I used to use Clearcase and CVS for version control "back in the day" (way back in the day actually).

Some shops use Subversion now, which is referred to these days in the era of shortcuts and short attention spans, as SVN.

This link here - an analysis - shows some differences between CVS and SVN compared:
http://www.pushok.com/software/svn-vscvs.html


Moving on to GIT, here is a link where fundamental differences between GIT and SVN are discussed.

http://boxysystems.com/index.php/5-fundamental-differences-between-git-svn/

It's been a long time since I have done version control, or had a need to. So this is some information that can be helpful to get back "up to speed".

The TTY Demystified - great article

Great background article. Interesting for anyone who wants to know the history.

http://www.linusakesson.net/programming/tty/

Some more interesting discussions.

https://news.ycombinator.com/item?id=10631513

Strict, Moderate, Open NAT

This came up yesterday. We'll take a note on the distinctions.

http://serverfault.com/questions/208522/what-is-strict-moderate-and-open-nat

DD-WRT

I spent some time today dissecting DD-WRT, which is an open source operating system used on many routers and embedded devices (that use Wireless technologies, especially 802.x).

Looks like it uses BusyBox for most of the binaries. BusyBox appears to be a single binary that can run many of the GNU / POSIX unix/linux-descended binaries. It's supposed to be more compact. For example, options have been stripped away or replaced on many of the binaries in the name of compact simplified code (lower footprint).  It is open source, so one can download, inspect, compile, etc.

For ssh, it uses something called DropBear. Again, a compact ssh server.

The webserver, httpd, looks to be an in-house developed web server (meaning, written by developers of dd-wrt). Chillispot is the access point controller.  ttraff is used as the traffic counter. dnsmasq is used as the DHCP server on the box.

All in all, the box looked very tight - with 40M used of 256M,

In some ways interesting, in other ways, uninteresting - which is a good thing for embedded devices.

Windows 10 Chatter

I wanted to take some time to do some forensic analysis on my router (this is another blog entirely).

One of the things I noticed, was how busy the router was.

Well, hey. It's a busy house. And the whole family is here this weekend, all streaming NetFlix on phones, laptops, et al.

But - I noticed an inordinate amount of traffic from one PC.

Upon doing some further investigation, using packet sniffing tools, Task Manager, et al. I realized that Microsoft was calling home for a number of reasons.

I should have looked into this more when I bought this PC, but got busy. Shame on me.  I saw all kinds of things, and starting shutting down services, etc. Finally, I after shutting down so many things, and continuing to see packets flowing, I went out to the web and found this link - which is reasonable recent.

http://arstechnica.com/information-technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-microsoft/?comments=1

I also read the comments, and wound up installing DisableWinTracking. I downloaded the source code first (as a tar file), and looked it over. Deciding it looked clean, I went ahead and ran the program, which is a series of powershell scripts that disable the tracking. There's a considerable amount of it. I un-installed all of the Microsoft apps listed, and disabled the services (I did not delete them - just disabled them). You have to be a little worried about shutting off your security updates on Windows 10, which is something I will need to monitor.  But a lot of that crap, I agreed with and decided was not really in my interests at all, and in fact was sucking up bandwidth and tying up an already-busy router.

Now, I'll go back and start looking at traffic again.

Firewall HA with conntrackd and keepalived

As we are doing some keepalived work, and looking at groups of IPs, I came across a couple of links worth mentioning:

This link below shows an approach of using a vrrp_sync group for an internal and external network. This is very much along the lines of what we were thinking we wanted to achieve and it was nice to see reassurance that we might be using a sync group as it is intended to be used (given the dirth of use-case documentation on this).

http://manpages.ubuntu.com/manpages/precise/man5/keepalived.conf.5.html

Another link is this one below.

Up to this point I have only been testing the VIP assignment and reassignment by pulling cables and making firewall adjustments (to make sure the VRRP could get through the firewall).

This link below has me concerned that true client testing might (will?) fail. Because indeed, Firewalld and iptables on Linux are, indeed, stateful firewalls. So I may need this link to bail me out.

http://backreference.org/2013/04/03/firewall-ha-with-conntrackd-and-keepalived/

VRRP Testing Round 3

Today, tested the concept of a Synch Group.

Used the configuration (essentially) from this ubuntu manpage.
http://manpages.ubuntu.com/manpages/precise/man5/keepalived.conf.5.html

Worked very well on VirtualBox, where we connected and disconnected virtual cables and watched the IPs move, in tandem.

Using just two instances if you disconnect one interface on each, VRRP considers itself in a complete fault state and neither box gets a virtual IP on either interface - which is what you want if it's a synch group.

Pretty happy with this testing.

BTW...another site I found had some decent comments about some options:
https://linux.die.net/man/5/keepalived.conf