I am wondering if there is a way to temporary change tmux prefix depending on the active session.
I manage multiple sessions with tmux to work in different tasks or projects in my local desktop. But I sometimes need to work on remote systems where it is also useful to open multiple panes, windows or even distinct sessions.
Opening a remote tmux session inside my local tmux works fine, but I need to press the prefix key twice (I have a map to send itself on double press) every time I want to issue a (remote) tmux command.
This is very annoying because most times I end up sending it to my local tmux unintentionally.
If I could change local prefix only for a given session (or, at least, while that session is active) it would be wonderful.
Temporary disabling it also could be enought because I can define an alternate prefix to use it only when my primary one is disabled.
Any suggestion will be welcomed.
I answer myself:
It is as easy as not specifying the -g modifier in the set prefix command.
For example, in my case that my usual prefix is tab key, to use regular Ctrl+b prefix in the current session:
[tab]:set prefix C-b
Related
How can I change the user's password over ssh connection (not via browser interface) on the UBNT (Ubiquity Network) device, more specifically airOS8 WA v8.x board?
I want to avoid the ridiculous restriction imposed by their web interface on the password complexity (the only thing they don't require in the password is the unicorn's blood). I don't feel comfortable with someone else telling me what my passwords should look like (for my own well being, of course), so I'd like to change it via ssh connection, where this restriction is not being imposed.
I followed the discussion on their forums, which is just a useless bike-shedding over the opinions if the developers should impose such restrictions (without the switch to turn that off) or not.
I found the way to do this and wanted to share with others, who need to do the same thing.
First, log in to your device over an ssh connection. Then, issue a passwd command to change your password. If you now just reboot your device, the new password won't be saved, so read on.
Next, you need to copy the new password hash to a file named /var/tmp/system.cfg. So, first, type cat /etc/passwd, to see the new password hash, which should look something like this:
ubnt:$1$ssssssss$hhhhhhhhhhhhhhhhhhhhhh:0:0:Administrator:/etc/persistent:/bin/sh
where ssssssss is the Salt and hhhhhhhhhhhhhhhhhhhhhh is the Hash of the new password. We need to copy all that to the /var/tmp/system.cfg file, so type:
vi /var/tmp/system.cfg and in there, find the line that starts with users.1.password= and change it to be like this (press 'I' for Insert operation):
users.1.password=$1$ssssssss$hhhhhhhhhhhhhhhhhhhhhh
where Salt and Hash will be something randomly generated. When you finish changing that line, press Escape key and then save/quit the file (pressing colon, 'w', 'q' and Enter key, like ':wq')
Once you're back in the shell, type save to save this configuration permanently and then type reboot to check if your password survived the reboot process.
That should be it.
Thanks, but much better is to use a hash of default password ubnt, to get it, just run grep users.1.password /var/etc/default.cfg
I'm running a Exit-Relay from VMware-Ubuntu 16.04 and my Exit-Relay works great-i have all the flags that i need- Exit, Fast, HSDir, Running,Stable,V2Dir, Valid.
now i want to control my Exit-Relay and allow access to the people i want or deny it from the people i don't want.
i used iptables for it and its not working.
is there any way to do that?
one more:
i can set in my torrc file to use my Exit-Relay, or my Tor-Bridge. but, they are not working together because they both running from the same ip-ssh.
is there a way to set them to still run?
i know its not the meaning of the tor but still i want to do that
I'm deploying virtual guests this way:
salt-run virt.init vmtest 2 2048 salt://images/ubuntu-image.qcow2
It only partially works; vmtest is created and its key is added to the master, but the new minion never connects. So I pull up the vnc interface (which works fine) to see what's going on from the minion end, and...can't log in, because I don't know what credentials to use. Oops.
How do I specify initial login credentials when creating a VM with virt.init?
Well, this may not be exactly what you were looking for, but you can use libguestfs-tools in order to set a password on the image itself.
In salt, you can use cmd.run or pass it in a state to change the password after you install libguestfs-tools like so:
salt 'hypervisor' cmd.run "virt-sysprep --root-password password:'myrootpassword' -a /path/to/image.img"
or
update_pass:
cmd.run:
- name: virt-sysprep --root-password password:'myrootpassword' -a /path/to/image.img
Side note:
If you create or update the image you use to spawn new vms to pre-install salt, and update the /etc/salt/minion conf to set your master, and set it to come up at your desired run level, you should be able to work out a solution where the minion connects on creation.
Good luck, I hope this helps.
We have increased the -n parameter in broker/db.pf file.We restarted the server and when we check in promon its still showing the same number of users. How do we increase the -n parameter?
I know you answered this yourselves but for future users a real answer can be good. There are several ways to set parameters like -n. This answer really applies to changing all startup parameters (but not what values are "good").
How you change this value depends on how you start your database. See below.
NB 1: you should be aware of your licensing plan before changing this number and contact your sales contact if needed.
NB 2: you should be aware that changing startup parameters can affect performance etc. Test new values in a separate environment before moving them to production.
NB 3: backup all files before messing around...
Managed Database
A managed database is a database that is handled by the AdminServer. OE Management is not needed for this approach. A working installation of OE Explorer is however recommended.
The managed database is started (and stopped etc) via either the web based OE Explorer interface or the dbman command line utility.
Settings are stored in conmgr.properties under your Progress installation. You can edit this file manually (save a copy first...) or via the OE Explorer (recommended way).
You will have a line like this in the file:
maxusers=20 # -n
Edit the number to your liking with your favourite editor.
You can also change this in the OE Explorer:
Log in to OE Explorer. Default location is http://servername:9090/.
Locate and click on the database (if it's not there it's not handled by the adminserver - see below).
Select Configuration
Select Configuration (again, not "servergroup")
Click EDIT
-n (or Max users) is located in the first group of settings ("General"). See picture below.
Edit the value and don't forget to save.
Scripted Database
A scripted database is a database that started with a custom script (or also directly from command line). The actual startup could be handled by crontab, a user, the server generic startup script etc.
The OE AdminServer is not "aware" of this database. (You can make the AdminServer "a little" aware of it by running the dbagent command line utility with certain parameters. Read more about this in the manual).
You could generally divide into two ways of handling the script: with parameters in it or with parameters in a separate parameter file (often with the extension .pf).
Script with parameters in it
With this approach you store all parameters in the actual startup script.
proserve <dbname> -H <hostname> -S <serviceport> -n 10 -B 10000 -spin 10000 etc..
Script with a separate parameter file
With this approach you store the parameters in a separate file.
proserve <dbname> -pf /path/to/file/file.pf
The .pf-file can be formatted like the parameters in the command line:
-db <dbname> -H <hostname> -S <service> etc.
Or with newlines (this allows for comments in the file):
# Main database
-db <dbname>
-H <hostname>
-S <service>
You can also mix these two approaches.
Sources:
OE Management and OE Explorer
OE Database Management
In my app I ask users to register using a unique name. The app creates a directory for them with that name that they then can work with, saving files, etc.
I hadn't really thought about screening for other than alpha-numeric for the name. However, I ran across a thread somewhere than said to make sure not to create directory names that match a unix command name.
Is this a legitimate risk? If so, how might one programmatically screen for such an occurrence? I'm also curious how such a scenario might play out to illustrate the problem (exploit?). That last part is academic interest only, of course.
Generally, it doesn't matter(has no obvious security risk). Most softwares, for example shell, search a unix command based on some enviroment variables(like PATH). So even if your created directory matches a unix command like "cd", it can only be used as a parameter to other unix command, like cd cd.
However, if another application search the unix command based on other approaches like searching some directories, it may lead to security breaches.
The only way I can think of that being a risk is if you're going to turn around and process those user names through command-line functions. You would want to be careful to escape the user names anywhere that they could be interpreted as a command...though off the top of my head, with strictly alphanumeric user names, you'd have to go to a lot of trouble to run into such a risk.
If you decided anyway that you wanted to ensure that the username didn't match an application on the path of the creating process, you could shell out from whatever your app environment is, and evaluate the result of which $prospectiveUsername. If it returns anything other than an empty string, you know that the username is an application on the process's path.
NOTE: In the above scenario, make sure you sanitize the username before calling out to the shell command. Otherwise, you do run security risks, if e.g. the user decides to enter her username as "janedoe; rm -rf /".