Thursday, June 2, 2016

python - git hook and ssh on server

I have a git repo on a server. I would like to run a update hook on this when a push is done.



I am unable to get git revlist or take any information from the user because i can't enable tty.



I have written the hook in python. I would like it so I can retrieve commit history from my local repo and use that information in the process of my update hook, which checks for pattern in commits.



the problem i am having is that when i run the command from my script it is being executed on my server.




Please any advice would really be appreciated.

Wednesday, June 1, 2016

raid - data lost with RAID5 on proliant DL360 when drives fail

For some reason the Array Controller on my Proliant DL360 G6 couldn't recognize 2 of the 6 750GB drives I am running in a RAID 5 configuration with VMware ESXi 5.1.



When I rebooted the server I chose the BIOS option (F2) to recognize the 2 drives it said it stopped acknowledging.



Here is the BIOS option I chose: "Select "F2" to accept data loss and re-enable logical drive(s)."




All 6 drives now show up in the volume again.



Unfortunately, there seems to be data corruption. Many of the virtual machines no longer work and don't even register properly in ESXi anymore. ESXi boots ok, but none of the virtual machines hosted in it work.



I booted with the Array Configuration Utility and it says the Parity Initialization has finished. ACU doesn't show any other errors or information notices.



Is there a way for me to rebuild or recover my data so my virtual machines start working again? It is still a mystery to me why Array stopped seeing the two drives in the first place, but all I want to do now is recover all my data so my virtual machines start working again.

permissions - What is preventing me from piping from a '600' file into mail within launchd?



In OSX 10.6 I'm running logcheck.sh via. launchd using this plist






"http://www.apple.com/DTDs/PropertyList-1.0.dtd">


Labelorg.logcheck
Program/opt/local/bin/logcheck.sh
StartInterval600




logcheck runs at the specified interval but it won't send me mail using the command below:




cat $TMPDIR/checkreport.$$ | $MAIL -s "$HOSTNAME $DATE system check" $SYSADMIN


where



$TMPDIR=/opt/local/var/tmp
$MAIL=/usr/bin/mail
$SYSADMIN=myuser



however, if I hack it, and change the command to:



cat $TMPDIR/checkreport.$$ > /Users/myuser/report
cat /Users/myuser/report | $MAIL -s "$HOSTNAME $DATE system check" $SYSADMIN


then I receive the mail.



Checking permission on tmp with $ls -l /opt/local/var I get




drwx------  20 root  admin  680 Jul 12 13:29 tmp/


If I run sudo /opt/local/bin/logcheck.sh the first command works.



If I use /opt/local/bin/logcheck.sh in root's crontab the first command works.



If I throw in the script echo "$(whoami)" > /Users/myuser/launchduser I see that it is indeed being run by root.



Why am I not getting mail with the first command in launchd? Is it a permissions issue with the pipe to mail?



Answer



I've recently been working on this myself, and have found entries in the system log (/var/log/system.log) that show errors related to this issue, such as:



Nov  1 08:52:14 my-computer com.apple.launchd[1] (org.postfix.master[22591]): Stray process with PGID equal to this dead job: PID 22592 PPID 1 pickup
Nov 1 08:52:14 my-computer com.apple.launchd[1] (org.postfix.master[22591]): Stray process with PGID equal to this dead job: PID 22594 PPID 1 cleanup


I found that my logcheck script and the expected email worked perfectly when executed from the command line, and that the logcheck script was performing its functions well when launched using launchd via a LaunchDaemon script.



However, the mail never arrived when using launchd. The errors above, and many others, involving postfix and sendmail, indicate that the child sendmail processes were being terminated by launchd (as part of its garbage collection routines?) before they had time to complete.




I added the following key to my plist:



AbandonProcessGroup



and the mail started flowing when using launchd. Unfortunately, I still get the stray process/dead job messages in my system.log, which I'm currently working on eliminating. I've added a sleep 120 line to my logcheck.sh script, which reduced, but has not eliminated, these messages. I could lengthen the time of the sleep command in logcheck.sh, so that the script persists longer, but I don't like this particular 'hack' and want to find a more elegant solution. I believe launchd does not begin its garbage collection until after the logcheck.sh process completes....



