run Sublime Text from OSX commandline

OSX is a little annoying that it's not quite as easy to symlink Sublime Text to a "/bin/command".  In doing so, so all kinds of cruft console output occurs.

But i've figured a better way to launch Sublime Text via commandline:

In your ~/.bash_profile add the following function:

function sublime() {
open -a Sublime\ Text.app "$@"
}


----
Please consider crypto tipping:
  

BASH copy preserving timestamps in Linux and OSX

The cp command annoys me sometimes in that i expect my files to retain their time-stamps.  However, such is not the default.  To set this behavior automatically, aliases may be used.

In a Linux ~/.bashrc file, include the follwing alias:
alias cp="cp --preserve=timestamps"

In an OSX ~/.bash_profile, include the following alias:
alias cp="cp -p"

In both cases you will need to exit and restart bash.

---


Please consider crypto tipping:
  

SSH - no matching cipher found

Edit: Please do your research, this may re-introduce vulnerable ciphers -- i don't have time to be safe. lmao.  
Please reference https://stribika.github.io/2015/01/04/secure-secure-shell.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After a recent update of either Debian testing (Jessie) or OSX (Mavericks), I could no longer SSH from OSX into my Debian testing boxes.

I really don't know which OS update was at fault, but when I tried to SSH into my Debian testing boxes, i received the following message:

no matching cipher found: client blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

I can't have that -- my daughter needed to play on the minecraft server and she NEEDED TO PLAY NOW!

What this told me is that that my client (OSX) expected blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc but my server (Debian) supported aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

That sucks; stupid computer! (Wow, had not said that once since leaving Windows®)

Via web searches, I found that I could force a cipher like so: ssh -c aes128-ctr username@hostname so i did successfully. (I could just as well used ssh -c none username@hostname, but that's risky)

Once logged into my Debian box(es), I edited the ssh daemon config:

sudo nano /etc/ssh/sshd_config

and added the following to the bottom:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

As you can see, since I didn't know if there is an order of preference or not, I erred on the safe side and added the previously supported server ciphers before the client's expected ciphers.

Afterward I had to restart and verify the SSH Daemon:

sudo service sshd restart ; sudo service sshd status

On my OSX client, I tried to SSH and it complained WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! .. Oh my lord the world will end.

An easy fix was ssh-keygen -R hostname, where hostname was my Debian's hostname or IP obviosuly.

Now it worked as expected (and should have never failed in the first place).

-end-

But Daddy, you forgot the minecraft server... START THE MINECRAFT SERVER NOW!

~~~
As always, good luck!

Please consider crypto tipping:
  

NTFS on OSX for FREE

I've since upgrade to OSX10.11.4 and "NTFS Free" no longer works. if you have a free solution, please post a comment below, TYVM.

----

1) Fuse for OSX

2) NTFS Free

i.e. You don't need to use the non-free Textera nor Paragon

off subject bonus: SSHFS

Update:
OSX 10.10 Yosemite broke this, but it can still be made to work by executing the following commands.  Special thanks to "braines" on the NTFS-FREE comments.

"braines" quote:
" Installing Yosemite broke my install with their stricter rules on code-signed kernal extensions for security reasons. To fix it, you need to run the following 3 commands in terminal before installing/reinstalling: 1) sudo nvram boot-args="kext-dev-mode=1" 2) sudo kextcache -system-prelinked-kernel 3) sudo kextcache -system-caches after the first command you will need to enter your password because of 'sudo' (super user do) this disables the security check. the other 2 commands just clear your cache of any old versions of this kernel extension to give you a fresh slate. After you install/reinstall you'll restart and things seem to be working. I suspect that this will be broken in the next update because this uses the /System/ folder which apple will be phasing out 3d party use of that folder "

---

Please consider crypto tipping:
  

OSX cronjob with GNU screen fails to run reporting "Must be connected to a terminal."

OSX crontab (cronjob) with GNU "screen" fails to run reporting "Must be connected to a terminal."


I had set a cronjob to run using the "screen" command,

0 * * * * /path/to/script.sh


where my script is:

#!/bin/bash
/usr/bin/screen -S taskname /usr/bin/nice mycommand


but it failed to run.  To figure out the problem, i redirected output to a log.

0 * * * * /path/to/script.sh > ~/mylog.log


The log reported "Must be connected to a terminal."

The solution is to add the -d -m options to screen:

#!/bin/bash
/usr/bin/screen -d -m -S taskname /usr/bin/nice mycommand


w00t!

-------

Please consider crypto tipping:
  

