Apigee: Unable to authenticate with Management Server - apigee

I'm installing Apigee on a single node but when running this command:
/opt/apigee/apigee-setup/bin/setup.sh -p aio -f configFile
I get this stack error at the end:
Checking if management-server is up management-server is up.
Finished edge-management-server setup
Checking for required variables
Checking required variable MSIP...OK
Checking required variable ADMIN_EMAIL...OK
Checking for optional variables
Found optional variable APIGEE_ADMINPW...OK
Found optional variable APIGEE_PORT_HTTP_MS...OK
http://10.10.37.31:8080/v1/servers/self......
Unable to authenticate with Management Server
Error: setup.sh: /opt/apigee/apigee-service/bin/apigee-service exited with unexpected status 1
I've already tried with uninstalling and reinstalling but still getting the same error:
/opt/apigee/apigee-service/bin/apigee-service apigee-service uninstall
This is my configFile:
# With SMTP
IP1=10.10.37.31
HOSTIP=$(hostname -i)
ENABLE_SYSTEM_CHECK=y
ADMIN_EMAIL=name.surname#org.ch
# Admin password must be at least 8 characters long and contain one uppercase
# letter, one lowercase letter, and one digit or special character
APIGEE_ADMINPW=Apigeepw2020
LICENSE_FILE=/tmp/license.txt
MSIP=$IP1
LDAP_TYPE=1
APIGEE_LDAPPW=Apigeepw2020
MP_POD=gateway
REGION=dc-1
ZK_HOSTS="$IP1"
ZK_CLIENT_HOSTS="$IP1"
# Must use IP addresses for CASS_HOSTS, not DNS names.
CASS_HOSTS="$IP1"
# Default is postgres
PG_PWD=postgres
SKIP_SMTP=y
SMTPHOST=smtp.example.com
SMTPUSER=smtp#example.com
# omit for no username
SMTPPASSWORD=SMTP_PASSWORD
# omit for no password
SMTPSSL=n
SMTPPORT=25
SMTPMAILFROM="My Company <myco#company.com>"

Related

tcpprep: Command line arguments not allowed

