This is the error it's loggin:
[Sun Sep 25 15:04:12 2016] [alert] (EAI 8)nodename nor servname provided, or not known: mod_unique_id: unable to find IPv4 address of "Jonathans-MacBook-Pro.local"
Configuration Failed
You will need to add this to your /etc/hosts file:
127.0.0.1 Jonathans-MacBook-Pro.local
Just stop macOS Apache
sudo apachectl stop
Related
I have a problem with Zabbix 6.0 LTS! Where i install zabbix agent 6.0 in this server! I have a error invalid argument:
In Zabbix Server 6.0 LTS its okay,but in zabbix agent 6.0 server i have a this error:
check 'vfs.file.contents["/sys/class/net/eth0/speed"]' is not supported: Cannot read from file: read /sys/class/net/eth0/speed: invalid argument
I dont have any idea also i try cat more commands for /sys/class/net/eth0/speed in file speed the error also invalid argument
P.S: File Exist! -r--r--r-- 1 root root 4.0K Feb 1 16:25 /sys/class/net/eth0/speed
Linux Mint 21
Success install openvpn.
OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
Now want to connect to remote setup via openvpn.
sudo openvpn Leo.ovpn
but get error:
2022-08-15 09:29:10 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2022-08-15 09:29:10 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2022-08-15 09:29:10 WARNING: file 'client.key' is group or others accessible
2022-08-15 09:29:10 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
2022-08-15 09:29:10 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2022-08-15 09:29:10 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2022-08-15 09:29:10 OpenSSL: error:0A00018E:SSL routines::ca md too weak
2022-08-15 09:29:10 Cannot load certificate file client.crt
2022-08-15 09:29:10 Exiting due to fatal error
P.S. I check folder. Exist files: client.crt and ca.crt
I'm having a problem with init.d script on my Raspberry PI 4 (4GB) with Raspbian 10.
I've followed the guide on the official docs and compiled RethinkDB without any problem.
Then I've configured as described in the Deployment docs.
Created conf file in /etc/rethinkdb/instances.d/<conf_name>.conf;
Copied init.d script sudo cp /home/pi/rethinkdb-2.4.1/packaging/assets/init/rethinkdb /etc/init.d/rethinkdb
Added Default Runlevel sudo update-rc.d rethinkdb defaults
I can start the server with command rethinkdb --config-file /etc/rethinkdb/instances.d/instance1.config and it gives me no problem
pi#homeserverpi:~ $ rethinkdb --config-file /etc/rethinkdb/instances.d/instance1.conf
WARNING: ignoring --server-name because this server already has a name.
Running rethinkdb 2.4.1 (CLANG 7.0.1 (tags/RELEASE_701/final))...
Running on Linux 5.4.72-v7l+ armv7l
Loading data from directory /home/pi/rethinkdb_data
Listening for intracluster connections on port 29015
Listening for client driver connections on port 28015
Listening for administrative HTTP connections on port 8182
Listening on cluster addresses: 127.0.0.1, 192.168.1.3, ::1, fe80::38b8:6928:e4fd:1a9c%3
Listening on driver addresses: 127.0.0.1, 192.168.1.3, ::1, fe80::38b8:6928:e4fd:1a9c%3
Listening on http addresses: 127.0.0.1, 192.168.1.3, ::1, fe80::38b8:6928:e4fd:1a9c%3
Server ready, "homeserverpi_9x0" 00eb027b-181c-4a15-a170-8ba8299f4f3f
But when I try to start the service it gives me this
sudo /etc/init.d/rethinkdb start rethinkdb: instance1: Starting instance. (logging to '/var/lib/rethinkdb/instance1/data/log_file')
/etc/init.d/rethinkdb: 224: /etc/init.d/rethinkdb: /usr/bin/rethinkdb: Permission denied
Permissions
pi#homeserverpi:~ $ ls -alh /etc/init.d/rethinkdb
-rwxr-xr-x 1 root root 7.5K Nov 30 00:20 /etc/init.d/rethinkdb
pi#homeserverpi:~ $ ls -alh /usr/bin/rethinkdb/
total 40K
drwxr-xr-x 2 root root 4.0K Nov 29 23:06 .
drwxr-xr-x 3 root root 36K Nov 29 23:06 ..
Can someone please help me on this?
Thank you
I installed Kali Linux via VMware and did a full system upgrade:
apt-get update
apt-get upgrade
apt-get full-upgrade
As part of the upgrade postgresql upgraded from v11 to v12. I followed the instructions to finish this part of the upgrade:
pg_dropcluster 12 main --stop
pg_upgradecluster 11 main
pg_dropcluster 11 main
I start postgresql, initialize metasploit, and start Armitage:
/etc/init.d/postgresql start
msfdb init
armitage
The only console output appears unrelated:
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
-Dswing.aatext=true
I do get the popup box with the connection information. I found that I get the "Unexpected end of file from server" if I use 'localhost' as the host, so - per their instructions - I change it to the external IP (in this case 192.168.9.134). I checked metasploit-framework/config/database.yml for
the port and login credentials.
After clicking 'Connect' with this information I get a connection window stating:
Connecting to 192.168.9.134:5432 Connection refused (Connection
refused)
There's also the progress bar that over time will completely fill up (unless I click 'Cancel'). After which nothing happens. As I run the command from the terminal I can see that the process is still running (I don't get my prompt back) but the window disappears and Armitage doesn't actually start. The log file, as verified by pg_lsclusters (/var/log/postgresql/postgresql-12-main.log) doesn't is actually empty.
The link I mentioned before suggests that the problem could either be not enough RAM (I set the VM to have 4gb and free -m shows):
total used free shared buff/cache available
Mem: 3964 803 2677 29 483 2787
Swap: 4093 0 4093
Or that the Metasploit RPC daemon never started (that window does come up the first time, but not subsequent times). I verified that it's running via msfdb status:
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
Active: active (exited) since Fri 2020-02-07 16:06:52 EST; 19min ago
Process: 1753 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 1753 (code=exited, status=0/SUCCESS)
Feb 07 16:06:52 kali systemd1: Starting PostgreSQL RDBMS... Feb 07
16:06:52 kali systemd1: Started PostgreSQL RDBMS.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME postgres
1735 postgres 3u IPv6 32516 0t0 TCP localhost:5432 (LISTEN)
postgres 1735 postgres 4u IPv4 32517 0t0 TCP localhost:5432
(LISTEN)
UID PID PPID C STIME TTY STAT TIME CMD postgres 1735
1 0 16:06 ? Ss 0:00 /usr/lib/postgresql/12/bin/postgres -D
/var/lib/postgresql/12/main -c
config_file=/etc/postgresql/12/main/postgresql.conf
[+] Detected configuration file
(/usr/share/metasploit-framework/config/database.yml)
Also, running regular Metasploit appears to work fine (msfconsole) and loads without error (not sure if there's any output that would be helpful here). I don't use postgresql directly, so I haven't messed with any configuration nor do I have any other applications (that I'm aware of) that use it, so it should be a pretty clean setup (not to mention this is a fresh install of Kali Linux). I'm out of ideas for what to check next. An online search didn't seem to match this problem well. Any thoughts?
Armitage has been deprecated for some time now, as it has not been updated since 2015, and is (to some extent) incompatible with current versions of metasploit.
Although this may not fix your problem, I suggest not using software this much out of date.
[root#name ~]# systemctl status firewalld -l
* firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)
Nov 17 18:47:24 strike325 systemd[1]: Starting firewalld - dynamic firewall daemon...
Nov 17 18:47:25 strike325 systemd[1]: Started firewalld - dynamic firewall daemon.
Nov 17 18:47:25 strike325 firewalld[1176]: WARNING: ipset not usable, disabling ipset usage in firewall.
Nov 17 18:47:26 strike325 firewalld[1176]: ERROR: Failed to load nf_conntrack module: modprobe: ERROR: could not find module by name='nf_conntrack'
modprobe: ERROR: could not insert 'nf_conntrack': Function not implemented
modprobe: ERROR: Error running install command for nf_conntrack
modprobe: ERROR: could not insert 'nf_conntrack': Operation not permitted
Nov 17 18:47:26 strike325 firewalld[1176]: E
RROR: Raising SystemExit in run_server
Nov 17 19:47:16 strike325 systemd[1]: Starting firewalld - dynamic firewall daemon...
Nov 17 19:47:17 strike325 systemd[1]: Started firewalld - dynamic firewall daemon.
Nov 17 19:47:17 strike325 firewalld[2689]: WARNING: ipset not usable, disabling ipset usage in firewall.
Nov 17 19:47:18 strike325 firewalld[2689]: ERROR: Failed to load nf_conntrack module: modprobe: ERROR: could not find module by name='nf_conntrack'
modprobe: ERROR: could not insert 'nf_conntrack': Function not implemented
modprobe: ERROR: Error running install command for nf_conntrack
modprobe: ERROR: could not insert 'nf_conntrack': Operation not permitted
Nov 17 19:47:18 strike325 firewalld[2689]: ERROR: Raising SystemExit in run_server
I've recently purchased a VPS using Centos 7 (x64) and I'm having some trouble with my firewalld. I found the fix here but unfortunately it's no longer working for me. Any help would be appreciated as I haven't been able to find any permanent fixes.
Other fix attempts so far:
restart dbus
restart firewalld
Reverting and locking the version of firewalld (temporary fix)
I was going to post my fix in a while now (I'm supporting a number of servers, all affected with the same issue), but haven't had the time.
But your question made me motivated to finally write it down.
The solution from this post is:
create a script which generates modules.builtin file specific to your current kernel
create a SystemD unit which automatically recreates the same before FirewallD during startup (useful in case the kernel is upgraded).
In this way, you permanently solve the issue without hacking a bit of FirewallD code.
Workaround is to downgrade firewalld to 7.6:
wget http://vault.centos.org/7.6.1810/os/x86_64/Packages/firewalld-0.5.3-5.el7.noarch.rpm http://vault.centos.org/7.6.1810/os/x86_64/Packages/firewalld-filesystem-0.5.3-5.el7.noarch.rpm http://vault.centos.org/7.6.1810/os/x86_64/Packages/python-firewall-0.5.3-5.el7.noarch.rpm
yum downgrade firewalld-0.5.3-5.el7.noarch.rpm firewalld-filesystem-0.5.3-5.el7.noarch.rpm python-firewall-0.5.3-5.el7.noarch.rpm
and then lock firewalld from yum feature updates:
yum -y install yum-versionlock
yum versionlock firewalld firewalld-filesystem python-firewall
you can find more info in this thread.