Password Protect Microsoft Remote Desktop Client for OSX

Microsoft Remote Desktop client version 8.x for OSX was released and I find it particularly nice. (Way better than v. 2.1.1 anyway).

One thing I tend to do is store my passwords, but this can be a bad habit for an enterprise environment.

I've found a way to password protect launching the RDP client, and furthermore, close it when the computer sleeps -- very convenient.

Essentially, what we'll do is create an encrypted storage container, move the app inside, and launch kill/eject scripts when entering sleep-mode.

This write-up assumes OSX 10.5+; I'm on 10.9.1 (Mavericks).

First, I used Disk Utility to create an encrypted .dmg file:

Launch the Disk Utility via Applications>Utility>Disk Utility.

Select File>New>Blank Disk Image.

In the "Save As" field, find your home directory or any other preferred area.  Name it "RDP.dmg".

In then "Name" field, name it "RDP" -- we will reuse this name for the eject-function later.

I found that "Microsoft Remote Desktop.app" was 67.7MB, so I opted to set the "Size" field as 72MB.  You can try 68MB if you like, I assume it would be fine.

For the "Format" field, I chose "Mac OSX Extended" as i do not need it journaled.

In the "Encryption" field, I chose 128-bit AES, but you may choose 256 if you are paranoid.

For "Partitions" and "Image Format", I chose the defaults of Single GUID and read/write respectively.

You will be asked for a password.  This is permanent so choose wisely.  Also, for the "Check-box" elect NOT to "Remember Password in my keychain" so that you are required to enter your password with each launch.

Once the RDP.dmg file is created, open it with Finder if it's not already open.  Again do NOT check to "Remember password".  Using Finder, drag the Microsoft Remote Desktop application into your new RDP.dmg file.  MS-RD should be in your Applications folder if you've installed it, or in the installer .dmg if you have not.

Once you have MS-RD inside the RDP.dmg file, go ahead and launch that copy.  Now to simplify things for future usage, on OSX's Dock, right click "Microsoft Remote Desktop", select Options, and select "Keep in Dock".

Now let's test your new password protected RDP Client.  First, close the MS-RD application.  Then eject "RDP".

Now using the Dock shortcut, click to open "Microsoft Remote Desktop" -- it should again ask for your password.  Voila, you have a password protected RDP client!  The key to this is to never check-on "Remember password in my keychain."

If everything works as expected, you should delete the original MS-RD app from your applications folder if you had previously installed it.  (And remove the original Keep in Dock if you had such.)

Now the interesting part of the project -- the RDP.dmg remains mounted even if you close MS-RD.  This mean the app could be re-lauched without the password. To protect from this, you could manually eject RDP.dmg after each usage (blah), or we can find a way to both close MS-RD and eject RDP.dmg when the machine goes into sleep mode (way more convenient). 

Now there may be ways to execute the process for a screensaver trigger, but I happened across a sleep-mode trigger solution first using SleepWatcher.  In fact, upon reading, SleepWatcher does indeed have an idle-mode trigger too, but this write-up will not utilize such as I have done this on a MacBook-Air and opted for sleep-trigger due to the ability to close the screen-lid to enter sleep-mode.

This configuration process will be mostly command line oriented.

Go ahead and download and extract SleepWatcher to your ~/Desktop.  You can delete the folder/files after the configuration process. Be certain to read the ReadMe.rtf file within.  If you do not already have SleepWatcher, then do not perform the first tasks listed, instead be sure to jump to the "Installation for new SleepWatcher users" section. Go ahead and skim through the readme first; The commands are listed below for convenience.

I elected to use the "user" mode .plist and therefore this resulted in my functions to be created in the ~/.sleep file.

If you elect the same, then as per the ReadMe.rtf file, do the following:

sudo mkdir -p /usr/local/sbin /usr/local/share/man/man8
 
sudo cp ~/Desktop/sleepwatcher_2.2/sleepwatcher /usr/local/sbin/
 
sudo cp ~/Desktop/sleepwatcher_2.2/sleepwatcher.8 /usr/local/share/man/man8/
 
cp ~/Desktop/sleepwatcher_2.2/config/de.bernhard-baehr.sleepwatcher-20compatibility-localuser.plist ~/Library/LaunchAgents/

launchctl load ~/Library/LaunchAgents/
de.bernhard-baehr.sleepwatcher-20compatibility-localuser.plist

Be careful copy-pasting, the five commands above are all ONE LINE each. You may opt to copy-paste into a text editor first to verify ONE-LINERS.

My ~/.sleep file consisted of the following:

