Oh ... and lets see the output of: iptables -vnL
Perhaps there is a firewall here? Its worth double checking. On Tue, Jun 17, 2014 at 11:06 AM, Ken Barber <[email protected]> wrote: > At first glance this all seems correct. Hrm. > > Can you do the telnet test? > > telnet puppet.internal 8081 > > Also, are you destroying and rebuilding these VM's each time and then > its failing? Or are you doing all of this _after_ the vm's are > launched. Its quite possible there is a race condition/ordering issue > in how the provisioning is occuring end-to-end. > > ken. > > On Tue, Jun 17, 2014 at 10:44 AM, Sans <[email protected]> wrote: >> Hi Ken, >> >> Thanks for the heads up! >> First of all, it's a VBox VM, provisioned by Vigrant. PuppetMaster and >> PuppetDB are on the same machine. >> I did go through those basic checks before posting, which appeared fine: >> >> >>> root@puppet:~# telnet puppet.internal 8081 >>> Trying 127.0.1.1... >>> Connected to puppet.internal. >>> Escape character is '^]'. >> >> >>> root@puppet:~# netstat -ntpl | grep 80 >>> tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN >>> 14345/apache2 >>> tcp6 0 0 :::8080 :::* LISTEN >>> 16301/java >>> tcp6 0 0 127.0.1.1:8081 :::* LISTEN >>> 16301/java >> >> >> This is my jetty.ini: >> >>> root@puppet:~# awk '!/^($|#)/ {print}' /etc/puppetdb/conf.d/jetty.ini >>> [jetty] >>> host = 0.0.0.0 >>> port = 8080 >>> ssl-host = puppet.internal >>> ssl-port = 8081 >>> ssl-key = /etc/puppetdb/ssl/private.pem >>> ssl-cert = /etc/puppetdb/ssl/public.pem >>> ssl-ca-cert = /etc/puppetdb/ssl/ca.pem >> >> >> Java is also running: >> >>> root@puppet:~# ps auxww | grep java >>> puppetdb 16301 1.0 26.8 1558932 135336 ? Sl 13:47 2:26 >>> /usr/lib/jvm/java-7-openjdk-amd64/bin/java -XX:OnOutOfMemoryError=kill -9 %p >>> -Xmx192m -XX:+HeapDumpOnOutOfMemoryError >>> -XX:HeapDumpPath=/var/log/puppetdb/puppetdb-oom.hprof >>> -Djava.security.egd=file:/dev/urandom -cp /usr/share/puppetdb/puppetdb.jar >>> clojure.main -m com.puppetlabs.puppetdb.core services -c >>> /etc/puppetdb/conf.d >> >> >> >> ping can resolve: >> >>> root@puppet:~# ping -c2 puppet.internal >>> PING puppet.internal (127.0.1.1) 56(84) bytes of data. >>> 64 bytes from puppet.internal (127.0.1.1): icmp_req=1 ttl=64 time=0.023 ms >>> 64 bytes from puppet.internal (127.0.1.1): icmp_req=2 ttl=64 time=0.032 ms >>> >>> --- puppet.internal ping statistics --- >>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms >>> rtt min/avg/max/mdev = 0.023/0.027/0.032/0.006 ms >> >> >> >> but nslookup cannot: >> >>> root@puppet:~# nslookup puppet.internal >>> Server: 10.0.2.3 >>> Address: 10.0.2.3#53 >>> >>> ** server can't find puppet.internal: NXDOMAIN >> >> (nslookup is fine though with localhost) >> >> This is what my /etc/hosts looks like: >> >>> 127.0.0.1 localhost >>> 127.0.1.1 puppet.internal puppet >> >> >> >> It's Ubuntu 12.04 server and I heard that name resolving works differently >> in this version. I'm lost here. Best!! >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/f1f592e5-c15f-407b-bf09-48ee28eb9ab7%40googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAE4bNTn4NfvtzLB8cdDUPCCuY0%2Bv-N3YNy-2SKQpCw-fsdyfvQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