I'm going to try explicitly lengthening the TimeOut key in the controlling plist, and see if that works better.



ubuntu - Why is Upstart not starting uWSGI?



I am trying to set up a django project on my VPS. I am trying to get a uWSGI Emperor to run and thus spawn vassals. I have set up all my config files as suggested by numerous websites including the uWSGI documentation. Yet when I run the file command

paul@example:/$ sudo service uwsgi start

I get the following:

start: Unknown job: uwsgi


I figured this was because Upstart couldn't recognize the uwsgi.conf file http://uwsgi-docs.readthedocs.org/en/latest/Upstart.html I have in /etc/init/. But after review I can not find anything wrong with it.





paul@example:/etc/init$ sudo vim uwsgi.conf



# Emperor uWSGI script

pre-start script
logger "pre-start for uWSGI Emperor"
end script


post-start script
logger "post-start for uWSGI Emperor"
end script

description "uWSGI Emperor"

start on runlevel [2345]
stop on runlevel [!2345]

respawn


env LOGTO = /var/log/uwsgi.log

exec /usr/local/bin/uwsgi --master --die-on-term --emperor /etc/uwsgi/vassals --logto $LOGTO


I also checked over my /etc/uwsgi/vassals files to make sure they were in working order. My only file right now is a mysite.ini file:




paul@example:/etc/uwsgi/vassals$ sudo vim mysite.ini




[uwsgi]
base = /home/paul/djprojs/mysite/
chdir = %(base)
master = true
threads = 20
socket = /tmp/sockets/%n.sock
home = /home/paul/.virtualenvs/dj

env = DJANGO_SETTINGS_MODULE=%n.settings
module = django.core.handlers.wsgi:WSGIHandler()


But this looks okay to me also.



Finally, to test and see if uWSGI would run from the command line, I started it without Upstart. I ran




paul@exmaple/$ uwsgi --emperor /etc/uwsgi/vassals



and it worked:




*** Starting uWSGI 1.9.13 (32bit) on [Sat Jul 27 19:23:43 2013] ***
compiled with version: 4.6.3 on 21 July 2013 03:35:50
os: Linux-3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 12:51:49 UTC 2012
nodename: example.me
machine: i686

clock source: unix
detected number of CPU cores: 1
current working directory: /
detected binary path: /usr/local/bin/uwsgi
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 3922
your memory page size is 4096 bytes
detected max file descriptor number: 1024
*** starting uWSGI Emperor ***
*** has_emperor mode detected (fd: 6) ***

[uWSGI] getting INI configuration from mysite.ini
*** Starting uWSGI 1.9.13 (32bit) on [Sat Jul 27 19:23:43 2013] ***
compiled with version: 4.6.3 on 21 July 2013 03:35:50
os: Linux-3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 12:51:49 UTC 2012
nodename: example.me
machine: i686
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/local/bin/uwsgi

your processes number limit is 3922
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address /tmp/sockets/mysite.sock fd 3
Python version: 2.7.3 (default, Apr 10 2013, 06:03:17) [GCC 4.6.3]
Set PythonHome to /home/paul/.virtualenvs/dj
Python main interpreter initialized at 0x9bdb000
python threads support enabled
your server socket listen backlog is limited to 100 connections

your mercy for graceful operations on workers is 60 seconds
mapped 410112 bytes (400 KB) for 20 cores
*** Operational MODE: threaded ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x9bdb000 pid: 18213 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 18213)
spawned uWSGI worker 1 (pid: 18214, cores: 20)


Then I was left without a bash prompt. The uWSGI cli shows all the server requests and doesn't return to let me type another command. I really feel like there must be a better way to do this (aka. using 'sudo service uwsgi start/restart') but I'm not sure how. I have looked into this post but I'm not sure a different runlevel would solve the issue at hand.



Answer



