I have followed (and partially adapted) the recommendations in Open file via SSH and Sudo with Emacs
My custom.el contains something like the following:
(custom-set-variables
'(tramp-default-proxies-alist (quote (("my-sudo-alias" nil "/ssh:user#host")))))
However when I try to visit a remote file say sudo:my-sudo-alias:/etc/whatever I get the following error: Method `scpc' is not supported for multi-hops.
How do I fix this?
Perhaps something else in your proxy list is interfering?
What does C-h v tramp-default-proxies-alist look like?
You might also have scpc set as your tramp-default-method. I don't think that should be an issue in this case, but I'm not certain of that.
Did you try the ad-hoc approach that I detailed in the Q&A you linked to?
If that doesn't work, try emptying the proxy list, and then trying it again.
Note also that the scpc & rsyncc tramp methods are deprecated in the latest Tramp (ControlMaster is now used automatically if it is available).
Related
I am using TRAMP to work on a remote host that has a very weird PATH. I was wondering whether it was possible to customize the PATH used by TRAMP to find the binary files only for this host?
Now, I'm using:
(add-to-list 'tramp-remote-path "/some/weird/path/bin")
but it also applies to any other host without this funky PATH, thus messing up all the other hosts' PATHs.
I'm sorry, but this is not possible yet. There is an item on Tramp's todo list for supporting connection-local variables, but this is not implemented yet.
Alternatively, you might set this in the $PATH env variable in your remote .profile. Then you instruct Tramp to use this, by adding tramp-own-remote-path to tramp-remote-path.
Seems like a silly question, but I cannot find the kernal.js script and I think I need to edit it for my installation...(see reason below if interested, though it's not part of the question). Does anyone know where it would be located on a Linux Ubuntu system? I've tried find and grep, but not getting anywhere.
I am serving ipython notebook with a reverse proxy in front, and I am finding that the path to the kernals is wrong, causing errors when I try to load a notebook. I think this line is a problem:
var ws_url = this.ws_url + this.kernel_url;
Because it excludes the port number suffix from ws_url, which is needed as I am not using the default port with my reverse proxy setup.
I realise it would be an ugly hack to change it, but it's only for development purposes.
Check /usr/share/ipython/notebook/static/services/kernels/js/kernel.js
Lets say I have an Emacs-Server running on some remote server, with all the libraries and software necessary for running my application.
Then I want several clients to connect to that remote machine, using Emacs-client. Does each client need a full Emacs installation, or is there a minimal installation that is just enough to communicate with the remote server, where all the action is?
Could this (Emacs-)client installation be so minimal, that almost all software-updates can be done on the server, without affecting the Emacs-clients?
Is there a reason not to run the clients remotely as well, and simply use a local display? That way, pretty much all you need on the local machines is the ssh client and the X Window server.
ssh -X (user)#(server) "emacsclient -c"
Edits for the comments:
This command starts a new client to connect to an existing Emacs server (which it assumes is already running). You can use "emacsclient -a '' -c" to automatically start emacs --daemon if there is no existing server, but I don't know whether you want the connecting user to be starting the server.
In fact, I'm pretty unsure about the whole multi-user side of this to be honest, as I've never done that before. Authentication for the above is handled by ssh, but there may well be subsequent permission issues to deal with, or similar, when the server and the clients are started by different users.
This approach should be possible with Windows/Cygwin as client and/or server, as Cygwin provides Emacs, OpenSSH, and X.org packages. (I regularly use Windows/Cygwin as a local display for Emacs running on Linux.) It may be harder to set up, though, and any permissions issues are probably different when you're using Cygwin.
I'm less sure how this would work without Cygwin. NTEmacs certainly won't talk to X.org, so I imagine you'd be terminal based in that instance. (There are probably other options, but Cygwin sounds to me like the best-integrated approach to using all of Emacs, SSH, and X on Windows).
Lastly, I imagine you're probably getting your "Connection refused" error because localhost is not running a sshd daemon? I would say that configuration of ssh is outside the scope of this question, but there are lots of resources online for that.
Depending on what you're trying to achieve, you may be able to use a combination of Emacs and Screen. By starting up Emacs from Screen on the remote machine and detaching from it, you can subsequently re-attach from a different machine that doesn't have Emacs. Again, whether this will work for you or not depends on what you're trying to do; however, for many Emacs use-cases, this can be very effective. If you're not familiar with using Screen in this manner, here is some reading material:
screen - The Terminal Multiplexer
I am not sure that would be possible. emacsclient uses tramp to connect to a remote server, and just by looking at the number of requires in the tramp elisp files (41) it seems very unlikely. You can try it yourself with the following:
zgrep -oE "\(require '[a-z-]+\)" *el.gz | sed -e 's%[a-z0-9-]\+\.el\.gz:%%g' | sort | uniq -cu | wc -l
I'm not an expert in emacsclient, but I don't think is was designed to do what you're looking for. I think the general use case is that emacsclient allows you to redirect new requests to open a file with emacs to a persistent emacs process to avoid what may be a bit of an overhead in startup time. You seem to be looking for more of a true client/server relationship.
I think to meet the goal you're aiming at you'll probably need to look a little outside emacs, probably a project unto itself - 'emacsRemoteClient. It boils down to one or two models; the file you want to edit would need to have it's path sent over to the server machine so that emacs could do some sort of remote tramp access & then spawn the xwindow locally (using the local X env or requiring an x server on windows)... or two, transferring the file to some temp location on the server box and again spawning the remote x window locally (followed by syncing the changes between the tmp & local file).
Would be cool to have something like that... but suspecting it'll involve a bit of work. Maybe we just need a version of emacs written in javascript and it can live in the cloud or on your browser... oh to have emacs keybindings in the browser ;-)
-Steve
This page from the Emacs manual describes a function called make-frame-on-display that allows you to access a remote Emacs session. My interest in this function is to use it to share buffers for pair programming remotely with a colleague.
From the page:
It is even possible to use this feature to let two or more users type simultaneously on the two displays, within the same Emacs job. In practice, however, the different users can easily interfere with each others' edits if they are not careful.
How exactly do I set this up? What do I need? What does my partner need? The details are not stated, but I don't know enough about Emacs to know where to start.
Is there any other way to get a shared Emacs session? This page from the Emacs Wiki refers to something called multi-tty. The questions I asked above also apply to this.
Which is better: multi-tty or make-frame-on-display?
I haven't tried multi-tty, but make-frame-on-display is pretty simple. You type M-x make-frame-on-display, hit return, then type the display you want the frame to show up on. For example:
I have my local host (thor) running emacs and I want to make a frame pop up on a machine called zeus, on its only X display (0.0). So I would type M-x make-frame-on-display<ret>zeus:0.0<ret>
All set!
You may need to configure the remote machine's X server to accept incoming connections from your machine with "xhost +thor". You may also need to configure its firewall to allow incoming connections on the X11 port, which is 6000. Keep in mind that X forwarding is not encrypted, so if you aren't working with someone on your LAN you may want to go through a VPN in order to keep things private.
Edited to fix brackets.
You can also have the person at zeus type ssh -X thor emacsclient -c.
Did you ever consider using GNU screen on a shared account for pair programming? It's dead easy to get it to work and you get to pick any console based editor you and your partner like (emacs, vim, joe, nano, zile, ...). However, this does of course not work with editors that cannot run inside a terminal.
To set it up, create a shared account on a computer running ssh. Then both log in to that account. One of the partners starts screen with
screen
and the other connects to it with
screen -x
where -x means "attach to a not detached screen session". The users can detach from their sessions w/ "C-a d".
Old question, new solution for anyone landed on this page from year 2016.
I set this up in Ubuntu 14.04 and it works perfectly:
Suppose I want to co-edit or demo some cool stuffs on emacs with my colleague Joe on the other end of the world.
Make sure an ssh server with emacs installed at either end. That is, either MyPC or JoePC must be a SSH server and have Emacs installed. From now on, let's say I asked Joe to install SSH server and Emacs on his computer.
Make sure byobu is installed on JoePC. Byobu supports both tmux and screen as backends (I prefer tmux for a more mordern and feature-rich).
I connect to JoePC with ssh remoteuser#joepc. No need for X-forwarding.
Open emacs from byobu-ssh terminal: TERM=xterm-256color && emacsclient --alternate-editor="" -t. One can make an alias for this command. I recommend this long command because it enables both better color support in the terminal and running Emacs in daemon mode. The daemon mode make it fast to close and reopen frames.
Now the magic unfold: Ask Joe to login with the same remoteuser I am loggin in; open the terminal and start byobu if it hasn't for him.
Start hacking or fumbling :-)
Comment:
Because the way byobu work. This approach works for any other program inside the byobu terminal.
This setup performs much better than Teamviewer or any other GUI remote desktop solutions.
Because the connection is through ssh to the remote server directly, it is as secure as the ssh conenction can offer.
I have seen a few suggestions on making emacs portable (on Windows). I have this in my site-start.el:
(defvar program-dir (substring data-directory 0 -4))
(setq inhibit-startup-message t)
(setenv "HOME" program-dir)
I changed the HOME variable so that not only my .emacs init files (and other init files) are read, but everything generated by emacs will stay in the program directory, not needing me to specify the path for everything one by one.
Well this works well but the emacs server is not working; I get error message "no connection could be made because target machine actively refused it." If I don't change my HOME var then emacs server works. Is there way to fix this?
Quoth the Emacs manual:
When you start the Emacs server (by calling server-start), Emacs creates a file with information about TCP connection to the server: the host where Emacs is running, the port where it is listening, and an authentication string. emacsclient uses this information if it needs to connect to the server via TCP. By default, the file goes in the ~/.emacs.d/server/ directory. You can specify the file name to use with the `-f file' or `--server-file=file' options, or by setting EMACS_SERVER_FILE environment variable to the file name.
In other words: wherever you're calling emacsclient from, you'll have to tell it to use the file in ${program-dir}/.emacs.d/server/, either with -f or setting the EMACS_SERVER_FILE environment variable. (In the environment in which you're starting emacsclient, not within Emacs.)
[You could also tell Emacsclient to look in the right place with -s for "socket", but that doesn't work on Windows. And on Unixes (at least on Mac OS X with Aquamacs) the socket would be somewhere like /tmp/emacs501/server (501 is my UID).]
[Oh, BTW, take a look at this question: How can I have a portable Emacs? Maybe something will help you, or maybe you have something to add to it :-)]
There is an initial packaging of a Portable Apps version of emacs 23.2 here. Initial test works here.