#!/bin/sh
killall "Microsoft Remote Desktop"
/usr/sbin/diskutil eject /Volumes/RDP

Be sure to chmod +x ~/.sleep to make it executable.

The above ~/.sleep script will close MS-RD and also eject the RDP.dmg file.

If you've done the above configuration properly, then you can test the scenario by launching MS-RD and then closing your laptop lid or waiting for sleep-mode to trigger.  Your power settings in OSX are in Applications>System Preferences>Energy Saver.

Quite cool, no?

-------------------
Good Luck!

-------------------

Please consider crypto tipping:
  

Replacing LogMeIn with TeamViewer on OSX and Linux

LogMeIn is no longer free and I'm not paying!

There are many remote desktop solutions and I have multiple ways of seeing my Linux desktop in emergency, but I've found TeamViewer (free for personal use) is a great replacement of LogMeIn on OSX.

I was accustomed to LogMeIn on OSX because it was always running and quite simple to remote from the web-console, LogMeIn Ignition, or even Android and iOS.  TeamViewer, although not the prettiest interface, works the same, supports multiple monitors, and even supports Linux. It also has advanced features such as file-transfer, meeting-mode, and video/audio conferencing -- but I'm not one to utilize such. TeamViewer does indeed have Android and iOS clients as well.

Go ahead and install the "All-In-One: TeamViewer full version" from TeamViewer.com/en/download for either Linux or OSX or both. If you choose, make them run at startup (as a daemon (service)). I also have a way around this as you will see further down.

Now the key settings to make TeamViewer work like LogMeIn is the following:

1) Create an account on TeamViewer.com !
2) Assign your client(s) to your account: TeamViewer>Preferences>General>Assign to account.
3) Set your client to unattended mode: TeamViewer>Preferences>Security>Password.

Presto change-o -- a LogMeIn replacement!

===============================================================


* The issue mentioned below seems to be fix in recent versions; However, I'll keep this info available: 


I had one issue that bugged me: On Linux, the client constantly bugged me with a pop-up and reported "click to disable" (the pop-up).  But it would never disable, no matter what.  So my solution is to NOT run TeamViewer upon startup; HOWEVER, I can still launch it via remote SSH login.

