I've got an AWS instance running Jupyter that I use for general mucking around, and tend to shut it down when not in use. Shutting it down changes the IP and the DNS name. On the Mac, I have a simple script that uses the AWS CLI to grab the current IP of the instance and use that to open the Jupyter notebook in Chrome.
I'm trying to replicate the same functionality on a ChromeBook. I've been able to get the shell running, get the AWS CLI running, but can't figure out how to do the last bit, which is to open the URL in Chrome. (In other words, do the equivalent of the OSX Bash command open -a "/Applications/Google Chrome.app" http://1.2.3.4:8888 on the ChromeBook shell.
So basically I want to know how to open an arbitrary URL in Chrome from the ChromeBook shell.
My Chromium OS machine has xdg-open. If your version has that, it'll be the easiest thing.
xdg-open http://1.2.3.4:8888
If not, you can always just call the full path of Chrome with the url as a parameter, (e.g. chrome http://...) or consider the many options provided here.
I've been using IPython ever since I can remember (and I have a pretty good memory), both for Python and for Julia. However, lately there seems to be an issue with getting it to work on my browser. I use ver. 50.1.0 of FF and my IP software is up-to-date. The program launches fine (i.e. without any errors), initiating a local host at port 8888, but the browser never gets the memo to start a new tab to render whatever IPython sends to that address. Any suggestions?
Apparently this has to do with some update or something that I've done recently. When I go to the local host address I can access the notebook. Even though this is less than ideal, as I have to take an additional step in order to use IPython, it's not crucial.
I'm running GitLab on Centos 7. GitLab was installed using YUM.
The initial gitlab version was 1.7.12.2.
The problem is with the WEB interface of the GitLab installation.
I'm trying to get the browser session to timeout so that it forces you to login again after a certain period.
I have noticed that a change request was implemented, so I upgraded from 1.7.12.2 to 1.7.14.3 using yum update.
Under the Administration setting (in Web UI) I can now see the extra parameter where you can set the timeout. I have now changed it tt two minutes(for testing so I don't have to wait so long), but it simply does not work.
I have also tried something bigger - 5 minutes - not working.
I have also done a gitlab-ctl stop, then gitlab-ctl reconfigure and then gitlab-ctl start. The new value still shows, but the browser session still does not timeout.
I have also created a new CentOS 7 installation from scratch, installed GitLab via yum with version 1.7.14.3 - this is as-is from the installation - so no previous upgrade problems or similar problems.
I have tried different browsers (FireFox and Chrome) on Windows 7/8, Even Mac. I have also cleared the browser cookies to make sure it gets the latest after the updates. No change in behavior.
Changing the time still has no effect....
Anybody with an idea what I'm doing wrong?
The truth is I think there is a bug in the current session expiration mechanism. See https://gitlab.com/gitlab-org/gitlab-ce/issues/2129
Short answer, your not crazy ;) Hopefully we can resolve this issue shortly.
I've just installed Meteor 1.0 on my Ubuntu 12.04 VM in VirtualBox. After login via SSH from my OS X host and trying out the Meteor tutorial at https://www.meteor.com/try I get this exit code 100 from Mongo when I launch the example.
Here's the weird part, I only see this exit code 100 when I'm using OS X's terminal to SSH. If I try using putty on Windows or Chrome Secure Shell in my Chrome browser there is no problem. The Meteor app launches ok!
Is OS X's terminal/SSH implementation any different from putty or Chrome Secure Shell?
OSX ssh is a version of OpenSSH, which is essentially the reference version of ssh. It's extremely unlikely that it's doing something unique or different than putty which prevents mongodb from working.
It is possible that you're using ssh differently than you're using putty, and that's preventing mongodb from working. You haven't given us any information about exactly how you're running ssh, or what putty options you're using. So there's no way for anyone to help you with that.
There are numerous questions on this site about mongodb exit code 100. Common causes seem to be lack of disk space and inability to delete a lock file. If you were using a different ubuntu account when you connect from OSX vs putty, that could certainly cause trouble deleting a lock file, for example.
I was wondering if there's a way to use Mosh on windows without Cygwin?
I need to be able to put it on my USB drive and copy it over to a windows computer and be able to Mosh into one of my servers. Otherwise, is there a way to use Cygwin and have it portable? I did get mosh working under windows via Cygwin, but that meant I had to add an environment path to the windows computer, which, on the windows computer that I'm working on doesn't allow you to change that, since I don't have admin privileges.
MobaXTerm is portable and supports Mosh.
It works quite well. I spent all day using it on a very dodgy connection and it worked like a charm.
Just get the most recent version and from the Session menu select Mosh. It did does not support IPv6 (at least in Version 9.2 (2016-09-18)):
Bugfix: Mosh sessions are forced to IPv4 only (IPv6 is not yet supported by Mosh client/server)
But it might work now, since Version 10.4 (untested):
We also improved MobaXterm behavior and fixed issues with multi-monitors, IPv6 connections, mouse scrolling and keyboard shortcuts.
Interestingly enough, I wanted MOSH for Windows too, and I find Cygwin to be very messy. Instead, I just downloaded a minimal Text-only Debian distribution, booted it up in VirtualBox, and installed MOSH. Surprisingly, it's much less time consuming and requires less tweaking than going the Cygwin route, and makes less modifications to the host machine.
In fact, there is a portable VirtualBox, so you can put your MOSH VM and Portable VirtualBox on a memory stick.
I haven't even tried to optimize things, but it runs just fine on the 256MB of ram I gave it. It would probably run just fine on 64MB or less.
I do hope MOSH will be built into PuTTY/KiTTY in the future.
I have noticed that a new version of MobaXterm has been released (version 7.1) and includes an intergrated Mosh session.
So, you dot not need anymore need plugin for that.
They said that it is "experimental", but I have tested it, and it is working quite well.
As of now, Mosh has added support for Google Chrome (or any of Chromium Browsers) as an official extension. So you can keep a portable google chrome & use mosh from there.
For Windows, there isn't a single solution install to support MOSH. Rather, you have to sort of "stitch together" a few options to make it work.
MOSH itself does not need ssh or any other initial program necessarily. It is possible to start a session on your server, then using the published connection information, go to your client (in this case your windows box) and use that information to connect the session. This is sort of messy and is the main reason people use SSH to basically establish a connection to the server, remotely start a MOSH server, get the session information back to your client machine, then launch the MOSH experience.
The two pieces you need on the client side (if you make the connection manually) are the server port number and symmetric encryption key. A typical example of one given by a MOSH server would be:
MOSH CONNECT 60001 U0MWPbwn3BdcdMyNLnSFCA
Where 60001 is my port number and "U0...CA" is my encryption key. Don't ever give this out BTW as ANYONE can connect to your running MOSH server with this information (that is, they would look just like an IP change just like you do when you get disconnected and reconnected)
So, back to installation. MobaXterm (currently at v10.5) is a free for personal use app that you can find at https://mobaxterm.mobatek.net/. Installation is relatively straight forward. One word of caution however, their SSH implementation is rudimentary. Basically they support password authentication for ssh. If you use public keys, you cannot have one with a password on it and expect it to work (the code to ask you for your password appears to be missing). This might not be a show stopper for everyone but this is where my company stopped following this thread.
Within MobiXTerm, you want to hit the "Sessions" button at the top left to bring up a new session window. Press the Mosh button on the top right to get the start of your session (NOTE: This is IPv4 only. Zippo luck on getting IPv6 with this to work). Enter your remote host and the username of the ssh account you will be using. If you have an unsigned ssh key, then you can use the Advanced Mosh setting to link that private key with this session (at this point, as a security guy, I'm sort of passing out). At this point, as long as mosh is correctly running on your server (with the 60000-61000 UDP ports open in the server firewall), things should "just work".
Ok, so its not too painful to get working this way. But other than terminal functionality, its not very much fun either. Although MobiXterm is an X-server, I haven't yet gotten X to function over the mobi connection (at least not automatically).