Figure it out. Not sure I know how though.
I think it was the LOGTO portion of the uwsgi.conf file that made it not work. This is my uwsgi emperor file now:




description "uWSGI Emperor"

start on runlevel [2345]
stop on runlevel [!2345]


respawn

exec uwsgi --emperor /etc/uwsgi/vassals/ --master --uid www-data --gid www-data --logto /var/log/uwsgi/emperor.log


And this is my vassal, ie. mysite.ini




[uwsgi]
base = /home/paul/djprojs/mysite

chdir = %(base)
module = mysite.wsgi:application
pidfile = /tmp/uwsgi_vassal_%n.pid
socket = /tmp/sockets/%n.sock
vacuum = True
wsgi-file = /home/paul/djprojs/mysite/mysite/wsgi.py
home = /home/paul/.virtualenvs/dj


Still working on how to clean it up but it is working like a beaut.



TLS 1.2 client hello triggers TCP Reset from 2012 R2

Struggling with a PKI implementation in my lab (ADCS 2012 R2) and cannot for the life of me figure out where I have gone wrong.



Got all the way to the point of being able to generate SSL/TLS certs for an IIS server and make the binding. Also used the NARTAC tool to shut down SSLv2/3 + enable TLS 1.0-1.2. Using testssl.sh I can verify that SSL is disabled and can get a handshake for TLS 1.0 and 1.1, but every time the client hello for TLS 1.2 is received the server sends a TCP Reset. The system logs show the pair of SCHANNEL 36874 and 36888 error IDs that correspond with the resets. Error 36874 suggests that the client hello is presenting cipher suites that aren't supported by the server.




This is where I hit the brick wall, and my searching the interwebs is not yielding a winner. I can all but guarantee I've overlooked something glaringly obvious. However, the blinders of frustration are preventing me from seeing it.



Thoughts?



Client hello details:





Frame 136: 377 bytes on wire (3016 bits), 377 bytes captured (3016 bits) on interface 0 Ethernet II, Src: CiscoInc_07:be:7f
(fc:5b:39:07:be:7f), Dst: Vmware_01:02:14 (00:50:56:01:02:14) Internet

Protocol Version 4, Src: 192.168.6.75, Dst: 10.22.163.219 Transmission
Control Protocol, Src Port: 35836 (35836), Dst Port: 443 (443), Seq:
1, Ack: 1, Len: 311 Secure Sockets Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 306
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 302

Version: TLS 1.2 (0x0303)
Random
Session ID Length: 0
Cipher Suites Length: 176
Cipher Suites (88 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_DH_DSS_WITH_AES_256_GCM_SHA384 (0x00a5)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
Cipher Suite: TLS_DH_RSA_WITH_AES_256_GCM_SHA384 (0x00a1)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_DH_RSA_WITH_AES_256_CBC_SHA256 (0x0069)
Cipher Suite: TLS_DH_DSS_WITH_AES_256_CBC_SHA256 (0x0068)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x0037)
Cipher Suite: TLS_DH_DSS_WITH_AES_256_CBC_SHA (0x0036)
Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
Cipher Suite: TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0086)
Cipher Suite: TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0085)
Cipher Suite: TLS_GOSTR341001_WITH_28147_CNT_IMIT (0x0081)
Cipher Suite: TLS_GOSTR341094_WITH_28147_CNT_IMIT (0x0080)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)

Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_DH_DSS_WITH_AES_128_GCM_SHA256 (0x00a4)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
Cipher Suite: TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (0x00a0)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)

Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_DH_RSA_WITH_AES_128_CBC_SHA256 (0x003f)
Cipher Suite: TLS_DH_DSS_WITH_AES_128_CBC_SHA256 (0x003e)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DH_RSA_WITH_AES_128_CBC_SHA (0x0031)
Cipher Suite: TLS_DH_DSS_WITH_AES_128_CBC_SHA (0x0030)
Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a)
Cipher Suite: TLS_DHE_DSS_WITH_SEED_CBC_SHA (0x0099)
Cipher Suite: TLS_DH_RSA_WITH_SEED_CBC_SHA (0x0098)

