expect with cron not as manually - ssh

backup.sh has :
#!/bin/bash
expect backup.exp
tr -d '\15\32' < backup.templog > backup.log
backup.exp has next content:
#!/usr/bin/expect -f
puts "----------------- [exec date +%Y.%m.%d\ %H:%M:%S] ------ exp start -----\n"
spawn ssh root#someIP2
expect "# "
send "su - postgres\r"
expect "\$ "
send "ls -lh db.dump.gz\r"
send exit\r
send exit\r
interact
when I run manually like next:
bash backup.sh >> backup.templog 2>&1
I get next, which I like:
spawn ssh root#someIP
Linux db01 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Sep 2 11:06:02 2015 from someIP2
root#db01:~# su - postgres
postgres#db01:~$ ls -lh /var/lib/postgresql/db.dump.gz
-rw-r--r-- 1 postgres postgres 218M Sep 2 10:39 /var/lib/postgresql/db.dump.gz
postgres#db01:~$ exit
logout
root#db01:~# exit
logout
Connection to someIP2 closed.
but with cron (has a line):
* * * * * bash backup.sh >> backup.templog 2>&1
I get only next:
spawn ssh root#someIP2
Linux db01 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Sep 2 11:04:13 2015 from someIP1
root#db01:~# su - postgres
postgres#db01:~$
Can I get the same with cron and manually?

Related

SSH protocol v.1 is no longer supported

