#hosts(['localhost'])
def start():
import curses
screen = curses.initscr()
backup_file = db_backup.sql
local("mysql -u %s -p %s < " % (
db_username,db_name) + backup_file)
now I run this with fab start
it asks for a password, after I entered the password the screen is not responding.
Can anyone know what's happening here? if I remove curses it is working fine.
The local command is doing the prompt for the password. That expects that the terminal modes are set normally, so that if you press Enter (which sends a ^M) it is mapped into a newline (^J).
When you initialized curses using curses.initscr, that changes the terminal modes so that the mapping is not done. The curses library does its own mapping when you call getch.
If you press controlJ rather than Enter, that should appease the password prompt in the local command.
Since your example is not using curses (perhaps it does later) you can either omit it, or move the initialization down to the place where you need to use it.
In any case, you probably cannot make the local command use a password prompt in the script via curses (without assuming and relying upon special devices).
By suspending the curses, it will return to the terminal. where we can complete the restore database task.
Related
I have a samba shared directory //dc/documents. However it has strange ACL ACL:S-1-22-2-0:ALLOWED/0x0/ which I can see but cannot delete.
here you can see it's listed properly but without a user name
$ smbcacls //dc/documents / -U "MYDOMAIN\admin"
Password for [MYDOMAIN\admin]:
REVISION:1
CONTROL:SR|DP
OWNER:MYDOMAIN\Domain Users
GROUP:MYDOMAIN\Domain Users
ACL:Everyone:ALLOWED/OI|CI/
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO/FULL
ACL:CREATOR GROUP:ALLOWED/OI|CI|IO/READ
ACL:S-1-22-2-0:ALLOWED/0x0/
ACL:MYDOMAIN\Domain Users:ALLOWED/OI|CI/FULL
and when I try to delete it a strong error occurs
$ smbcacls //dc/documents / -U "MYDOMAIN\admin" -D "ACL:S-1-22-2-0:ALLOWED/0x0/ "
Password for [MYDOMAIN\admin]:
ACE 'S-1-22-2-0:ALLOWED/0x0/ ': bad permission value at ' '
However deleting / adding other ACLs do not have any problem. And I suspect because of this strange ACL, I cannot even change the ACLs from Windows either. It would simply crash explorer if I click on the "Security" tab of the shared directory's properties dialog.
Now I'm stuck here, any thoughts? Thanks!
I'm trying to set a MySQL Database in my pc for development.
Of course I've tried to change the OS
None of this options made it work.
Although when I hit the testconnection button it shows success, the OS message error keeps being shown and I cannot use my database.
Any help will be appreciated. Thanks in advance!
You have to go to the control panel, then region, then clic in the administrative tab and click on "change system regional settings" and as a final step check the box: Beta: Use Unicode UTF-8 for worldwide language support, restart your PC and try to access MySQL Workbench.
Although the option proposed by Fernando Valderrama Guayán is functional I would not recommend activating a beta version option, since depending on your configuration strange symbols could appear in the rest of the operating system.
The solution with less collateral effects would be to edit the file 'os_utils.py' in the path 'C:\Program Files\MySQL\MySQL Workbench 8.0\workbench'.
We look for the line:
process = subprocess.Popen(command, stdin = subprocess.PIPE, encoding='utf-8', stdout = subprocess.PIPE, stderr = subprocess.STDOUT, shell=True)
And we replace it with:
process = subprocess.Popen(command, stdin = subprocess.PIPE, encoding='ansi', stdout = subprocess.PIPE, stderr = subprocess.STDOUT, shell=True).
The idea is to modify the encoding parameter to the ansi encoding system.
It's a bug in MySQL Workbench 8.0.28
Using MySQL Installer, you can uninstall the workbench then install the MySQL Workbench 8.0.16.
It will work well.
I try to connect to my router using ssh in order to automatically extract some logs from it.
I developed this code below :
#!/usr/bin/expect -f
spawn ssh root#192.168.1.1
expect "Are you sure you want to"
send -- "yes\r"
expect "password"
send -- "root\r"
expect "\#"
send -- "ls\r"
expect "\#"
the problem is I expected a garbage before the prompt in the output log.
spawn ssh root#192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is SHA256:6aeE74qXMeQzg0SGJBZMIa0HFQ5HJrNqE5f3XZ6Irds.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/amin/.ssh/known_hosts).
root#192.168.1.1's password:
BusyBox v1.30.1 () built-in shell (ash)
OpenWrt Version: ALPHA
OpenWrt base: 19.07
------------------------------------
]0;root#openwrt: ~root#openwrt:~# ls
[0;0mnetwork[m
]0;root#openwrt: ~root#openwrt:~#
what's the main cause of this issue? How I can fix it?
The problem is that there are terminal escape sequences being issued, probably to control what colour the terminal uses. The easiest fix is to set the terminal type (an environment variable) to something that doesn't support colour before doing the spawn. Perhaps this will do the trick:
set env(TERM) "dumb"
If that doesn't work (it depends on exactly what is in someone's .bashrc) then you can just override the PS1 environment variable on the remote side with your first command after logging in.
# etc for logging in
expect "# "
send "PS1='# '\r"
expect "# "
# Everything should be right from here on
default: on
# description: mysqlchk
service mysqlchk
{
# this is a config for xinetd, place it in /etc/xinetd.d/
disable = no
flags = REUSE
socket_type = stream
type = UNLISTED
port = 9200
wait = no
user = root
server = /usr/bin/mysqlclustercheck
log_on_failure += USERID
only_from = 0.0.0.0/0
#
# Passing arguments to clustercheck
# <user> <pass> <available_when_donor=0|1> <log_file> <available_when_readonly=0|1> <defaults_extra_file>"
# Recommended: server_args = user pass 1 /var/log/log-file 0 /etc/my.cnf.local"
# Compatibility: server_args = user pass 1 /var/log/log-file 1 /etc/my.cnf.local"
# 55-to-56 upgrade: server_args = user pass 1 /var/log/log-file 0 /etc/my.cnf.extra"
#
# recommended to put the IPs that need
# to connect exclusively (security purposes)
per_source = UNLIMITED
}
/etc/xinetd.d #
It is kind of strange that script works fine when run manually when it runs using /etc/xinetd.d/ , it is not working as expected.
In mysqlclustercheck script, instead of using --user= and passord= syntax, I am using --login-path= syntax
script runs fine when I run using command line but status for xinetd was showing signal 13. After debugging, I have found that even simple command like this is not working
mysql_config_editor print --all >>/tmp/test.txt
We don't see any output generated when it is run using xinetd ( mysqlclustercheck)
Have you tried the following instead of /usr/bin/mysqlclustercheck?
server = /usr/bin/clustercheck
I am wondering if you could test your binary location with the linux which command.
A long time ago since this question was asked, but it just came to my attention.
First of all as mentioned, Percona Cluster Control script is called clustercheck, so make sure you are using the correct name and correct path.
Secondly, since the server script runs fine from command line, it seems to me that the path of mysql client command is not known by the xinetd when it runs the Cluster Control script.
Since the mysqlclustercheck script as it is offered from Percona, it uses only the binary name mysql without specifying the absolute path I suggest you do the following:
Find where mysql client command is located on your system:
ccloud#gal1:~> sudo -i
gal1:~ # which mysql
/usr/local/mysql/bin/mysql
gal1:~ #
then edit script /usr/bin/mysqlclustercheck and in the following line:
MYSQL_CMDLINE="mysql --defaults-extra-file=$DEFAULTS_EXTRA_FILE -nNE --connect-timeout=$TIMEOUT \
place the exact path of mysql client command you found in the previous step.
I also see that you are not using MySQL connection credentials for connecting to MySQL server. mysqlclustercheck script as it is offered from Percona, it uses User/Password in order to connect to MySQL server.
So normally, you should execute the script in the command line like:
gal1:~ # /usr/sbin/clustercheck haproxy haproxyMySQLpass
HTTP/1.1 200 OK
Content-Type: text/plain
Where haproxy/haproxyMySQLpass is the MySQL connection user/pass for HAProxy monitoring user.
Additionally, you should specify them to your script's xinetd settings like:
server = /usr/bin/mysqlclustercheck
server_args = haproxy haproxyMySQLpass
Last but not least, the signal 13 you are getting is because you try to write something in a script run by xinetd. If for example in your mysqlclustercheck you try to add a statement like
echo "debug message"
you probably going to see the broken pipe signal (13 in POSIX).
Finally, I had issues with this script using SLES 12.3 and I finally manage to run it not as 'nobody' but as 'root'.
Hope it helps
I've been messing around with IO#popen and different programs, and having some trouble with interactive processes.
Here's a stripped down version of the script:
def test(command, string)
IO.popen(command, 'a+') do |pipe|
puts "Prompt: #{pipe.read(5)}" # Just to show whether data is read in
pipe.puts string
end
end
I'm seeing various behavior with a few different interactive processes, and trying to understand why.
$ test('pt-kill --user user --ask-pass --print', 'password')
=> This successfully reads in the prompt, and the password is successfully written
to the script. Works as desired. (This is a perl script from Percona)
$ test('telnet', 'quit')
=> Blocks indefinitely trying to read the prompt. In the process of hacking around,
found that calling 'pipe.close_write' prior to the read would allow the read to
complete. Why?
$ test('mysql -u user -p -e "SELECT 1 FROM DUAL", 'password')
=> Echoes full prompt to the screen, but is still blocking on the first read.
Adding a 'pipe.close_write' does nothing.
I've been trying to understand the differences, but am at a loss. Anyone have an explanation?