20170408/UGR Project - Revision history

Admin at 21:43, 16 April 2017

2017-04-16T21:43:56Z

← Older revision		Revision as of 21:43, 16 April 2017
Line 1:		Line 1:
	~~{{Orphan\|date=April 2017}}~~
	Here is the status of getting ssh and rsync up and working over rsync (raspberry pis using dropbear).		Here is the status of getting ssh and rsync up and working over rsync (raspberry pis using dropbear).

Bleep bloop: Bot: Orphan page, add template

2017-04-16T03:27:21Z

Bot: Orphan page, add template

← Older revision		Revision as of 03:27, 16 April 2017
Line 1:		Line 1:
			{{Orphan\|date=April 2017}}
	Here is the status of getting ssh and rsync up and working over rsync (raspberry pis using dropbear).		Here is the status of getting ssh and rsync up and working over rsync (raspberry pis using dropbear).

Admin at 06:07, 9 April 2017

2017-04-09T06:07:04Z

← Older revision		Revision as of 06:07, 9 April 2017
Line 36:		Line 36:
	* Better organization of stunnel - since each service requires different configurations and ports should be easy to switch in and out.		* Better organization of stunnel - since each service requires different configurations and ports should be easy to switch in and out.

			Successful experiment and experimental data acquisition:
			* Ran aircrack collection script on both pis
			* Ran rsync stunnel forever loop in another tab
			* Collected 30 minutes of data
			* Verified data was transferred to server successfully

			What comes next?
			* Data aggregation and database population script
			* MongoDB population/extraction scripts
			* Jupyter notebooks for data analysis

Admin at 05:35, 9 April 2017

2017-04-09T05:35:33Z

@@ Line 25: / Line 25: @@
 Note: can also run multiple instances of stunnel - one for each port. Thus, can forward port 2222 to remote server ssh service, and forward port 873 to remote server rsync service, by using two instances of stunnel using two external ports. I'm using one instance of stunnel to forward local port 2222 to external port 443, and a second instance of stunnel to forward local port 873 to external port 273.
@@ Line 34: / Line 45: @@
 [[Category:Networking]]
 [[Category:Linux]]

Admin at 22:29, 8 April 2017

2017-04-08T22:29:33Z

← Older revision		Revision as of 22:29, 8 April 2017
Line 1:		Line 1:
	~~Current status: FIXING STUNNEL CONTAINER.~~		Here is the status of getting ssh and rsync up and working over rsync (raspberry pis using dropbear).
	* Each time I try and replicate this pipeline, a different piece goes wrong.
	* This time, it's been the rsync stunnel container's secure communications port, 273, not opening up between host/container.
	* This is why we need Docker - so much bullshit involved in configuring Linux networking services. It isn't the technical complexity that's bullshit, it's the bazillion tiny switches that must be aligned just-so, but aren't explicitly documented, or are documented, but somewhere in a 473-page document.

	~~Okay, here~~ is the status of getting ssh and rsync up and working over rsync.

	ssh over stunnel: works ok.		ssh over stunnel: works ok.

Admin at 22:27, 8 April 2017

2017-04-08T22:27:57Z

← Older revision		Revision as of 22:27, 8 April 2017
Line 2:		Line 2:
	* Each time I try and replicate this pipeline, a different piece goes wrong.		* Each time I try and replicate this pipeline, a different piece goes wrong.
	* This time, it's been the rsync stunnel container's secure communications port, 273, not opening up between host/container.		* This time, it's been the rsync stunnel container's secure communications port, 273, not opening up between host/container.
	* This is why we need Docker - so much bullshit involved in configuring Linux networking services. I'~~m not calling~~ technical complexity bullshit, I'~~m calling hypernuanced~~, ~~undocumented~~, ~~impossible~~-~~to-debug network configuration and hardware issues bullshit~~.		* This is why we need Docker - so much bullshit involved in configuring Linux networking services. It isn't the technical complexity that's bullshit, it's the bazillion tiny switches that must be aligned just-so, but aren't explicitly documented, or are documented, but somewhere in a 473-page document.

	Okay, here is the status of getting ssh and rsync up and working over rsync.		Okay, here is the status of getting ssh and rsync up and working over rsync.

Admin at 22:26, 8 April 2017

2017-04-08T22:26:51Z