Trying to scp files to my server like I've done every day for years... got this weird error today:
client$ scp filename.file server:/path/to/somewhere/
SSH protocol v.1 is no longer supported
client$ echo $?
255
The file does not show up on my server like it would normally after running this command.
This error only appears on scp commands. Using ssh to get into my server works fine.
Has anyone seen this before? How do I go about debugging this? Here's some version info:
client$ ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020
client$ apt show openssl
Package: openssl
Version: 1.1.1f-1ubuntu2
server$ apt show openssh-server
Package: openssh-server
Version: 1:7.2p2-4ubuntu2.10
server$ sshd -V
unknown option -- V
OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g 1 Mar 2016
(note that I've added hostnames "client" and "server" for clarity)
In my sshd_config, it shows Protocol 2
server$ cat /etc/ssh/sshd_config | grep Protocol
Protocol 2
I'm running Ubuntu 16.04 on my server, which should have maintenance updates through today.
Let me know if I should run any other operations. Server is local network only, but I still want to make sure it's hardened.
Ugh, it was a typo... Keeping the post up for others who bang their head against the wall on this as I couldn't find any info on this error message from googling.
It's not in the ssh command (removed various parts for privacy), but I was supplying a port:
scp -p3122 file server:/path/
But it really should be:
scp -P3122 file server:/path/
(Use a capital 'P')
I have the same message with the command 'SSH'.
I fix the problem: that work ONLY if you use 3 elements: ssh server -l user -p port ..
And the party continue..

Raspberry pi2 model B, "Access Point, hostapd" setup issue

Working with Raspberry Pi2, ModelB with below configurations:
$ uname -a
Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
I have a MediaTek usb-adapter as below:
$ lsusb | grep 76
Bus 001 Device 004: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
When trying to start "hostapd" for creating access-point, the below error is reported:
$ sudo /usr/local/bin/hostapd -ddd /etc/hostapd/hostapd.conf
random: Trying to read entropy from /dev/random
Configuration file: /etc/hostapd/hostapd.conf
Line 2: invalid/unknown driver 'mt7601u'
1 errors found in configuration file '/etc/hostapd/hostapd.conf'
However, the driver does exist,
$ ls /lib/modules/4.9.59+/kernel/drivers/net/wireless/mediatek/mt7601u
-rw-r--r-- 1 root root 126932 Oct 30 14:36 mt7601u.ko
Can someone please help point out what is going wrong here ? why is it not able to find the driver ?

shuf generates "Bad file descriptor" error on nfs but only when run as a background process

Here is an interesting mystery ...
This code ...
shuf $TRAINING_UNSHUFFLED > $TRAINING_SHUFFLED
wc -l $TRAINING_UNSHUFFLED
wc -l $TRAINING_SHUFFLED
shuf $VALIDATION_UNSHUFFLED > $VALIDATION_SHUFFLED
wc -l $VALIDATION_UNSHUFFLED
wc -l $VALIDATION_SHUFFLED
generates this error ...
shuf: read error: Bad file descriptor
8122 /nfs/digits/datasets/com-aosvapps-distracted-driving3/databases/TrainImagePathsAndLabels_AlpineTest1.csv
0 /nfs/digits/datasets/com-aosvapps-distracted-driving3/databases/TrainImagePathsAndLabels_AlpineTest1_Shuffled.csv
shuf: read error: Bad file descriptor
882 /nfs/digits/datasets/com-aosvapps-distracted-driving3/databases/ValImagePathsAndLabels_AlpineTest1.csv
0 /nfs/digits/datasets/com-aosvapps-distracted-driving3/databases/ValImagePathsAndLabels_AlpineTest1_Shuffled.csv
but ONLY when I run it as a background job like so ...
tf2$nohup ./shuffle.sh >> /tmp/shuffle.log 2>&1 0>&- &
[1] 6897
When I run it directly in an interactive shell, it seems to work fine.
tf2$./shuffle.sh > /tmp/shuffle.log
I am guessing that this has something to do with the fact that both the input and output files reside on an nfs share on a different aws ec2 instance.
The severing of stdin, stderr and stdin in the background process example is suspicious. This is done so that the process will not die if the terminal session is closed. I have many other commands that read and write from this share without any problems at all. Only the shuf command is being difficult.
I am curious as to what might be causing this and if it is fixable without seeking an alternative to shuf?
I am using shuf (GNU coreutils) 8.21 on Ubuntu 14.04.5 LTS.
tf2$which shuf
/usr/bin/shuf
tf2$shuf --version
shuf (GNU coreutils) 8.21
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Paul Eggert.
tf2$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
UPDATE: eliminating the severing of STDIN makes the problem go away
ie. if instead of doing this ...
$nohup ./shuffle.sh > /tmp/shuffle.log 2>&1 0>&- &
I do this ...
$nohup ./shuffle.sh > /tmp/shuffle.log 2>&1 &
the "Bad descriptor" error goes away.
However, the severing of stdin/stdout/stderr is there to ensure that killing the terminal session will not kill the process, so this solution is not entirely satisfactory.
Furthermore, it only seems be be necessary to do this for shuf. None of other commands which read files from this file system cause any errors.
This turned out to be a bug in glibc.
The details are here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25029
The work-around is simple:
instead of
shuf $TRAINING_UNSHUFFLED > $TRAINING_SHUFFLED
do
shuf < $TRAINING_UNSHUFFLED > $TRAINING_SHUFFLED
Thanks to Pádraig Brady on the coreutils team.

Jenkins Publish Over SSH Plugin on MacOS limits to 130MB and frezze

In Jenkins test project i have in Execute shell:
dd if=/dev/urandom of=ios_512MB bs=531628032 count=1
and i have checked and configured Send files or execute commands over SSH after the build runs
When i run it i see:
Started by user X
Building remotely on ios in workspace /data/workspace/test
[test] $ /bin/sh -xe /var/folders/9b/s86tztx90bb9c_73gtynfzx80000gn/T/hudson8582983867531973712.sh
+ dd if=/dev/urandom of=ios_512MB bs=531628032 count=1
1+0 records in
1+0 records out
531628032 bytes transferred in 44.384345 secs (11977828 bytes/sec)
SSH: Connecting from host [jenkins2.local]
SSH: Connecting with configuration [jenkins.builds] ...
I see on Network traffic this connection, and its stops. On sftp i have:
ls -lh
-rw------- 1 10048 10047 130M Apr 16 09:56 ios_512MB
On windows/ubuntu all works well. How to fix it?
Fixed by Execute Shell:
echo "mkdir ${short}/${date}
mkdir ${short}/${date}/${RANDSTR}
put ${WORKSPACE}${location}${n}${format} ${short}/${date}/${RANDSTR}/
put ${WORKSPACE}${location}${n}.html ${short}/${date}/${RANDSTR}/" | sftp -o StrictHostKeyChecking=no -P 2222 -i ~/.ssh/id_rsa jenkins.builds#sftp.example.com

Why doesn't setting the SUID bit in OpenBSD set effective and saved UIDs to executable file owner?

I am using a fresh install of OpenBSD 5.3 as a guest OS on Parallels for Mac:
$ uname -a
OpenBSD openbsd.localdomain 5.3 GENERIC#53 amd64
To my surprise, a binary file owned by root with its SUID bit set runs with UIDs as if the SUID was not set. That is, when UID 1000 runs such a program, the program starts in state:
<real_uid, effective_uid, saved_uid> = <1000, 1000, 1000>
and not in state:
<real_uid, effective_uid, saved_uid> = <1000, 0, 0>
as expected.
Why is this the case?
Here are the details regarding how I found the issue:
I have written an interactive C program (compiled as setuid_min.bin) for evaluating setuid behaviour in different Unix systems. The program lives in a subdirectory of UID 1000's home directory, and the sudo command is used to change ownership and SUID; then the program is run and I enter the uid to report the real, effective, and saved UIDs of the process:
$ sudo chown root:staff setuid_min.bin
$ ls -l | grep 'setuid_min\.bin$'
-rwxr-xr-x 1 root staff [...] setuid_min.bin
$ sudo chmod a+s setuid_min.bin
$ ls -l | grep 'setuid_min\.bin$'
-rwsr-sr-x 1 root staff [...] setuid_min.bin
$ ./setuid_min.bin
uid
1000 1000 1000 some_pid
exit
$
Note that some_pid above is the pid of the setuid_min.bin process. The program reports the real UID, effective UID, and saved UID by reporting the output of the following shell command:
ps -ao ruid,uid,svuid,pid | grep '[ ]my_pid$'
where my_pid is the pid is reported by getpid(). My only guess as to why this might be the case is that OpenBSD has some underlying permissions structure that is using the ownership/permissions of the directory where setuid_min.bin resides, or that is not actually changing ownership/SUID bit when an unprivileged user uses sudo to change file permissions.
Most likely your binary is in one of the default partitions that are mounted "nosuid". The default fstab the install script creates will by mount everything nosuid unless it's known to contain suid binaries.