Error When Starting OmniEvents - redhawksdr

I am attempting to install REDHAWK v1.8.2 on a fresh install of CentOS 6.4 32 bit, but I am unable to get omniNames and omniEvents to start.
sudo /sbin/service omniEvents stop
Stopping CORBA event service: omniEvents
sudo /sbin/service omniNames stop
Stopping omniNames [ OK ]
sudo /sbin/service omniNames start
Starting omniNames [ OK ]
sudo /sbin/service omniEvents start
Starting CORBA event service on port 11169: omniEvents: [25848]: Warning - failed to resolve initial reference 'NameService'. Exception: TRANSIENT
omniEvents.
I tried to verify if omniNames was really running by calling the naming client, but got an error (see below), so it seems omniNames is not successfully starting.
nameclt list
Caught a TRANSIENT exception when trying to validate the type of the
NamingContext. Is the naming service running?
As part of the debugging process, I tried to kill the omniNames process and start it a different way (see below).
sudo killall omniNames
omniNames -start
Wed Nov 13 21:08:08 2013:
Starting omniNames for the first time.
Error: cannot create initial log file '/var/omninames/omninames-orion.log':
No such file or directory
You can set the environment variable OMNINAMES_LOGDIR to specify the
directory where the log files are kept.
I'm not sure why omniNames can't create the log file, because I verified that /var/omninames folder actually exists and even starting omniNames as root yields the same error. Regardless, I set the log directory to my desktop to circumvent the error (see below).
export OMNINAMES_LOGDIR=/home/$USER/Desktop/logs
mkdir -p /home/$USER/Desktop/logs
omniNames -start
Wed Nov 13 21:09:17 2013:
Starting omniNames for the first time.
Wrote initial log file.
Read log file successfully.
Root context is IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000001000000000000005c000000010102000a00000031302e322e382e333500f90a0b0000004e616d6553657276696365000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100
Checkpointing Phase 1: Prepare.
Checkpointing Phase 2: Commit.
Checkpointing completed.
Even though it looks like omniNames successfully started, when I open another terminal window and call the naming client, I get the same error as before (see below).
nameclt list
Caught a TRANSIENT exception when trying to validate the type of the
NamingContext. Is the naming service running?
The only modification I made in the /etc/omniORB.cfg file is to add the lines for InitRef (see below).
InitRef = NameService=corbaname::localhost
InitRef = EventService=corbaloc::localhost:1169/omniEvents
Also, I am not connected to the internet so my version of CentOS has not been updated from the base version, except for the boost libraries as recommended in Appendix J of the manual (http://sourceforge.net/projects/redhawksdr/files/redhawk-doc/1.9.0/REDHAWK_Manual_v1.9.0.pdf/download).

Looks like the issue is in your configuration. You've got the wrong port in your configuration file. It should be port 11169 however you've listed port 1169.
See: http://redhawksdr.github.io/Documentation/mainch2.html#x4-120002.6 for details.
A few other observations and tricks regarding omniOrb in case this was not the issue.
Sometimes omninames/omnievents can get into a bad state. The fix is to delete the log files created by omniNames and omniEvents and restart the services. They are located:
/var/lib/omniEvents/*
/var/omniNames/*
You'll need to be root to delete those files. I always forget where they are located and often do a "locate omni | grep -i log" to remind myself but you must do this as root since they are not visible to standard users.
While it should not matter, I've personally found that using 127.0.0.1 is more reliable than localhost. For some reason, using localhost within a VM in the configuration file has caused me problems in the past. Consider using 127.0.0.1 instead of localhost. This is what the current version of the Redhawk Manual recommends as well.
You mentioned you are using Redhawk v1.8.2. As an FYI, the latest REDHAWK version in the 1.8 series is currently v1.8.5 and 1.9.0 was also recently released.
Hopefully this gets you up and running!

Related

I am trying to set up a postgresql server on arch linux but the start command returns logfile: permission denied

As explained I want to set up a PostgreSQL database (specifically for Metasploit to use as I'm running my own install of arch instead of kali linux). I have followed the instructions so far to the best of my ability although I don't have any experience with PostgreSQL or much in databases for that matter and am stuck on this error.
As you can see the server was able to be initialised at least but I don't know how to/can't get it to start.
[postgres#rt metasploit]$ initdb --locale=C --encoding=UTF8 -D /var/lib/postgres/data --data-checksums
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "C".
The default text search configuration will be set to "english".
Data page checksums are enabled.
creating directory /var/lib/postgres/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/GMT-2
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgres/data -l logfile start
[postgres#rt metasploit]$ pg_ctl -D /var/lib/postgres/data -l logfile start
waiting for server to start..../bin/sh: line 1: logfile: Permission denied
stopped waiting
pg_ctl: could not start server
Examine the log output.
If this is a noob question please just link me to the answer, as I said I have little to no experience working with databases and just want to get it up and running. I tried searching for it myself but couldn't find much of help.

Not able to connect to AWS server using linux terminal after a reboot with "sudo service sshd restart". Getting “Connection timed out” error

I was trying to edit the sshd_config file and in between that my machine crashed. When I tried again it started showing the below message-
Found a swap file by the name "/etc/ssh/.sshd_config.swp"
dated: Mon Oct 23 07:17:17 2017 [cannot be read]
While opening file "/etc/ssh/sshd_config"
dated: Mon Oct 23 22:19:04 2017
NEWER than swap file!
(1) Another program may be editing the same file. If this is the case,
be careful not to end up with two different instances of the same
file when making changes. Quit, or continue with caution.
(2) An edit session for this file crashed.
If this is the case, use ":recover" or "vim -r /etc/ssh/sshd_config"
to recover the changes (see ":help recovery").
If you did this already, delete the swap file "/etc/ssh/.sshd_config.swp"
to avoid this message.*
I deleted the .swp file but it looks like the original file got deleted. After that I ran this command "sudo service sshd restart ".
Now I am not able to connect to the AWS server using linux terminal. Can anyone please help me with this
The original file shouldn't have been deleted ... the .swp file is the in process edit.
Have you tried rebooting the instance?
If that doesn't help, you may need to recover from a snapshot. You did take a snapshot before editing the ssh config, right?

avahi-daemon doesn't start (can't create runtime directory)

I am trying to start avahi-daemon but it responds with and error
Failed to create runtime directory /opt/var/run/avahi-daemon/
That directory do exist.
Even if I delete this folder and start avahi again it creates it but still keeps saying that its a fail.
What am I doing wrong?
It's possible that such cases be linked with a lack of privileges.
=> use sudo
e.g.
sudo service dbus start
sudo service avahi-daemon start
Another issue could be the missing space of the file system. To check that do:
df -h /opt/var/run/
Result musn't be 100%.

Where should I put the "down" file to prevent Chef from starting

I am running Open Source Chef 11 Server and a dozen or so Linux and SmartOs servers running chef-client. At one point I created a file on one of my linux servers with the filename of "down" in a specific directory and that prevented the chef-client from running, even after reboot. I have since deleted this file and I cannot remember which directory I had put that file in. I can no longer find any documentation that this existed or works. Did I imagine this?
I realize the point of Chef is to have chef-client running at all times but sometimes it is useful to disable the chef-client while experimenting with the server configuration.
I believe this "down" file might be related to runit.
I think I found it.
If I create the file in /etc/sv/chef-client
# touch /etc/sv/chef-client/down
then run
# sv status chef-client
I get back
down: chef-client: 85480s; run: log: (pid 8000) 93131s
If I remove the down file I get back
down: chef-client: 85539s, normally up; run: log: (pid 8000) 93190s

Error when "Connecting Doman"

In the Redhawk IDE, when I try to connect I get the following error.
Connecting Domain, has encounterd a problem
Details are
Failed to connect
org.omg.CosNaming.NameingContextPackage.NotFound: IDL: omg.org/CosNaming/NamingContext NotFound:1.0
It does not appear that a DomainManager is getting started at all, I have the
OmniEvents and OmniOrb running and the /etc/Omni config file set up as described in the
documenation.
I have tried to delete and redo the DomanManger ConnnectionSettings with REDHAWAK_DEV
corbaname::localhost:2809 but nothing helps.
It appears that omniNames is in a bad state, which should be resolvable through a hard reset of the service. To do a hard reset of omniNames, you will need to stop the omniNames service, delete the files in /var/log/omniORB, and then restart the omniNames service:
# /sbin/service omniNames stop
# rm -f /var/log/omniORB/*
# /sbin/service omniNames start
Note: do not delete the omniORB directory: just delete its contents.
More details on this are in the 1.9 user manual (which may not have been available at the time of your post) in "Appendix H: Resolving omniNames/omniEvents Failures".

Resources