Want to be able to select multiple photos in a panorama, then quickly kick off the Hugin auto-analysis for that grouping
> cat ~/bin/my_pto_gen
output = IO.popen(["pto_gen", *ARGV])
output.readlines.each do |line|
if(line =~ /Written output to (.*)/)
system("PTBatcherGUI", "-a", $1, "-b")
> cat ~/bin/my_pto_gen.desktop
Name=Custom Hugin PTO generator
Comment=Initialise a Hugin panorama project from multiple photos & run the assistant
GenericName=Panorama project generator & assistant
desktop-file-install --dir=/home/matt/.local/share/applications/ /home/matt/bin/my_pto_gen.desktop
Doesn’t work, but autofs works on all other machines just fine.
“showmount” works fine.
mentioned resolv.conf. Found a strange entry there:
no other machines have that entry. How to remove?
/etc/dhcpcd.conf to not request the domain name?
That removed the domain from
resolv.conf, but autofs still fails.
sudo mount bruce:/ /mnt/bruce/ works, so it’s not NFS sucking. definitely autofs.
> mount |grep bruce
bruce:/ on /mnt/bruce type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.106,local_lock=none,addr=192.168.1.102)
maybe I need to uncomment the NFS4 line in
/etc/auto.net? I’ve never done that anywhere else…no effect
This worked…no idea why: http://russell.ballestrini.net/autofs-net-automount-stopped-working/
I’ll try rolling back my other changes to see if they’re necessary too. Nope, only the change to
I have a commercial IOT product that I want more control over. Sure, I can control it with the free Android app, but I want my home server to be able to control it, too. This means trying to understand how the app controls it over the network, and attempting to replicate that communication.
This means I have to do some packet sniffing.
At this point, I have a few IOT things on my home network. The first were a couple of EcoPlugs Wifi outlets that I use to control my gutter heaters in the winter, and the next was a custom garage door controller. For the former, I’m basically controlling them by using a replay attack (I hope to make a post about this soon)…re-sending packets that I observed the EcoPlugs app sending. For the latter, I’m using a custom http interface. Since both of these contain an ESP8266, I’d like re-program them and unify them both to use the MQTT protocol.
While browsing Hackaday, I came across their Minimal MQTT series. In this post, I’ll begin by walking through that series, noting my thoughts, then conclude by getting things set up the way I want.
Canonical recently dropped official support for Ubuntu 15.10 “Wily Werewolf”, so I decided to upgrade. I also don’t like being stuck on Long-Term-Support releases, so I did 2 upgrades in sequence: 15.10 “Wily Werewolf” to 16.04 “Xenial Xerus” to 16.10 “Yakkety Yak”. In the past, I’ve just done a clean install, but the trouble with that is having to re-do all my various customizations. This time I figured I’d just try an in-place upgrade. Of course, this meant that my customizations conflicted with packages changes. I’m still not sure which method is better.
For those that don’t know, sslh is a TCP port multiplexer. This basically means that you can serve both
ssh traffic from the same port. It’s most useful for circumventing corporate firewalls that block TCP port 22 (i.e.
ssh), but allow TCP port 443 (i.e.
https) by serving both on TCP port 443.
In the default configuration, however, all connections that go through
sslh look to
apache as if they came from
localhost. This isn’t ideal if you want to run something like
fail2ban to block malicious
ssh login attempts.
sslh does have an option to do “transparent” proxying so
apache think that the connections have come from the right place. In this post, I’ll describe how I set this up on my machine.