I'm not sure, why executing below command on ubuntu terminal throws error. tcpprep syntax and options are mentioned as per in help doc, still throws error.
root#test-vm:~# /usr/bin/tcpprep --cachefile='cachefile1' —-pcap='/pcaps/http.pcap'
tcpprep: Command line arguments not allowed
tcpprep (tcpprep) - Create a tcpreplay cache cache file from a pcap file
root#test-vm:~# /usr/bin/tcpprep -V
tcpprep version: 3.4.4 (build 2450) (debug)
There are two problems with your command (and it doesn't help that tcpprep errors are vague or wrong).
Problem #1: Commands out of order
tcpprep requires that -i/--pcap come before -o/--cachefile. You can fix this as below, but then you get a different error:
bash$ /usr/bin/tcpprep —-pcap='/pcaps/http.pcap' --cachefile='cachefile1'
Fatal Error in tcpprep_api.c:tcpprep_post_args() line 387:
Must specify a processing mode: -a, -c, -r, -p
Note that the error above is not even accurate! -e/--mac can also be used!
Problem #2: Processing mode must be specified
tcpprep is used to preprocess a capture file into client/server using a heuristic that you provide. Looking through the tcpprep manpage, there are 5 valid options (-acerp). Given this capture file as input.pcapng with server 192.168.122.201 and next hop mac 52:54:00:12:35:02,
-a/--auto
Let tcpprep determine based on one of 5 heuristics: bridge, router, client, server, first. Ex:
tcpprep --auto=first —-pcap=input.pcapng --cachefile=input.cache
-c/--cidr
Specify server by cidr range. We see servers at 192.168.122.201, 192.168.122.202, and 192.168.3.40, so summarize with 192.168.0.0/16:
tcpprep --cidr=192.168.0.0/16 --pcap=input.pcapng --cachefile=input.cache
-e/--mac
This is not as useful in this capture as ALL traffic in this capture has dest mac of next hop of 52:54:00:12:35:02, ff:ff:ff:ff:ff:ff (broadcast), or 33:33:00:01:00:02 (multicast). Nonetheless, traffic from the next hop won't be client traffic, so this would look like:
tcpprep --mac=52:54:00:12:35:02 —-pcap=input.pcapng --cachefile=input.cache
-r/--regex
This is for IP ranges, and is an alternative to summarizing subnets with --cidr. This would be more useful if you have several IPs like 10.0.20.1, 10.1.20.1, 10.2.20.1, ... where summarization won't work and regex will. This is one regex we could use to summarize the servers:
tcpprep --regex="192\.168\.(122|3).*" —-pcap=input.pcapng --cachefile=input.cache
-p/--port
Looking at Wireshark > Statistics > Endpoints, we see ports [135,139,445,1024]/tcp, [137,138]/udp are associated with the server IPs. 1024/tcp, used with dcerpc is the only one that falls outside the range 0-1023, and so we'd have to manually specify it. Per services syntax, we'd represent this as 'dcerpc 1024/tcp'. In order to specify port, we also need to specify a --services file. We can specify one inline as a temporary file descriptor with process substitution. Altogether,
tcpprep --port --services=<(echo "dcerpc 1024/tcp") --pcap=input.pcapng --cachefile=input.cache
Further Reading
For more examples and information, check out the online docs.

ssh ipv6 address in R ssh package

How do I ssh ipv6 address in R ssh package
library(ssh)
# works
session <- ssh_connect("user#10.1.1.0")
# gives error
session <- ssh_connect("user#24:022f:0313:112:0::2")
Error in parse_host(host, default_port = 22) :
host string contains multiple ':' characters
Since you can't install source packages, one super hacky way to do this is to call the C function ssh_connect() calls directly:
.Call(
ssh:::C_start_session, "2405:0200:0313:112:41::42", 22, "user", NULL, ssh:::askpass, FALSE
)
That C interface is highly unlikely to change so it should be a pretty safe hack until the package eventually supports IPv6.
For those that stumble on this before the rOpenSci folks make any changes, the fork : https://github.com/hrbrmstr/ssh : also adds support for using a local SSH config file. Which means you can add a Host entry for IPv6 addresses (along with any other config options) and they'll be looked up.
i.e. if one has:
Host awickedcoolhost
User boringusername
Hostname ::1
IdentityFile ~/.ssh/id_rsa
Port 22222
in ~/.ssh/config, one can (with the fork) do:
ssh_connect("awickedcoolhost", config="~/.ssh/config")
and all the overrides in that entry should work.

Where is the Compose Scylladb SSL certificate?

I'm trying to connect to my scylladb 1.7.4 instance using the connection string provided for me in the compose overview section of the management UI:
$ cqlsh --ssl portal-xxxx.ibm-343.composedb.com 19228 -u scylla -p XXXX --cqlversion=3.3.1
However, the response is:
Validation is enabled; SSL transport factory requires a valid certfile to be specified. Please provide path to the certfile in [ssl] section as 'certfile' option in /Users/snowch/.cassandra/cqlshrc (or use [certfiles] section) or set SSL_CERTFILE environment variable
Where can I get access to the Compose SSL certificate so that I can connect with:
$ SSL_CERTFILE=/path/to/scylla_certfile cqlsh --ssl portal-xxxx-0.csnow-scylla-45.ibm-343.composedb.com 19228 -u scylla -p XXXX --cqlversion=3.3.1
I have seen the option SSL_VALIDATE=false in the documentation however, I don't want to disable SSL validation.
The information is further down in the documentation in the section https://help.compose.com/docs/scylla-and-certificates.
My confusion was because I was drawn to the information on ssl (#2) because of the issue I had encountered and as such I jumped over the section on full configuration for cqlsh (#1):
Cqlsh Command Line
The Cqlsh Command Line panel contains three cqlsh commands, each of which connect to the three Compose portals. Full details on obtaining cqlsh and configuring it are available in Scylla and cqlsh. (#1)
The displayed command include required flags (--ssl and --cqlversion). If the command is preceded by setting the environment variable SSL_VALIDATE=false, then no further configuration is needed. (#2)
I think this section would be a bit clearer if it was re-ordered:
Cqlsh Command Line
The Cqlsh Command Line panel contains three cqlsh commands, each of which connect to the three Compose portals.
The displayed command include required flags (--ssl and --cqlversion). If the command is preceded by setting the environment variable SSL_VALIDATE=false, then no further configuration is needed.
Full details on obtaining cqlsh and configuring it are available in Scylla and cqlsh. This section includes information on configuring cqlsh to use ssl.

Error on starting the application Puppet in the Generic enablers Cosmos

Good afternoon,
I have installed the Generic enablers Cosmos, following the manual BigData Analysis - Installation and Administration Guide. When I have come to 'Step 7: applying Puppet' and executed the commands, in the file puppet.err has appeared the following errors:
Error: Could not prefetch yumrepo provider ' inifilé: Section 'openvz-utils' is already defined, cannot re-defines in/etc/yum.repos.d/openvz.repo
Description: There is a conflict with the titles (indicated in bold type) of the file /etc/yum.repos.d/cosmos-openvz.repo and /etc/yum.repos.d/openvz.repo .
cat /etc/yum.repos.d/cosmos-openvz.repo
[openvz-utils]
...
[openvz-kernel-rhel6]
...
cat /etc/yum.repos.d/openvz.repo
[openvz-utils]
...
[openvz-kernel-rhel6]
...
[openvz-kernel-rhel6-testing]
...
Solution: I have realized a change in the titles of the file /etc/yum.repos.d/openvz.repo, example: [openvz-utils_1]
Error: Could not prefetch database_grant provider 'mysql': Execution of '/usr/bin/mysql mysql -Be describe user' returned 1: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
Description: in the folder /var/lib/mysql/ was not found the file mysql.sock.
Solution: I have installed mysql-server.x86_64:
yum install mysql-server.x86_64
At the end of the installations, I restarted the service:
/etc/init.d/mysqld stop
/etc/init.d/mysqld start
Error: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y list vzstats' returned 1: Error: Cannot retrieve repository metadata (repomd.xml) for repository: ambari. Please verify its path and try again
Description: This error appears in the machine of the Master node, this one is provoked by the configuration of the file [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/hieradata/my_environment/common.yaml, indicated in 'Step 6: Puppet configuration'. Concretely, the URL that use the IP: 130.206.81.65
Solution: in the file [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/hieradata /my_environment/common.yaml to change the line:
ambari::params::repo_url: 'http:// 130.206.81.65/cosmos/ambari/'
(without blank space)
for
ambari::params::repo_url: 'http:// public-repo-1.hortonworks.com/ambari/centos6/1.x/GA'
(without blank space)
Error: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y list vzstats' returned 1: Error: Cannot retrieve repository metadata (repomd.xml) for repository: cosmos-libvirt. Please verify its path and try again
Description: it is the same problem as the previous error. The difficulty in this one is that I cannot modify the file [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/hieradata /my_environment/common.yaml in the line:
cosmos::params::cosmos_repo_deps_url: 'http:// 130.206.81.65/cosmos/rpms/cosmos-deps'
(without blank space)
Because it is line is used in several files:
cat /etc/yum.repos.d/cosmos-libvirt.repo
[cosmos-libvirt]
name=Cosmos LibVirt with OpenVZ - v1.0.5 - NO PolKIT
baseurl=http:// 130.206.81.65/cosmos/rpms/cosmos-deps//libvirt
gpgcheck=0
priority=10
enabled=1
cat /etc/yum.repos.d/cosmos-openvz.repo
[openvz-utils]
name=OpenVZ utilities
baseurl=http:// 130.206.81.65/cosmos/rpms/cosmos-deps//OpenVZ/openvz-utils
enabled=1
gpgcheck=0
priority=1
[openvz-kernel-rhel6]
name=OpenVZ RHEL6-based kernel
baseurl=http:// 130.206.81.65/cosmos/rpms/cosmos-deps//OpenVZ/openvz-kernel- > rhel6
enabled=1
gpgcheck=0
priority=1
It does not also allow to modify the file previous, in the moment to execute the command (indicated in 'Step 7: applying Puppet'):
puppet apply --debug --verbose \
--modulepath [COSMOS_TMP_PATH]/puppet/modules/:[COSMOS_TMP_PATH]/puppet/modules_third_party/ \
--environment my_environment --hiera_config [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/hiera.yaml \
--manifestdir [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/ [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/site.pp \
> puppet.out 2> puppet.err
It will erase the modified.
Solution: https://github.com/telefonicaid/fiware-cosmos-platform/issues/4
I need help with the error:
Error: /Stage[main]/Ambari::Server::Config/Augeas[ambari-config-repoinfo]: Could not evaluate: Saving failed, see debug
Might they to throw me a hand with these last error?
Thank you in advance.
PD: Forgive for if it is written badly

ldap_bind: Invalid credentials (49) again

I have searched several posting on this message and I am still getting the error when I attempt to do an "ldapsearch"
I have changed the slapd.conf to use a plain-text password and I am still getting the error. I have also made sure that there are no blank spaces in the file. The log file shows and iptables is turned off. I have attempted to follow the LDAP setup from
"http://www.itmanx.com/kb/centos63-openldap-phpldapadmin".
conn=1001 fd=15 ACCEPT from IP=[::1]:54486 (IP=[::]:389)
conn=1001 op=0 BIND dn="cn=Manager,dc=domain,dc=local,dc=pt" method=128
conn=1001 op=0 RESULT tag=97 err=49 text=
conn=1001 fd=15 closed (connection lost)
my server is running Centos 6.4 64.
below are the commands I am using
"ldapsearch -x -D cn=Manager,dc=domain,dc=local,dc=pt -w abc"
my slapd.conf file
database bdb
suffix "dc=domain,dc=local"
checkpoint 1024 15
rootdn "cn=Manager,dc=domain,dc=local"
rootpw abc
You need to generate your password like below -
slappasswd -h {CLEARTEXT}
enter password - abc
Do the search -
ldapsearch -x -h ipaddress(mention ip address) -D "cn=Manager,dc=domain,dc=local" -W
In the search you try to bind as:
cn=Manager,dc=domain,dc=local,dc=pt
but in the config the rootdn is:
cn=Manager,dc=domain,dc=local
This is of course "an invalid credential".
You are binding as the rootdn, which is to say the "root account" of your DIT. This account's password is, in this case, config-based. It is possible that while 'abc' is the configured password, it may not be the loaded password.
Case in point: Someone goes into the slapd.conf file and changes the rootdn password from 'xyz' to 'abc' but neglects to restart the OpenLDAP daemon. What will happen here is that 'abc' will NOT work until the process is restarted, and thus the OpenLDAP daemon will continue to honor the OLD password of 'xyz'.
I hope this helps...
Max

Resources