I am trying to connect a remote machine in python. I used telnetlib module and could connect to machine after entering login id and password as
tn = Telnet("HOST IP")
tn.write("UID")
tn.write("PWD")
After entering password, the terminal connects to the remote machine which is a linux based software [having its own IP address(HOST IP).]
Then after If I try to give a command e.g. tn.write("cd //tmp/media/..) to go to its various folders then it does not work and when checked to see what the screen is showing with
tn.read_very_eager()
error comes up as :
""\r\n\r\n\r\nBusyBox v1.19.4 (2012-07-19 22:27:43 CEST) built-in shell (ash)\r\n
Enter 'help' for a list of built-in commands.\r\n\r\n~ # ""
I wanted to know if there is any method in Python as we have in PERL as $telnet->cmd ("cd //tmp/media/..)
Any suggestions are welcomed if you can give an example!!!
You should try to login to the machine using telnet, then you will notice you will login into BusyBox. That string you print not an error it is hte normal BusyBox prompt.
It might not be what you expected, I only know BusyBox from Linux boxes that were unable to properly boot.
Related
I cant get codecollaborator to upload files to for code review. I suspect I am missing some config. I have been scouring perforce and smartbear and stackover flow pages for a couple hours now no luck
CENTOS7
p4 (cant seem to find the version)
Collaborator Enterprise v11.2.11200
My p4 works totally fine have been using for months now to create CLs and submit. But now i need to upload files for code reviews.
command i ran to setup ccollab:
wget https://s3.amazonaws.com/downloads.smartbear/collaborator/11.2.11200/ccollab_client_11_2_11200_unix.sh
chmod +x ccollab_client_11_2_11200_unix.sh
./ccollab_client_11_2_11200_unix.sh
(went through install accepting entering as prompted)
ccollab login https://<codecollaborator_server> <username>
the above logs in fine no errors
ccollab --no-browser --scm perforce --server-proxy-host https://codecollaborator_server --p4user <username> --p4charset utf8 --p4client local_workspace_name --p4 /bin/p4 set
the try to upload a file
ccollab --debug addchangelist new 123456789
and get the following output:
Connecting to server at https://
Connected to Collaborator Enterprise v11.2.11200
Connected as:
Attaching changelists to review
Auto-detecting SCM System for '/my/workspace/path'
Checking client configuration for '/my/workspace/path'.
ERROR: Could not configure SCM system:
SCM system could not be auto-detected, but there was an error: Cannot run program "accurev" (in directory "/my/workspace/path"): error=2, No such file or directory
I tried to find what the "accurev" package is or how to use it but no joy.
Accurev is a different source control system. Sounds like Code Collab doesn't know that it's supposed to be using Perforce?
I am connecting to SSH via terminal (on Mac) and run a Paramiko Python script and for some reason, the two sessions seem to behave differently. The PATH environment variable is different in these cases.
This is the code I run:
import paramiko
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('host', username='myuser',password='mypass')
stdin, stdout, stderr =ssh.exec_command('echo $PATH')
print (stdout.readlines())
Any idea why the environment variables are different?
And how can I fix it?
The SSHClient.exec_command by default does not allocate a pseudo terminal for the session. As a consequence a different set of startup scripts is (might be) sourced (particularly for non-interactive sessions, .bash_profile is not sourced). And/or different branches in the scripts are taken, based on an absence/presence of TERM environment variable.
To emulate the default Paramiko behavior with the ssh, use the -T switch:
ssh -T myuser#host
See the ssh man:
-T Disable pseudo-tty allocation.
Contrary, to emulate the default ssh behavior with Paramiko, set the get_pty parameter of the exec_command to True:
def exec_command(self, command, bufsize=-1, timeout=None, get_pty=False):
Though rather than working around the issue by allocating the pseudo terminal in Paramiko, you should better fix your startup scripts to set the same PATH for all sessions.
For that see Some Unix commands fail with "<command> not found", when executed using Python Paramiko exec_command.
Working with the Channel object instead of the SSHClient object solved my problem.
chan=ssh.invoke_shell()
chan.send('echo $PATH\n')
print (chan.recv(1024))
For more details, see the documentation
I am using following code to get ANDROID_ID
String androidID = Secure.getString(getContext().getContentResolver(),
Secure.ANDROID_ID);
But for work profile I am getting a different ANDROID_ID for the same app than when deployed as a normal user app.
Are two different ANDROID_IDs generated for work and personal ?
I definitely see that behavior on our devices. You can test it in the command line using adb. Here's a sample script: (the XXXXX returned is just me anonymizing the android_IDs from our system).
$ adb shell pm list users
Users:
UserInfo{0:Owner:13} running
UserInfo{10:Work profile:30} running
$ adb shell settings --user 0 get secure android_id
XXXXXX6d13c171c
$ adb shell settings --user 10 get secure android_id
XXXXXX6b3d28a2c9
I would like to change my jupyter notebook server's password to something else. I see on Jupyter's documentation (http://jupyter-notebook.readthedocs.org/en/latest/public_server.html) how to prepare a password for ostensibly a new server but not how to change an existing one.
Can I simply:
Generate a new SHA hash for a password as the documentation above specifies
Replace the password in the PWDFILE environment variable (located in jupyter_notebook_config.py)
Restart the jupyter server
Basically, I'm asking because I don't want to confuse and/or mess up the authentication system by just changing things.
From version 5.0, you can easily change current password with jupyter notebook password command.
Note : I tested it on windows environment.
Start -> Anaconda Powershell Prompt
It will display you the prompt like below:
(base) PS C:\yourName >
Enter below command :
(base) PS C:\yourName > jupyter notebook password
It will ask you for new password
Currently its 2022 and the jupyter notebook password still works
Reposting as an answer:
The process to change the password should be just the same as setting it in the first place. Jupyter hashes the password you enter, and compares it with the hash it loaded from the config file. It doesn't copy the hash to any other persistent storage (though it does store it in memory, so you will need to restart the notebook server).
I'm not sure how environment variables are involved - I don't think the instructions use any for the password.
As we all know by now, the only way to run tests on iOS is by using the simulator. My problem is that we are running jenkins and the iOS builds are running on a slave (via SSH), as a result running xcodebuild can't start the simulator (as it runs headless). I've read somewhere that it should be possible to get this to work with SimLauncher (gem sim_launcher). But I can't find any info on how to set this up with xcodebuild. Any pointers are welcome.
Headless and xcodebuild do not mix well. Please consider this alternative:
You can configure the slave node to launch via jnlp (webstart). I use a bash script with the .command extension as a login item (System Preferences -> Users -> Login Items) with the following contents:
#!/bin/bash
slave_url="https://gardner.company.com/jenkins/jnlpJars/slave.jar"
max_attempts=40 # ten minutes
echo "Waiting to try again. curl returneed $rc"
curl -fO "${slave_url}" >>slave.log
rc=$?
if [ $rc -ne 0 -a $max_attempts -gt 0 ]; then
echo "Waiting to try again. curl returneed $rc"
sleep 5
curl -fO "${slave_url}" >>slave.log
rc=$?
if [ $rc -eq 0 ]; then
zip -T slave.jar
rc=$?
fi
let max_attempts-=1
fi
# Simulator
java -jar slave.jar -jnlpUrl https://gardner.company.com/jenkins/computer/buildmachine/slave-agent.jnlp -secret YOUR_SECRET_KEY
The build user is set to automatically login. You can see the arguments to the slave.jar app by executing:
gardner:~ buildmachine$ java -jar slave.jar --help
"--help" is not a valid option
java -jar slave.jar [options...]
-auth user:pass : If your Jenkins is security-enabled, specify
a valid user name and password.
-connectTo HOST:PORT : make a TCP connection to the given host and
port, then start communication.
-cp (-classpath) PATH : add the given classpath elements to the
system classloader.
-jar-cache DIR : Cache directory that stores jar files sent
from the master
-jnlpCredentials USER:PASSWORD : HTTP BASIC AUTH header to pass in for making
HTTP requests.
-jnlpUrl URL : instead of talking to the master via
stdin/stdout, emulate a JNLP client by
making a TCP connection to the master.
Connection parameters are obtained by
parsing the JNLP file.
-noReconnect : Doesn't try to reconnect when a communication
fail, and exit instead
-proxyCredentials USER:PASSWORD : HTTP BASIC AUTH header to pass in for making
HTTP authenticated proxy requests.
-secret HEX_SECRET : Slave connection secret to use instead of
-jnlpCredentials.
-slaveLog FILE : create local slave error log
-tcp FILE : instead of talking to the master via
stdin/stdout, listens to a random local
port, write that port number to the given
file, then wait for the master to connect to
that port.
-text : encode communication with the master with
base64. Useful for running slave over 8-bit
unsafe protocol like telnet
gardner:~ buildmachine$
For a discussion about OSX slaves and how the master is launched please see this Jenkins bug: https://issues.jenkins-ci.org/browse/JENKINS-21237
Erik - I ended up doing the items documented here:
Essentially:
The first problem, is that you do have to have the user that runs the builds also logged in to the console on that Mac build machine. It needs to be able to pop up the simulator, and will fail if you don’t have a user logged in — as it can’t do this entirely headless without a display.
Secondly, the XCode Developer tools requires elevated privileges in order to execute all of the tasks on the Unit tests. Sometimes you may miss seeing it, but without these, the Simulator will give you an authentication prompt that never clears.
A first solution to this (on Mavericks) is to run:
sudo security authorizationdb write system.privilege.taskport allow
This will eliminate one class of these authentication popups. You’ll also need to run:
sudo DevToolsSecurity --enable
Per Apple’s man page on this tool:
On normal user systems, the first time in a given login session that
any such Apple-code-signed debugger or performance analysis tools are
used to examine one of the user’s processes, the user is queried for
an administator password for authorization. DevToolsSecurity tool to
change the authorization policies, such that a user who is a member of
either the admin group or the _developer group does not need to enter
an additional password to use the Apple-code-signed debugger or
performance analysis tools.
Only issue is that these same things seem to be broken once I upgraded to Xcode 6. Back to the drawing board....