The key to this is that I still run LogMeIn Hamachi (Mesh VPN) on all my machines so that I always have SSH access to any of them (as long as Hamachi doesn't fail).

Now, from a remote machine, SSH into the Linux machine and perform the following:

env DISPLAY=:0 teamviewer

Don't close your SSH (preferably, run it from screen). This will set the GUI of TeamViewer to the default display (the monitor) and launch it properly -- now TeamViewer should be ready for a client connection.  (If it does not launch, see below regarding the daemon start command)

------------------------------------------------------------------------------------------------------------

Similarly, this can be done with OSX, but there seems to be a bug that requires a particular work-around that I was lucky to notice.  TeamViewer will need to be run twice -- once as sudo, and another as the user:

SSH into the OSX machine and run TeamViewer like so:

sudo /Applications/TeamViewer.app/Contents/MacOS/TeamViewer 

It should fail and report:
com.teamviewer.desktop: Invalid argument
com.teamviewer.teamviewer: Invalid argument

Now run it again without sudo:

/Applications/TeamViewer.app/Contents/MacOS/TeamViewer

This should launch TeamViewer and make it ready for a client connection.

If for some reason it fails to launch, try setting the display first with:

export DISPLAY=:0

===============================================================

I've had some occasions where the programs stay running or won't relaunch properly.  It's probably best to quit the program from the desktop GUI, but if all else fails, in Linux, we can use the killall command to stop the processes:

killall teamviewer
killall wineserver
killall TeamViewer.exe
sudo killall teamviewerd

(It turns out TeamViewer for Linux actually runs a custom version of wine to emulate the windows version.)

You should restart the daemon service after any kills, as the GUI client will not run without:

sudo teamviewer --daemon start

In OSX, it seems I could only quit TeamViewer from the Desktop and unfortunately not use the killall nor the kill commands.

You may have better success, you can find the processes with the following command:

ps aux | grep [Tt]eam[Vv]iewer

===============================================================

Other free options that you may research -- but likely require direct network connectivity or VPN and therefore do not work like LogMeIn or TeamViewer for "from anywhere" remote access:

Both Linux and OSX:
X11 Forwarding over SSH
NoMachine.com (NXRemote) -- I had played with version 3 which was SSH secure and as fast as RDP.  It created virtual desktops like RDP, but I had issues keeping it working.  Version 4 is now available and works differently -- it now connects to the actual desktop much as LogMeIn or x11vnc.  It is, however, direct access only until they release "NoMachine Anywhere." Android and iOS clients are in Alpha and not yet released.

OSX:
Preferences>Sharing>Screen Sharing (VNC) (There commandlines/files to enable, but different versions of OSX have different commands, so you may research that on your own.)

Linux (likely in your repositories) :
xrdp - RDP for X !
A ton of different VNC servers, but i like x11vnc best.

===============================================================

Related to the subject, here are RDP Clients:

OSX:
Microsoft RDP Client v2.1.1
Microsoft RDP Client v8.x (on a domain, use the "DOMAIN\username" syntax) ; Available on iOS also!

Linux (likely in your repositories):
Remmina+freerdp (xfreerdp) -- supports Microsoft's Network Level Authentication (NLA).

===============================================================

Related to the subject, here are alternatives to Hamachi (listing only cross-platform solutions):

ZeroTier One (RECOMMENDED - i have move off of hamachi onto this; with great success)
n2n - a Layer Two Peer-to-Peer VPN
SoftEther VPN Project
tinc vpn
freelan (no redhat, et al?)
Remobo -- I had tried this a long time ago, but didn't like it so much.  It might be worth a revisit.
NeoRouter Free (as opposed to the Mesh and Pro versions)

=========
Good Luck!
=========


Please consider crypto tipping:
  

Spectacle OSX Mavericks fail

Did you upgrade to OSX Mavericks only to find Spectacle failing and no "Enable access for assistive devices" option available?

Me too.

Go to your Systems Preferences, go to Security and Privacy, go to Privacy, then Accessibility, and finally check-mark Spectacle (You may need to click the Lock at the bottom left corner first).

----------
Please consider crypto tipping:
  

Holy X11 Batman (RDP via ssh X11Forwarding from an OSX host over VPN -- it's true!)

Can it be true??? YES it IS... with a caveat I hope you solve for me...
The caveat is with a Linux client; I've verified OSX to OSX has no issue.

Scenario: I wanted to ssh into my Mac Pro at work from my Linux box at home and launch RDP via X11Forwarding.  Of course, from-Linux to-Linux is a non-issue, but in this case my host is OSX.  I got to playing, and the surprise was joyous.

Setup/Prerequisites:
 Client: Linux or OSX
 Host: OSX 10.8
 VPN: Hamachi (Hamachi for Linux in Labs)
 RDP Client: FreeRDP via OSX HomeBrew
 X11: XQuartz will be required for both OSX Hosts and OSX Clients.  Of course X11 is already part of any Linux Desktop Environment.
 Host firewall's ssh port 22 open for NIC "ham0"


Assumptions/Prerequisites:
 Let's assume you've installed XQuarts on the OSX host already.
 Let's assume you have Hamachi fully operational on both machines. (i.e. hamachi logged in, VPN created, joined on both machines, firewall open for ham0) -- ("hamachi list" to see your IP's, "hamachi -h" for other options).
 Let's assume you've installed Homebrew on the host already. (or you can do it while ssh'd in).

We will do this remotely through the hamachi VPN.

From your linux client, ssh into your OSX host: (If on an OSX client, XQuartz's xterm is necessary)
 ssh -XC user@hostIP #(-X is for X11 forwarding, -C is for compression)

Edit the ssh server config:
 sudo nano /etc/sshd_config
Adding the following 3 lines to the end of the config file:
 AddressFamily inet #(required when IPv6 is disabled on any client or host)
 X11Forwarding yes
 X11DisplayOffset 10

Restart the sshd service:
 ps -ef | grep sshd | awk {'print $2'} | sudo xargs kill -HUP
 
This will have disconnected you, so ssh in again:
 ssh -XC user@hostIP

Let's install FreeRDP:
 brew install freerdp

Setup the display for the X11Forward:
 export DISPLAY=localhost:10.0

Now run xfreerdp:
 xfreerdp serverIP #(where serverIP is a legitimate internal network IP)
 #OR
 xfreerdp -u username -d domain serverIP  #(where -d domain is only needed for Active Directory members)

Proof:

Caveat:
  I've found a significant issue strictly when on Linux client-side --  When i type into the RDP session I get completely different characters making the session unusable.

Here I type "Administrator":

I'm sure it's a keyboard or character set issue.  I'm looking into the xfreerdp -k option, but have not solved it yet.  If you solve my problem, PLEASE post it in a comment.  Thank you, and good luck!
------------
Please consider crypto tipping: