Is it possible to generate a new overcloudrc file? One is created during deployment but ours was deleted during some other issues.
If someone knows the command to do so....
Take some overcloudrc, change IPs with control plane VIP, you can get this from any of the controller nodes (I hope you still have stackrc, which has only undercloud IP as variable). For OS_PASSWORD, you can login to any of the overcloud controller node and get the output of "sudo hiera keystone::admin_password".
I hope this will solve your problem.
Related
Openstacks configuration page says (highlights and numbering by me):
OpenStackClient looks for a file called clouds.yaml in the following locations: I) current directory II) ~/.config/openstack III) /etc/openstack
but when I place an openstack clouds.yaml at I-III), it doesn't read any data from it. openstack configuration show at least is not showing the additional information and calls that would require said information fail due to that information not being available to openstack.
I used the command: openstack configuration show
openstack configuration show won't show any information from your clouds.yaml unless you either specify --os-cloud <name> on the command line or set the OS_CLOUD environment variable (because otherwise how does it know which cloud configuration to use?).
I am using VS Code for R in a remote Unix environment. My goal is to perform regular interactive job while editing the script on the remote server as what people usually do in RStudio locally.
For the HPC server I use, there're a admin node (i.e. login node) and a compute node (mostly for interactive job).
Usually what I did, is to login in via admin node first (via ssh), and then request certain resourses (e.g. memories, cpu, etc) from the compute node, and then do
ssh $SLURM_JOB_NODELIST
which transfer me from 'admin' to 'compute' node in the terminal.
And lastly, I do "R: Create R terminal". However, I wouldn't be able to check if this R terminal is operated on the compute node or the admin node.
There's a way to go around, by using 'radian' package and set "r.alwaysUseActiveTerminal" as "true". However, via this way, my data viewer wouldn't be attached and I couldn't view my data in the 'workspace'. As this,
enter image description here
The trickiest part is I need to use 'ssh' to switch between 'admin' and 'compute node'. While at the same time the whole left panel of VS Code, including the File Viewer, is still based on the 'admin' node.
Any suggestions and advice are welcome! Thanks a lot!
In the R syntax, use Sys.info() to find the hostname of the computer R is running on:
> Sys.info()["nodename"]
nodename
"node002.cluster"
This is my first time setting up an OpenStack instance on Ubuntu and I'm having some difficulty with setting up additional compute nodes. I've set up a controller node following the devstack instructions here with the stable/xena release and I'm trying to add an additional compute node so I've gone through the set up here but I have a few questions.
The additional compute node does not show up as a hypervisor (although it shows up under the compute service list), does someone have a resource for how to add the compute node as a hypervisor?
I ran the discover_hosts tool within the devstack repo so that the compute node gets picked up by the db but what transport url and database connections should the additional compute node use? Do I copy the transport url and database connection url used by the controller node?
Does Openstack use the resources (storage, RAM, cpus) of the additional compute node to create new VMs as well?
If someone could provide advice on how to go about setting up this compute node that would be greatly appreciated.
Thanks in advance!
Note: In the comments below I mention some steps I tried so I'll just sum them up here with their results.
nova-manage cell_v2 discover_hosts --verbose gave this output:
Found 3 cell mappings.
Skipping cell0 since it does not contain hosts. Getting computes from cell 'cell1': <random_string1> .
Found 0 unmapped computes in cell <random_string1>.
Getting computes from cell: <random_string2>.
Checking host mapping for compute host 'vmname': <random_string3>.
Found 0 unmapped computes in cell <random_string2>
So the command runs but I think theres an issue with how things are set up in the db since the compute node doesn't seem to be linked to a cell.
nova-manage cell_v2 list_hosts output gives 2 hosts, the controller and the vm I am trying to add but the cell name for the compute node I'm trying to add is None.
nova-manage cell_v2 list_cells output gives 3 cells, one with no name value but it has the same cell uuid as <random_string2> in the above comment with a transport url that has no /nova_cell1 ending and the db connection string is the same as cell0.
So I think there is an issue with how the compute node is trying to be added to the db?
1, try run nova-manage cell_v2 discover_hosts in controller node to discover hypervisor.
2, you should not do anything if the step 1 works.
3, yes if the step 1 works.
CPU utilization is high on openstack controller node.
I want to know how to replace the controller node or any other way to fix this issue.
I dont find any documentation for this online. Need help.
Add a new Node as a Controller node, HA setup
After new Controller works and enough (a strong Node), deactivate first one.
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.