← Older revision		Revision as of 22:26, 8 April 2017
Line 29:		Line 29:
	* Ensure external port 273 is open with <code>nmap localhost</code>		* Ensure external port 273 is open with <code>nmap localhost</code>

	Note: can also run multiple instances of stunnel - one for each port. Thus, can forward port 2222 to remote server ssh service, and forward port 873 to remote server rsync service.		Note: can also run multiple instances of stunnel - one for each port. Thus, can forward port 2222 to remote server ssh service, and forward port 873 to remote server rsync service, by using two instances of stunnel using two external ports. I'm using one instance of stunnel to forward local port 2222 to external port 443, and a second instance of stunnel to forward local port 873 to external port 273.

Admin at 22:25, 8 April 2017

2017-04-08T22:25:21Z

← Older revision		Revision as of 22:25, 8 April 2017
Line 16:		Line 16:
	* Client can run 2nd instance of stunnel, local port 873 open		* Client can run 2nd instance of stunnel, local port 873 open

	~~this is where~~ we ~~step into~~ the ~~problem~~.		(Previously, we were not seeing the stunnel port opening. Turned out this was because there was no local rsync server listening on port 873, so stunnel had no service to connect to.)

	rsync on the server:		rsync on the server:
Line 28:		Line 28:
	* The rsync service must be ready on port 873 when docker stunnel starts, or the connection will not be made		* The rsync service must be ready on port 873 when docker stunnel starts, or the connection will not be made
	* Ensure external port 273 is open with <code>nmap localhost</code>		* Ensure external port 273 is open with <code>nmap localhost</code>

			Note: can also run multiple instances of stunnel - one for each port. Thus, can forward port 2222 to remote server ssh service, and forward port 873 to remote server rsync service.





	[[Category:Stunnel]]		[[Category:Stunnel]]
	[[Category:April 2017]]]		[[Category:April 2017]]
	[[Category:Networking]]		[[Category:Networking]]
	[[Category:Linux]]		[[Category:Linux]]

Admin at 22:07, 8 April 2017

2017-04-08T22:07:22Z

← Older revision		Revision as of 22:07, 8 April 2017
Line 16:		Line 16:
	* Client can run 2nd instance of stunnel, local port 873 open		* Client can run 2nd instance of stunnel, local port 873 open

			this is where we step into the problem.

			rsync on the server:
			* rsync is running on the host machine, not in a docker. (Next steps.)
			* To start rsync service, use <code>sudo service rsync start</code>
			* Note that rsync will NOT print out error messages, it will fail silently. Check its status to ensure it is running via <code>systemctl status rsync.service</code>
			* Once it is running, your rysnc server instance should be ready and waiting for input

			stunnel on the server:
			* stunnel is running via docker
			* The rsync service must be ready on port 873 when docker stunnel starts, or the connection will not be made
			* Ensure external port 273 is open with <code>nmap localhost</code>

Admin at 21:07, 8 April 2017

2017-04-08T21:07:19Z

← Older revision		Revision as of 21:07, 8 April 2017
Line 3:		Line 3:
	* This time, it's been the rsync stunnel container's secure communications port, 273, not opening up between host/container.		* This time, it's been the rsync stunnel container's secure communications port, 273, not opening up between host/container.
	* This is why we need Docker - so much bullshit involved in configuring Linux networking services. I'm not calling technical complexity bullshit, I'm calling hypernuanced, undocumented, impossible-to-debug network configuration and hardware issues bullshit.		* This is why we need Docker - so much bullshit involved in configuring Linux networking services. I'm not calling technical complexity bullshit, I'm calling hypernuanced, undocumented, impossible-to-debug network configuration and hardware issues bullshit.

			Okay, here is the status of getting ssh and rsync up and working over rsync.

			ssh over stunnel: works ok.
			* Client is pi on dropbear, connected directly to router which is connected to internet
			* Client can run stunnel, local port 2222 open
			* Server can run stunnel, port 443 open
			* Able to connect the stunnel client and server just fine

			rsync over stunnel:
			* Client is pi on dropbear, connected directly to router which is connected to internet
			* Client can run 2nd instance of stunnel, local port 873 open





			[[Category:Stunnel]]
			[[Category:April 2017]]]
			[[Category:Networking]]
			[[Category:Linux]]