Cipher Suite: TLS_DH_DSS_WITH_SEED_CBC_SHA (0x0097)
Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
Cipher Suite: TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0043)
Cipher Suite: TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0042)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)

Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA (0x0007)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)

Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA (0x0010)
Cipher Suite: TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA (0x000d)
Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)

Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 85
Extension: ec_point_formats
Extension: elliptic_curves
Extension: SessionTicket TLS
Extension: signature_algorithms

Type: signature_algorithms (0x000d)
Length: 32
Signature Hash Algorithms Length: 30
Signature Hash Algorithms (15 algorithms)
Extension: Heartbeat





And the TCP reset:





137 2.086290 10.22.163.219 192.168.6.75 TCP 54 443 → 35836 [RST, ACK]
Seq=1 Ack=312 Win=0 Len=0 Frame 137: 54 bytes on wire (432 bits), 54
bytes captured (432 bits) on interface 0 Ethernet II, Src:
Vmware_01:02:14 (00:50:56:01:02:14), Dst: IETF-VRRP-VRID_19
(00:00:5e:00:01:19) Internet Protocol Version 4, Src: 10.22.163.219,
Dst: 192.168.6.75 Transmission Control Protocol, Src Port: 443 (443),
Dst Port: 35836 (35836), Seq: 1, Ack: 312, Len: 0
Source Port: 443
Destination Port: 35836

[Stream index: 3]
[TCP Segment Len: 0]
Sequence number: 1 (relative sequence number)
Acknowledgment number: 312 (relative ack number)
Header Length: 20 bytes
Flags: 0x014 (RST, ACK)
Window size value: 0
[Calculated window size: 0]
[Window size scaling factor: 256]
Checksum: 0x74ff [validation disabled]

Urgent pointer: 0
[SEQ/ACK analysis]




SCHANNEL 36874




Log Name: System Source: Schannel Date: 5/4/2016
9:48:36 AM Event ID: 36874 Task Category: None Level:
Error Keywords: User: SYSTEM Computer:
OCSP.corp.contoso.com Description: An TLS 1.2 connection request was
received from a remote client application, but none of the cipher

suites supported by the client application are supported by the
server. The SSL connection request has failed.




SCHANNEL 36888:




Log Name: System Source: Schannel Date: 5/4/2016
9:48:36 AM Event ID: 36888 Task Category: None Level:
Error Keywords: User: SYSTEM Computer:
OCSP.corp.contoso.com Description: A fatal alert was generated and
sent to the remote endpoint. This may result in termination of the

connection. The TLS protocol defined fatal error code is 40. The
Windows SChannel error state is 1205.




EDIT 1



Found that I can successfully get a non-domain joined 2012 R2 IIS server to respond to a TLS 1.2 hello packet. So my issue appears to be related to being a domain joined system. Still haven't solved that part of the equation.

ubuntu - Garbled SSH packets, garbled HTML packets, but not in all situations



I am having a very strange problem with lost headers on packets when trying to contact a guest VM.




I have bare metal running CentOS 7 and VirtualBox v.5.0.14. I then have a guest running Ubuntu 15.10 using bridged networking. It has happily picked up its IP address from our DHCP server. The guest is running SSH and Apache.



All firewalls are disabled on VirtualBox host, guest and all clients used in the tests below.



I can SSH out from the guest to any other Linux host on our network. I can also connect to Windows Samba services, served out by Windows hosts =D




  • SSH and Apache work when accessing guest from VirtualBox host.
    Likewise, I can SSH to VBox host from guest =D

  • SSH and Apache work when accessing guest from an Ubuntu laptop =D


  • SSH and Apache work when accessing guest from CentOS 7 VM =D

  • SSH to the VBox host using PuTTY in Windows works fine =D



