Perforce command timeout doesn't seem to work - version-control

I am trying to set timeout to the perforce commands using the net.maxwait configurable as per this document:
https://community.perforce.com/s/article/3751
user#test:~/perforce/sandbox$ date; p4 -v net.maxwait=1 sync -f; date
Wed Dec 30 05:38:19 EST 2020
TCP receive failed.
read: socket stdio: Connection reset by peer
Perforce client error:
TCP receive failed.
read: socket stdio: Connection reset by peer
Wed Dec 30 05:40:26 EST 2020
But, I see that the p4 command times-out only after 2mins (approx).
To simulate the scenario of an unreliable network, I'm using iptables to drop the outgoing packets to the perforce server:
sudo iptables -D OUTPUT -d 172.27.213.25 -m statistic --mode random --probability 0.9 -p tcp --dport 22 -j DROP
strace indicates the connect() system call to be blocked.
user#test:~$ sudo strace -p 12356
strace: Process 12356 attached
connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("172.27.213.25")}, 16
The perforce version that I'm using:
user#test:~/perforce/sandbox$ p4 -V
Perforce - The Fast Software Configuration Management System.
Copyright 1995-2014 Perforce Software. All rights reserved.
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit (http://www.openssl.org/)
See 'p4 help legal' for full OpenSSL license information
Version of OpenSSL Libraries: OpenSSL 1.0.1g 7 Apr 2014
Rev. P4/LINUX26X86_64/2014.1/821990 (2014/04/08).
How do I get this to work as expected?

Related

Pivpn no internet

This question might seem duplicate but I've tried all other solutions which are years old so please help.
I setup Pivpn on my Raspberry Pi but cannot access internet via VPN.
Running ping 1.1.1.1 -I tun0 gives 100% packet loss and no response. From eth0 it works. Even ping 127.0.0.1 -I tun0 doesn't work.
Below is my log of pivpn -d it doesn't show any error.
::: Generating Debug Output
:::: [4mPiVPN debug[0m ::::
=============================================
:::: [4mLatest commit[0m ::::
Branch: master
Commit: 027f257931d1f169e254def5d1552d55810fefda
Author: 4s3ti
Date: Thu Aug 5 15:12:33 2021 +0200
Summary: Latest Changes update.
=============================================
:::: [4mInstallation settings[0m ::::
PLAT=Raspbian
OSCN=stretch
USING_UFW=0
IPv4dev=eth0
dhcpReserv=1
IPv4addr=10.10.70.10/24
IPv4gw=10.10.70.254
install_user=pi
install_home=/home/pi
VPN=openvpn
pivpnPROTO=udp
pivpnPORT=50552
pivpnDNS1=8.8.8.8
pivpnDNS2=8.8.4.4
pivpnSEARCHDOMAIN=
pivpnHOST=REDACTED
TWO_POINT_FOUR=1
pivpnENCRYPT=256
USE_PREDEFINED_DH_PARAM=0
INPUT_CHAIN_EDITED=0
FORWARD_CHAIN_EDITED=0
pivpnDEV=tun0
pivpnNET=10.8.0.0
subnetClass=24
ALLOWED_IPS=""
UNATTUPG=0
INSTALLED_PACKAGES=(grepcidr expect)
=============================================
:::: [4mServer configuration shown below[0m ::::
dev tun
proto udp
port 50552
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44.crt
key /etc/openvpn/easy-rsa/pki/private/ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44.key
dh none
ecdh-curve prime256v1
topology subnet
server 10.3.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 1.1.1.1"
#push "dhcp-option DNS 8.8.8.8"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
push "route 192.168.15.1 255.255.255.0"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.io
tun-mtu 1400
mssfix 1360
=============================================
:::: [4mClient template file shown below[0m ::::
client
dev tun
proto udp
remote REDACTED 50552
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44 name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
=============================================
:::: [4mRecursive list of files in[0m ::::
::: [4m/etc/openvpn/easy-rsa/pki shows below[0m :::
/etc/openvpn/easy-rsa/pki/:
Default.txt
ca.crt
crl.pem
ecparams
index.txt
index.txt.attr
index.txt.attr.old
index.txt.old
issued
openssl-easyrsa.cnf
private
renewed
revoked
safessl-easyrsa.cnf
serial
serial.old
ta.key
/etc/openvpn/easy-rsa/pki/ecparams:
prime256v1.pem
/etc/openvpn/easy-rsa/pki/issued:
ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44.crt
/etc/openvpn/easy-rsa/pki/private:
ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44.key
ca.key
/etc/openvpn/easy-rsa/pki/renewed:
private_by_serial
reqs_by_serial
/etc/openvpn/easy-rsa/pki/renewed/private_by_serial:
/etc/openvpn/easy-rsa/pki/renewed/reqs_by_serial:
/etc/openvpn/easy-rsa/pki/revoked:
private_by_serial
reqs_by_serial
/etc/openvpn/easy-rsa/pki/revoked/private_by_serial:
/etc/openvpn/easy-rsa/pki/revoked/reqs_by_serial:
=============================================
:::: [4mSelf check[0m ::::
:: [OK] IP forwarding is enabled
:: [OK] Iptables MASQUERADE rule set
:: [OK] OpenVPN is running
:: [OK] OpenVPN is enabled (it will automatically start on reboot)
:: [OK] OpenVPN is listening on port 50552/udp
=============================================
:::: Having trouble connecting? Take a look at the FAQ:
:::: [1mhttps://docs.pivpn.io/faq[0m
=============================================
:::: [4mSnippet of the server log[0m ::::
Aug 21 11:16:40 ANY ovpn-server[488]: ECDH curve prime256v1 added
Aug 21 11:16:40 ANY ovpn-server[488]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Aug 21 11:16:40 ANY ovpn-server[488]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 21 11:16:40 ANY ovpn-server[488]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Aug 21 11:16:40 ANY ovpn-server[488]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 21 11:16:40 ANY ovpn-server[488]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Aug 21 11:16:40 ANY ovpn-server[488]: TUN/TAP device tun0 opened
Aug 21 11:16:40 ANY ovpn-server[488]: TUN/TAP TX queue length set to 100
Aug 21 11:16:40 ANY ovpn-server[488]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Aug 21 11:16:40 ANY ovpn-server[488]: /sbin/ip link set dev tun0 up mtu 1400
Aug 21 11:16:40 ANY ovpn-server[488]: /sbin/ip addr add dev tun0 10.3.0.1/24 broadcast 10.3.0.255
Aug 21 11:16:40 ANY ovpn-server[488]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Aug 21 11:16:40 ANY ovpn-server[488]: Socket Buffers: R=[163840->163840] S=[163840->163840]
Aug 21 11:16:40 ANY ovpn-server[488]: UDPv4 link local (bound): [AF_INET][undef]:50552
Aug 21 11:16:40 ANY ovpn-server[488]: UDPv4 link remote: [AF_UNSPEC]
Aug 21 11:16:40 ANY ovpn-server[488]: GID set to openvpn
Aug 21 11:16:40 ANY ovpn-server[488]: UID set to openvpn
Aug 21 11:16:40 ANY ovpn-server[488]: MULTI: multi_init called, r=256 v=256
Aug 21 11:16:40 ANY ovpn-server[488]: IFCONFIG POOL: base=10.3.0.2 size=252, ipv6=0
Aug 21 11:16:40 ANY ovpn-server[488]: Initialization Sequence Completed
=============================================
:::: [4mDebug complete[0m ::::
:::
::: Debug output completed above.
::: Copy saved to /tmp/debug.log
:::
Running cat /proc/sys/net/ipv4/ip_forward gives 1 so forwarding is enabled.
I've ran the command sudo iptables -t nat -A POSTROUTING -s 10.3.0.0/24 -o eth0 -j MASQUERADE still doesn't work.
Please note that I've changed ip from 10.8.0.0 to 10.3.0.0 still doesn't work with both.
My openvpn version is OpenVPN 2.4.0
Well everything looks good. I suggest you reinstall pivpn from the official website here
Also, while installation select public dns and enter any public dns, you seem to be using your ip.
After reinstall and reboot, run the command sudo iptables -t nat -A POSTROUTING -s 10.3.0.0/24 -o eth0 -j MASQUERADE
Also, most importantly, using ping 1.1.1.1 -I tun0 won't work even if the VPN works so stop using it and use an actual connection.
You might want to create a statup script that runs the command sudo iptables -t nat -A POSTROUTING -s 10.3.0.0/24 -o eth0 -j MASQUERADE

Armitage 'Connection refused' error in new install of Kali Linux after full upgrade

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.

could not bind IPv4 socket: Permission denied

I am trying to set up a new instance of PostgreSQL 9.6 on a machine. I have tested it on another machine and its working fine on that machine. But the same process is not working on new machine. Below are the steps I am using
created a new data directory with below command
/opt/rh/rh-postgresql96/root/bin/initdb -D /var/lib/pgsql/9.6/data/
created a service file /etc/systemd/system/rh-postgresql96-inst2.service with below content
.include /lib/systemd/system/rh-postgresql96-postgresql.service
[Service]
Environment=PGDATA=/var/lib/pgsql/9.6/data/
Environment=PGPORT=5433
User=postgres
Group=root
registered service using command systemctl enable rh-postgresql96-inst2
now using command systemctl start rh-postgresql96-inst2 to start service.
All these steps are working fine on one machine but not on the 2nd one.
I am getting below error while starting service on the 2nd machine
rh-postgresql96-inst2.service - PostgreSQL database server
Loaded: loaded (/etc/systemd/system/rh-postgresql96-inst2.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2018-06-18 09:59:01 UTC; 10s ago
Process: 7552 ExecStart=/opt/rh/rh-postgresql96/root/usr/libexec/postgresql-ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT} (code=exited, status=1/FAILURE)
Process: 7550 ExecStartPre=/opt/rh/rh-postgresql96/root/usr/libexec/postgresql-check-db-dir %N (code=exited, status=0/SUCCESS)
HINT: Is another postmaster already running on port 5433? If not, wait a few seconds and retry.
LOG: could not bind IPv4 socket: Permission denied
HINT: Is another postmaster already running on port 5433? If not, wait a few seconds and retry.
WARNING: could not create listen socket for "localhost"
FATAL: could not create any TCP/IP sockets
LOG: database system is shut down
systemd[1]: rh-postgresql96-inst2.service: control process exited, code=exited status=1
systemd[1]: Failed to start PostgreSQL database server.
systemd[1]: Unit rh-postgresql96-inst2.service entered failed state.
systemd[1]: rh-postgresql96-inst2.service failed.
However, I am able to start service using pg_ctl.
Also, I have checked with netstat, lsof command to check if any other postgresql instance is running on port 5433 but its not the case.
Infact i tried 5431, 5434 ports also but server is not starting up
Instead of turning of SELinux you should allow postgres to bind to port 5433 in SELinux.
There is a port parameter postgresql_port_t which by default has port 5432 and 9898.
semanage port -l | grep post
postgresql_port_t tcp 5433, 9898
What you could do is simply add port 5433 to this list.
semanage port -a -t postgresql_port_t 5433 -p tcp
semanage port -l | grep post
postgresql_port_t tcp 5433, 5432, 9898
After that you can start your postgres server listening on port 5433
systemctl enable rh-postgresql96-postgresql
systemctl start rh-postgresql96-postgresql
netstat -tulpn
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 2847/postgres
tcp 0 0 127.0.0.1:5433 0.0.0.0:* LISTEN 2775/postgres
There is also a handy tool called audit2allow to help debug selinux problems.
audit2allow -m whatiswrong < /var/log/audit/audit.log > /root/showme.te
The file showme.te show you why SELinux is not allowing the service to do what you need.
You should not turn off SELinux just because it's hard to understand or if you don't know how it works. Instead you should study it :)
I reccomend this lecture from the Red Hat Summit https://www.redhat.com/en/about/videos/summit-2018-security-enhanced-linux-mere-mortals
This issue was related to SELinux.
When I run command sestatus on both machines, output was a little bit different.
One server had Current mode: permissive and 2nd one had Current mode: enforcing.
So I changed the current mode to permissive on the 2nd machine using command setenforce 0.
and it resolved the permission related issue. Now I am able to start 2nd instance.

Mongoexport with cluster throws i/o timeout error

Just upgraded to mongo 3.0, but mongoexport gives us a the following error: "Failed: read tcp 127.0.0.1:27020: i/o timeout" after outputting some documents (not always the same amount). mongoexport is connecting to a sharded cluster of 4 standalone mongod servers with 3 mongod config servers
[root#SRV]$ mongoexport --host
localhost:27022,localhost:27021,localhost:27020 --db horus
--collection users --type json --fields _id | wc -l
2015-03-09T12:41:19.198-0600 connected to:
localhost:27022,localhost:27021,localhost:27020
2015-03-09T12:41:22.570-0600 Failed: read tcp 127.0.0.1:27020: i/o
timeout
15322
The versions we are using are:
[root#MONGODB01-SRV]# mongo --version MongoDB shell version: 3.0.0
[root#SRV]$ mongoexport --version mongoexport version: 3.0.0 git
version: e35a2e87876251835fcb60f5eb0c29baca04bc5e
[root#SRV]$ mongos --version MongoS version 3.0.0 starting: pid=47359
port=27017 64-bit host=SRV (--help for usage) git version:
a841fd6394365954886924a35076691b4d149168 OpenSSL version: OpenSSL
1.0.1e-fips 11 Feb 2013 build sys info: Linux ip-10-181-61-91 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 BOOST_LIB_VERSION=1_49
Tried with a 2.6 mongoexport in another server against our mongod3.0 and mongos3.0 and works fine
This is an old question but I wanted to answer. Maybe this answer will help one of us. It might be caused by someone else trying to write to the collection you are writing. I had a smilar problem. After a long research I realised that a user with higher role was trying to write in the sametime and because his/her role is more important than mine ones request were done and mine are given IO exception.
Try closing the ports first: eg. killall -9 node

openldap fails to bind ldaps://127.0.0.1:636

Here is my testcase :
[root#192.168.121.130 ~$]slapd -d 1 -h ldaps://127.0.0.1:636
#(#) $OpenLDAP: slapd 2.4.23 (Apr 29 2013 07:47:08) $
mockbuild#c6b7.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
ldap_pvt_gethostbyname_a: host=centos-6.3, r=0
daemon_init: listen on ldaps://127.0.0.1:636
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldaps://127.0.0.1:636)
daemon: bind(7) failed errno=98 (Address already in use)
slap_open_listener: failed on ldaps://127.0.0.1:636
slapd stopped.
connections_destroy: nothing to destroy.
But if I change another port , such as 6361, it works.
My environment:
OS: centos 6.4 x86_64
OpenLDAP: 2.4.23 installed by yum
Any suggestion?
it seems that another service is already running on port 636:
daemon: bind(7) failed errno=98 (Address already in use)
you can try the following command to identify this service:
netstat -tulpn | grep ':636 ' | grep 'LISTEN'
Old post, but still ...
This error is also displayed when SELinux prevents slapd from starting. Personally I experienced this after manually copying data (/var/lib/ldap/) from another server, to this one. I had to restore the imported files to default SELinux security contexts:
restorecon -R /var/lib/ldap
And I see this doesn't apply to you, but this might also happen if you're attempting to bind slapd to a port out of the ordinary. Default on CentOS7, these are the allowed ports:
#semanage port -l | grep ldap
ldap_port_t tcp 389, 636, 3268, 7389
ldap_port_t udp 389, 636
Adding another one to the legal port range, could be done with semanage. (You might need to install the package policycoreutils-python.):
semanage port -a -t ldap_port_t -p tcp 10389
... if you wish to allow slapd to bind on TCP port 10389 in addition to the four listed above. After this, the previous result would look like:
# semanage port -l | grep ldap
ldap_port_t tcp 10389, 389, 636, 3268, 7389
ldap_port_t udp 389, 636