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
Related
We are using MariaDB v10.5.15 and clustering of Galera-4 v26.4.11.
The cluster is in the weighted quorum mode so that the primary site has more votes than the non-primary. During a network outage, the primary site with more votes prevails and continues service without the other peer.
The system needs to undergo a regular disaster recovery examination, including switching the primary site to the other peer. So, we need to change the weight assignments for the design reasons explained above.
Within MySQL client, we can set pc.weight dynamically by command like set global wsrep_provider_options="pc.weight=2";. However, this command only changes the in-memory configuration. So, if reboot the host, the MariaDB will start again with the old value written in the configuration file /etc/my.cnf.d/server.cnf.
To make the new weights non-volatile, we need to edit the below part of the configuration file. And the edit is error-prone because the file contains many other items in the same line of wsrep_provider_options, with pc.weight in the middle.
[galera]
...
wsrep_provider_options="socket.ssl=true; socket.ssl_key=/etc/pki/galera/server-key.pem; socket.ssl_cert=/etc/pki/galera/server-cert.pem; socket.ssl_ca=/etc/pki/galera/ca-cert.pem; pc.weight=2"
...
I am wondering:
Is it possible to set the pc.weight non-volatile without editing the configuration files?
Otherwise, is it possible to separate pc.weight into another .cnf file while keeping the other items of wsrep_provider_options in the original file?
We highly appreciate your help and suggestions.
No pc.weight cannot be non-volatile without editing a configuration file.
If you put it into another configuration file and start the server with --defaults-extra-file=/path/to/other/file.cnf that would pick it up.
Another option is to start another node, even an arbitrator node, on the secondary site during DR/DR testing. That node might need more than a 2 weight.
How does the primary site know the weight of a node it hadn't seen? I'm not sure. So be careful.
both plugin seems to use the same code for redis_gzip_flag and memcached_gzip_flag not provide any instructions about this flag and how to set it, as redis string doesn't have any flag support
so what is this flag?
where I set it in redis?
what number should I choose in the nginx config?
Hadn't heard of this but I found an example here, looks like you add it manually to your location block when you know the data you're going to be requesting from redis is gzipped.
I am trying to configure my asterisk to regsiter every user who tries to connect to it, and allow it to establish calls. I have read that I should set "allowguest = yes" in sip.conf.
What about the dialplan in extensions.conf ? What should I add so that all my users could make and recieve calls ? (this is my first questions).
I would go even more precise about the users : is it possible to allow only guests from one precise domain ? If yes please help find how to do it, I will be very thankful.
Guest calls will go to default context which is in general section of sip.conf
[general]
context=some_restricted_access
About dialplan for calls - you need read some book for beginner or install freepbx/other web which do dialplan for you.
No, you can't allow guests from domain. But you can try play with realm= setting or allow access from one ip by using ip-authentification.
On a RedHat 6 server, a third party application requires to be root to run and needs access to sqlplus. I have a running database, I can run sqlplus as user 'oracle'. When logged in as user root, 'sqlplus usr/pwd#dbname' works as expected. The trouble is that this agent needs to run sqlplus with no parameters and it always returns ORA-12546: TNS:permission denied.
I've read a dozen times that enabling root to launch Oracle is a security issue but I really have no other choice.
Running Oracle 11.2.0.1.0.
Any help will be much appreciated as I've googled for 2 days with no success.
From the documentation, ORA_12546 is:
ORA-12546: TNS:permission denied
Cause: User has insufficient privileges to perform the requested operation.
Action: Acquire necessary privileges and try again.
Which isn't entirely helpful, but various forum and blog posts (way too many to link to, Googling for the error shows a lot of similar advice) mention permissions on a particular part of the installation, $ORACLE_HOME/bin/oracle, which is a crucial and central part of most of the services.
Normally the permissions on that file would be -rws-r-s--x, with the file owned by oracle:dba, and this error can occur when the word-writable flag - the final x in that pattern - is not set. Anyone in the dba group will still be able to execute it, but those outside will not.
Your listener seems to be fine as you can connect remotely, by specifying #dbname in the connect string. The listener runs as oracle (usually, could be grid with HA, RAC or ASM) so it is in the dba group and can happily hand-off connections to an instance of the oracle executable.
When you connect without going via the listener, you have to be able to execute that file yourself. It appears that root cannot execute it (or possibly some other file, but this is usually the culprit, apparently), which implies the world-writable bit is indeed not set.
As far as I can see you have three options:
set the world-writable bit, with chmod o+x $ORACLE_HOME/bin/oracle; but that opens up the permissions for everyone, and presumably they've been restricted for a reason;
add root to the dba group, via usermod or in the /etc/group; which potentially weakens security as well;
use SQL*Net even when you don't specify #dbname in the connect string, by adding export TWO_TASK=dbname to the root environment.
You said you don't have this problem on another server, and that the file permissions are the same; in which case root might be in the dba group on that box. But I think the third option seems the simplest and safest. There is a fourth option I suppose, to install a separate instant client, but you'd have to set TWO_TASK anyway and go over SQL*Net, and you've already ruled that out.
I won't dwell on whether it's a good idea to run sqlplus (or indeed the application that needs it) as root, but will just mention that you'd could potentially have a script or function called sqlplus that switches to a less privileged account via su to run the real executable, and that might be transparent to the application. Unless you switch to the oracle account though, which is also not a good idea, you'd have the same permission issue and options.
I have a program that is going to take a password as input and then do a shell execute to perform a "su" (switch user) command in UNIX. However, I don't know how to pass the password variable to the UNIX su command. The language I have to use for this is pretty limited (UniBasic).
Any ideas?
Well, the best way to do that would be a setuid-root binary that ask for the password then execute whatever command is needed but it requires knowledge you say not to possess. I'd advise in looking at sudo(1) instead.
You could ssh to localhost as another user to execute whatever command you want. Or, use sudo and edit /etc/sudoers such that sudo does not ask for a password. However, there could be security implications.
EDIT: Please let me know why when you vote it down. My answer may not be perfect but at least it works. I do that myself for some licensed software that can only be run under a weird user name.
You do not want to specify the password as a command-line argument. Not so much because of #unwind's answer (scripts could be made private) but because if someone runs a list of processes, you could see the command argument and hence the password in question.
The version of su I have on my Linux server does not support such an option. I checked sudo, but it doesn't either. They want to do the prompting themselves, to ensure it's done in a safe manner and (I guess) to discourage people from putting passwords verbatim in scripts and so on.
You could also look at the 'expect' utility that was designed to script complex user inputs into a programs that weren't flexible enough to receive this input from places other than stdin.