Everything is working as it should, right?




  • SSH from any Windows host using PuTTY results in a "Packet was garbled on decryption" error =(

  • Apache from any Windows host results in either unintelligible text output to the screen, or it attempts to download a file which contains the same unintelligible text, depending on the browser =(




Using Solaris to get the Apache web page or SSH gives us a little more insight. I'm guessing it's behaving the same as the Windows hosts, except we get more debugging output.



ssh fullyqualifiedguesthostname
0000 0000 0000 a89f
Disconnecting: Bad packet length 0.


The end of that line of numbers is different every time, with a hexadecimal string. i.e.
0000 0000 0000 xxxx




And when using wget to get the webpage...



wget --no-proxy fullyqualifiedguesthostname
--09:57:38-- fullyqualifiedguesthostname
=> `index.html'
Resolving fullyqualifiedguesthostname... x.x.x.x
Connecting to fullyqualifiedguesthostname|x.x.x.x|:80... connected.
HTTP request sent, awaiting response... 200 No headers, assuming HTTP/0.9
Length: unspecified


[ <=> ] 11,638 2.33K/s

09:57:43 (2.33 KB/s) - `index.html' saved [11638]


Note the No headers, assuming HTTP/0.9



Additionally, it takes a good few seconds to download this 11Kb file.




Using wget on an Ubuntu host:



wget --no-proxy fullyqualifiedguesthostname
--2016-02-26 10:08:06-- fullyqualifiedguesthostname
Resolving fullyqualifiedguesthostname (fullyqualifiedguesthostname)... x.x.x.x
Connecting to fullyqualifiedguesthostname (fullyqualifiedguesthostname)|x.x.x.x|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11321 (11K) [text/html]
Saving to: ‘index.html’


100%[=========================================================>] 11,321 --.-K/s in 0s

2016-02-26 10:08:06 (160 MB/s) - ‘index.html’ saved [11321/11321]


No problems, no message about missing headers, it is done in the blink of an eye, as you'd expect.



And now here are the first lines of the index.html file that was downloaded on the Solaris host:



cat index.html

.1 200 OK
Date: Fri, 26 Feb 2016 10:18:26 GMT
Server: Apache/2.4.12 (Ubuntu)
Last-Modified: Tue, 26 Jan 2016 15:38:24 GMT
ETag: "2c39-52a3e79e18489"
Accept-Ranges: bytes
Content-Length: 11321
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

Content-Type: text/html


Normal, unmolested HTML code follows this.



The index.html file downloaded on the Ubuntu host does NOT contain these first lines. It is just the HTML code.



I am assuming that the missing headers are what is causing the unintelligible text when accessing the web page from a Windows host - the browsers don't know what the file is and therefore don't know how to display it. I am also assuming that the same goes for the SSH failures - missing headers.



I should also note that I can ping the guest from anywhere, Windows, Linux, Solaris.




I think that just about captures all the variables in this web of confusion.



Does anyone know what the heck is going on?


Answer



I changed my guest OS's Network Adapter Type to "Paravirtualized Network (virtio-net)" and the problems all went away.


sub domain records



UPDATE 2:




Our website is created on RedHat Linux. We are using Apache as the web server software. Basically, we have our website on a LAMP configuration. We use rackspace managed hosting, but they do not manage our dns records. Our DNS records are managed by verizon, for which I have access too also.



UPDATE 1:



How do I create a sub-domain for our existing domain? If our existing domain was companyname.com, we would want a subdomain like users.companyname.com.



ORIGINAL QUESTION:



I've been given access to our dns records and need to create a sub domain. We currently have




companyname.com and www.companyname.com go to our web host at say 00.000.000.00



How do I create a new dns record so we can point users.companyname.com to a folder on our server at 00.000.000.00 instead of it going to the webroot of 00.000.000.00?


Answer



DNS will only point you to the IP/server. Then you must use Apache to direct to a different folder. First setup the CName or A record with Verizon's interface for DNS. Point to the server that will be hosting the site. You can confirm that it works by pinging the name and getting the correct IP back.



Then the next step isn't related to DNS. It's Apache related. If you still have questions about that, start a fresh question or re-flag this as an Apache question.


linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...