I am using MobaXterm v20.6 build 4532 to connect to a Linux machine over SSH. I am trying to open a file in the Scp panel on the left by double-clicking on it, and this brings up a dialog box saying "Please wait while opening file...", and it gets stuck here forever.
Interestingly enough, this works on some servers but not others. Is there some way to debug this? Is there a log file which shows the scp command that MobaXterm is trying to run?
I figured out the problem. I was able to enable logging by running "MobaXterm.exe -log". This left a log in C:\Users\jdoe\Documents\MobaXterm\MobaXterm.log. This was printed when I tried to open a file:
[11:31.39.305] (SSH-Browser) Starting MobaSCP(2, OpenFile, /local/jdoe/.bashrc, C:\Users\JDOE\DOCUME~1\MobaXterm\slash\RemoteFiles\526608_2_0\.bashrc)
[11:31.39.307] BEGIN ShellExecuteA(C:\Users\JDOE\DOCUME~1\MobaXterm\slash\bin\MobaSCPOpenFile.exe, -v -batch -scp -load "TERM5266082" mobauser#mobaserver:"/local/jdoe/.bashrc" "C:\Users\JDOE\DOCUME~1\MobaXterm\slash\RemoteFiles\526608_2_0\.bashrc")
[11:31.39.308] ShellExecuteA: ShellExecuteEx succeeded.
[11:31.39.308] END ShellExecuteA(C:\Users\JDOE\DOCUME~1\MobaXterm\slash\bin\MobaSCPOpenFile.exe, -v -batch -scp -load "TERM5266082" mobauser#mobaserver:"/local/jdoe/.bashrc" "C:\Users\JDOE\DOCUME~1\MobaXterm\slash\RemoteFiles\526608_2_0\.bashrc")
[11:31.39.405] [MobaSCP2] Multiplex=0
[11:31.39.406] [MobaSCP2] HOSTNAME: 192.168.1.104
[11:31.39.406] [MobaSCP2] USERNAME: jdoe
[11:31.39.724] Received verification request for hostkey: ssh-ed25519#22:192.168.1.104
[11:31.39.724] Hostkey corresponds to the cached one
[11:31.39.748] WMNewTab2: Saving sshkey and NOT CONNECTING SSH-Browser...
[11:31.39.748] BEGIN SavePassword
[11:31.39.749] END SavePassword
[11:31.39.845] [MobaSCP2] Using SCP1
[11:31.39.845] [MobaSCP2] Connected to 192.168.1.104
[11:31.39.845] [MobaSCP2] Protocol error: Expected control record
Looks like the "Expected control record" error was being caused by my .bashrc printing output. Apparently this confuses SCP: https://documentation.help/PuTTY/faq-pscp-protocol.html
I was able to fix this by changing my .bashrc to not print anything.
Related
I'm trying to do a SSH login from VSCode using the Remote SSH extension and I'm getting this error. It is working fine when I login from my GIT terminal.
The error stack:
[20:44:36.547] > \ln /root/.vscode-server/bin/a5d1cc28bb5da32ec67e86cc50f84c67cc690321/vscode-rem
> ote-lock.root.a5d1cc28bb5da32ec67e86cc50f84c67cc690321.target /root/.vscode-serv
> er/bin/a5d1cc28bb5da32ec67e86cc50f84c67cc690321/vscode-remote-lock.root.a5d1cc28
> bb5da32ec67e86cc50f84c67cc690321
>
[20:44:36.555] > ln: failed to create hard link ‘/root/.vscode-server/bin/a5d1cc28bb5da32ec67e86c
> c50f84c67cc690321/vscode-remote-lock.root.a5d1cc28bb5da32ec67e86cc50f84c67cc6903
> 21’: File exists
> Installation already in progress...
> e6e07fdafb38##24##
>
[20:44:36.555] Received install output: e6e07fdafb38##24##
[20:44:36.556] Server installation process already in progress - waiting and retrying
[20:44:36.827] "install" terminal command done
[20:44:36.827] Install terminal quit with output:
[20:44:37.557] Resolver error:
[20:44:37.560] ------
I had the same problem after updating VScode.
Not sure if this is the correct solution but it does work:
Login to your server via another ssh program like PuTTY, because your file is located in the root user home directory you'll need to login as root to do this.
Delete folder a5d1cc28bb5da32ec67e86c from /root/.vscode-server/bin/ directory.
Found the answer here:
https://github.com/microsoft/vscode-remote-release/issues/2507
I have a task to install Oracle 11g on a centOS 8 using VM (i'm new to linux / oracle).
I downloaded the Oracle files and unzipped them, then I tried to ./runInstaller but I get an error and this is the full terminal with error:
login as: admin
admin#192.168.163.129's password:
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Thu May 21 09:26:48 2020 from 192.168.163.1
[admin#oracledb ~]$ cd Downloads
[admin#oracledb Downloads]$ cd database
[admin#oracledb database]$ ls
doc linux.x64_11gR2_database_1of2 response runInstaller stage
install linux.x64_11gR2_database_2of2 rpm sshsetup welcome.html
[admin#oracledb database]$ ./runInstaller
Starting Oracle Universal Installer...
Checking Temp space: must be greater than 120 MB. Actual 2027 MB Passed
Checking swap space: must be greater than 150 MB. Actual 1759 MB Passed
Checking monitor: must be configured to display at least 256 colors
>>> Could not execute auto check for display colors using command /usr/bin/xdpyinfo. Check if the DISPLAY variable is set. Failed <<<<
Some requirement checks failed. You must fulfill these requirements before
continuing with the installation,
Continue? (y/n) [n] y
>>> Ignoring required pre-requisite failures. Continuing...
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2020-05-21_09-43-58AM. Please wait ...
DISPLAY not set. Please set the DISPLAY and try again.
Depending on the Unix Shell, you can use one of the following commands as examples to set the DISPLAY environment variable:
- For csh: % setenv DISPLAY 192.168.1.128:0.0
- For sh, ksh and bash: $ DISPLAY=192.168.1.128:0.0; export DISPLAY
Use the following command to see what shell is being used:
echo $SHELL
Use the following command to view the current DISPLAY environment variable setting:
echo $DISPLAY
- Make sure that client users are authorized to connect to the X Server.
To enable client users to access the X Server, open an xterm, dtterm or xconsole as the user that started the session and type the following command:
% xhost +
To test that the DISPLAY environment variable is set correctly, run a X11 based program that comes with the native operating system such as 'xclock':
% <full path to xclock.. see below>
If you are not able to run xclock successfully, please refer to your PC-X Server or OS vendor for further assistance.
Typical path for xclock: /usr/X11R6/bin/xclock
[admin#oracledb database]$
I am using putty and Xming but I still get this error.
Make sure your putty session is connecting with "x-11 port forwarding"
Be sure after you set this that you scroll back up to 'Session' and then 'save'
It was scuccessful to run dqn with no image, but by trying using qlua (some tutorial) to see the netwrok playing the rom in real time, it gets a
Warning x error baddrawable
It opens an image window but it is grey/blank and in terminal I get a " warning x error baddrawable (...)" error.
UPDATE: I have solved the issue I was facing. Since I am running the DeepMind in one of my instances of Google Cloud V's, via a VNC GUI server, the proceedings should work in any.
I´ve opened the script file (run_cpu) and put the line "export QT_GRAPHICSSYSTEM=native" right before the line that runs qlua. Let me share you my editings:
(UBUNTU 12.* using latest vncserver + GNOME GUI)
//terminal and where the dqn dir is:
$ vim run_cpu
//that opens the file 'run_cpu'. Press "i" to edit. The new edit should look like this (copy and paste at line 45):
export QT_GRAPHICSSYSTEM=native
//Press "ESC" then type ":wq" then enter.
$ reboot
//To make sure the effects will take change after restarting all processes.
Open a new SSH terminal via Google Cloud console. Before running the vncserver, also run the export QT_GRAPHICSSYSTEM=native before:
$ export QT_GRAPHICSSYSTEM=native
$ vncserver
Then, when connected thru a VNC client, open the terminal there and run ./run_cpu.
$ sudo bash ./run_cpu
//In case no root access.
UPDATE 2: I've also did a very small change at the dqn-graphics.sh. At line 4, leave nothing but the line with a 'then'. Like this ( :
//$ vim dqn-graphics.sh. Scroll at line 4. Press Enter. Put:
then
//ESC :wq
I use playframework2.2 and sbt 0.13.1, I can run the sbt and start the server on command line
sbt start
it works ok. but when I run:
nohup sbt start
It run a while and then stop with log error:
(Starting server. Type Ctrl+D to exit logs, the server will remain in background) java.io.IOException: Bad file descriptor
at java.io.FileInputStream.read0(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:210)
at jline.internal.NonBlockingInputStream.read(NonBlockingInputStream.java:248)
at jline.internal.InputStreamReader.read(InputStreamReader.java:261)
at jline.internal.InputStreamReader.read(InputStreamReader.java:198)
at jline.console.ConsoleReader.readCharacter(ConsoleReader.java:2038)
at play.PlayConsoleInteractionMode$$anonfun$waitForKey$1.play$PlayConsoleInteractionMode$$anonfun$$waitEOF$1(PlayInteractionMode.scala:36)
at play.PlayConsoleInteractionMode$$anonfun$waitForKey$1$$anonfun$apply$1.apply$mcV$sp(PlayInteractionMode.scala:45)
at play.PlayConsoleInteractionMode$$anonfun$doWithoutEcho$1.apply(PlayInteractionMode.scala:52)
at play.PlayConsoleInteractionMode$$anonfun$doWithoutEcho$1.apply(PlayInteractionMode.scala:49)
at play.PlayConsoleInteractionMode$.withConsoleReader(PlayInteractionMode.scala:31)
at play.PlayConsoleInteractionMode$.doWithoutEcho(PlayInteractionMode.scala:49)
at play.PlayConsoleInteractionMode$$anonfun$waitForKey$1.apply(PlayInteractionMode.scala:45)
at play.PlayConsoleInteractionMode$$anonfun$waitForKey$1.apply(PlayInteractionMode.scala:34)
at play.PlayConsoleInteractionMode$.withConsoleReader(PlayInteractionMode.scala:31)
at play.PlayConsoleInteractionMode$.waitForKey(PlayInteractionMode.scala:34)
at play.PlayConsoleInteractionMode$.waitForCancel(PlayInteractionMode.scala:55)
at play.PlayRun$$anonfun$24$$anonfun$apply$9.apply(PlayRun.scala:373)
at play.PlayRun$$anonfun$24$$anonfun$apply$9.apply(PlayRun.scala:352)
at scala.util.Either$RightProjection.map(Either.scala:536)
at play.PlayRun$$anonfun$24.apply(PlayRun.scala:352)
at play.PlayRun$$anonfun$24.apply(PlayRun.scala:334)
at sbt.Command$$anonfun$sbt$Command$$apply1$1$$anonfun$apply$6.apply(Command.scala:72)
at sbt.Command$.process(Command.scala:95)
at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:100)
at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:100)
at sbt.State$$anon$1.process(State.scala:179)
at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:100)
at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:100)
at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18)
at sbt.MainLoop$.next(MainLoop.scala:100)
at sbt.MainLoop$.run(MainLoop.scala:93)
at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:71)
at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:66)
at sbt.Using.apply(Using.scala:25)
at sbt.MainLoop$.runWithNewLog(MainLoop.scala:66)
at sbt.MainLoop$.runAndClearLast(MainLoop.scala:49)
at sbt.MainLoop$.runLoggedLoop(MainLoop.scala:33)
at sbt.MainLoop$.runLogged(MainLoop.scala:25)
at sbt.StandardMain$.runManaged(Main.scala:57)
at sbt.xMain.run(Main.scala:29)
at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:57)
at xsbt.boot.Launch$.withContextLoader(Launch.scala:77)
at xsbt.boot.Launch$.run(Launch.scala:57)
at xsbt.boot.Launch$$anonfun$explicit$1.apply(Launch.scala:45)
at xsbt.boot.Launch$.launch(Launch.scala:65)
at xsbt.boot.Launch$.apply(Launch.scala:16)
at xsbt.boot.Boot$.runImpl(Boot.scala:32)
at xsbt.boot.Boot$.main(Boot.scala:21)
at xsbt.boot.Boot.main(Boot.scala)
error[0m] [0mjava.io.IOException: Bad file descriptor[0m
error[0m] [0mUse 'last' for the full log.[0m
Any one know which file is Bad file descriptor. And How to solve this problem.
The error happens because standard input get redirected from /dev/null by nohup - you get the same error if you do play start < /dev/null. The sbt process starts the actual server in a separate process, the sets itself up to display logs and wait for you to type Ctrl-D or Ctrl-C. It uses JLine to wait for user input, which attempts to attach to the standard input as a terminal. /dev/null can't be used in this way, so it dies complaining of a bad file descriptor. However, the background server process continues running.
If you want to start Play non-interactively, you need to use the stage task. See Using the stage task in the Play documentation.
Ok, so I'm trying to configure and install svnserve on my Ubuntu server. So far so good, up to the point where I try to configure sasl (to prevent plain-text passwords).
So; I installed svnserve and made it run as a daemon (also installed it as a startup script with the command svnserve -d -r /var/svn).
My repository is in /var/svn and has following configuration (to be found in /var/svn/myrepo/conf/svnserve.conf) (I left comments out):
[general]
anon-access = none
auth-access = write
realm = my_repo
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256
Over to sasl, I created a svn.conf file in /usr/lib/sasl2/:
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/my_sasldb
mech_list: DIGEST-MD5
I created it in that folder as the article at this link suggested: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl (and also because it existed and was listed as a result when I executed locate sasl).
Right after that I executed this command:
saslpasswd2 -c -f /etc/my_sasldb -u my_repo USERNAME
Which also asked me for a password twice, which I supplied. All going great.
When issuing the following command:
sasldblistusers2 -f /etc/my_sasldb
I get the - correct, as far as I can see - result:
USERNAME#my_repo: userPassword
Restarted svnserve, also restarted the whole server, and tried to connect.
This was the result from my TortoiseSVN client:
Authentication error from server: SASL(-13): user not found: unable to canonify
user and get auxprops
I have no clue at all in what I'm doing wrong. I've been scouring the web for the past few hours, but haven't found anything but that I might need to move the svn.conf file to another location - for example, the install location of subversion itself. which svn results in /usr/bin/svn, thus I moved the svn.conf to /usr/bin (although that doesn't feel right to me).
Still doesn't work, even after a new reboot.
I'm running out of ideas. Anyone else?
EDIT
I tried changing this (according to what some other forums on the internet told me to do): in the file /etc/default/saslauthd, I changed
START=no
MECHANISMS="pam"
to
START=yes
MECHANISMS="sasldb"
(Actually I had already changed START=no to START=yes before, but I forgot to mention it). But still no luck (I did reboot the whole server).
It looks like svnserve uses default values for SASL...
Check /etc/sasl2/svn.conf to be readable by the svnserver process owner.
If /etc/sasl2/svn.conf is owned by user root, group root and --rw------, svnserve uses the default values.
You will not be warned by any log file entry..
see section 4 of https://svn.apache.org/repos/asf/subversion/trunk/notes/sasl.txt:
This file must be named svn.conf, and must be readable by the svnserve process.
(it took me more than 3 days to understand both svnserve-sasl-ldap and this pitfall at the same time..)
I recommend to install the package cyrus-sasl2-doc and to read the section Cyrus SASL for System Administrators carefully.
I expect this is caused by the SASL API for the call
result = sasl_server_new(SVN_RA_SVN_SASL_NAME,
hostname, b->realm,
localaddrport, remoteaddrport,
NULL, SASL_SUCCESS_DATA,
&sasl_ctx);
if (result != SASL_OK)
{
svn_error_t *err = svn_error_create(SVN_ERR_RA_NOT_AUTHORIZED, NULL,
sasl_errstring(result, NULL, NULL));
SVN_ERR(write_failure(conn, pool, &err));
return svn_ra_svn__flush(conn, pool);
}
as you may see, handling the access failure by svnserve is not foreseen, only Ok or error is expected...
I looked in /var/log/messages and found
localhost svnserve: unable to open Berkeley db /etc/sasldb2: No such file or directory
When I created the sasldb to the above file and got the permissions right, it worked. Looks like it ignores or does not use the sasl database path.
There was another suggestion that rebooting solved the problem but that option was not available to me.