Screen - Revision history

Support: /* Screen Organization */

2013-03-04T22:30:17Z

Screen Organization

← Older revision		Revision as of 15:30, 4 March 2013
Line 226:		Line 226:
	7 - jail7 root shell		7 - jail7 root shell
	8 - jail8 root shell		8 - jail8 root shell
	8 - jail9 root shell		9 - jail9 root shell

	Window 4:		Window 4:

Support at 01:11, 1 March 2013

2013-03-01T01:11:52Z

← Older revision		Revision as of 18:11, 28 February 2013
Line 1:		Line 1:
	~~_TOC_~~		__TOC__

	= Overview =		= Overview =

Support at 01:11, 1 March 2013

2013-03-01T01:11:44Z

← Older revision		Revision as of 18:11, 28 February 2013
Line 1:		Line 1:
	~~<<TOC>>~~		_TOC_

	= Overview =		= Overview =

Support at 01:11, 1 March 2013

2013-03-01T01:11:34Z

← Older revision		Revision as of 18:11, 28 February 2013
Line 1:		Line 1:
			<<TOC>>

	= Overview =		= Overview =
	Screen is essentially `nohup` on steroids. Screen is a userland application that allows one to start interactive login sessions, detach them, and later reattach them. Screen is extremely helpful in the following three manners:		Screen is essentially `nohup` on steroids. Screen is a userland application that allows one to start interactive login sessions, detach them, and later reattach them. Screen is extremely helpful in the following three manners:

Support: /* Screen Organization */

2012-12-06T01:21:00Z

Screen Organization

← Older revision		Revision as of 18:21, 5 December 2012
Line 222:		Line 222:
	1 - jail1 root shell		1 - jail1 root shell
	2 - jail2 root shell		2 - jail2 root shell
	~~5 - jail5 root shell~~
	~~6 - jail6 root shell~~
	7 - jail7 root shell		7 - jail7 root shell
	8 - jail8 root shell		8 - jail8 root shell
Line 231:		Line 229:
	0 - mx1 root shell		0 - mx1 root shell
	1 - jail11 root shell		1 - jail11 root shell
	~~2 - jail12 root shell~~
	3 - mx2 root shell		3 - mx2 root shell
	6 - jail16 root shell		6 - jail16 root shell
Line 240:		Line 237:
	Window 5:		Window 5:
	0 - quar1 root shell		0 - quar1 root shell
	~~1 - tempvirt1 root shell~~
	9 - virt9 root shell		9 - virt9 root shell

	Window 6:		Window 6:
	~~0 - virt10 root shell~~
	1 - virt11 root shell		1 - virt11 root shell
	2 - virt12 root shell		2 - virt12 root shell

70.230.212.110: /* Screen Organization */

2012-11-28T21:06:51Z

Screen Organization

← Older revision		Revision as of 14:06, 28 November 2012
Line 189:		Line 189:
	The main johncompanies server which hosts all the screens is simply nat.johncompanies.com (or 69.55.233.195). Simply ssh as your user to nat.johncompanies.com, and your home directory will contain the "dr" (or 'hr') script for reattaching.		The main johncompanies server which hosts all the screens is simply nat.johncompanies.com (or 69.55.233.195). Simply ssh as your user to nat.johncompanies.com, and your home directory will contain the "dr" (or 'hr') script for reattaching.

	The window organization is as follows:		The window organization is roughly as follows (the actual way you organize your screens is up to you, this is the organization for the user 'user'):

	~~Note: windows in grey may not exist in your screen org~~
	<pre>		<pre>
	Window 0:		Window 0:

70.230.212.110: /* Screen Organization */

2012-11-28T19:48:51Z

Screen Organization

← Older revision		Revision as of 12:48, 28 November 2012
Line 257:		Line 257:

	(note- order of "O" windows may not always be accurate. Simply cycle through them till you find the server you want with the sequence: ctrl-o n)		(note- order of "O" windows may not always be accurate. Simply cycle through them till you find the server you want with the sequence: ctrl-o n)
	P0 -		P0:
	O0 - 3750		O0 - 3750
	O1 - switch-p1		O1 - switch-p1a
	O2 - switch-p2		O2 - switch-p1b
	O3 - switch-p3		O3 - switch-mx1
	O4 - switch-p4		O4 - switch-mx2
	O5 - switch-p5		O5 - switch-3550
	O6 - switch-p6		O6 - switch-p1
	O7 - switch-p7		O7 - switch-p3
	O8 - switch-p8		O8 - switch-p4
	O9 - switch-p9		O9 - switch-p13
	O10 - switch-~~p10~~		O10 - switch-p16
	O11 - switch-~~p11~~		O11 - switch-p17
	~~O12 - switch-p12~~
	~~O13 - switch-p13~~
	~~O14 - switch-p14~~
	~~O15 - switch-p15~~
	~~O17 - office-gw~~
	~~O18 - switch-m1~~
	~~O19 - switch-m2~~

			P1:
	P1 -
	O0 - nat		O0 - nat
	O1 - ~~newgateway (live firewall)~~		O1 - mail
	O2 - ~~gate (backup firewall)~~		O2 - bwdb
	O3 - ~~mail~~		O3 - backup1
	O4 - ~~bwdb~~		O4 - backup2
	O5 - ~~backup2~~		O5 - firewall (live firewall)
			O6 - gate (backup firewall)

	P2 -		P2:
	O0 - jail1 serial console		O0 - jail1 serial console
	O1 - ~~jail3~~ serial console		O1 - jail2 serial console
	O2 - ~~jail4~~ serial console		O2 - jail3 serial console
	O3 - ~~jail6~~ serial console		O3 - jail7 serial console
	O4 - ~~jail7~~ serial console		O4 - jail8 serial console
	O5 - ~~jail2~~ serial console ~~(tip cab3-5)~~		O5 - jail9 serial console
	~~O7 - mx2~~

	P3 -		P3:
	O0 - mx1 serial console		O0 - mx1 serial console
	O1 - ~~jail11~~ serial console		O1 - mx2 serial console
	O2 - ~~jail12~~ serial console		O2 - jail11 serial console
	~~O3 - jail15 serial console~~		O2 - jail17 serial console
	~~O4 - jail16 serial console~~		O3 - jail18 serial console
	O5 - jail17 serial console		O4 - jail19 serial console
	O6 - jail18 serial console
	O7 - jail19 serial console

	P4 -		P4:
	O0 - quar1 serial console		O0 - quar1 serial console
	O1 - virt9 serial console		O1 - virt9 serial console
	~~TODO – not working:~~		O2 - virt11 serial console
	O - ~~tempvirt1~~ serial console		O3 - virt12 serial console
	~~O - tempvirt2 serial console~~		O4 - virt13 serial console
			O5 - virt15 serial console
	~~P5 -~~		O6 - virt16 serial console
	~~O0 - virt10 serial console~~		O7 - virt17 serial console
	O1 - virt12 ~~serial console~~
	~~O3 - virt14~~ serial console
	O4 - ~~virt15~~ serial console
	O5 - ~~virt16~~ serial console
	O6 - ~~virt17~~ serial console
	O7 - ~~virt18~~ serial console
	O8 - virt19 serial console		O8 - virt19 serial console

	P6 -		P5: (i2b)
	O0 - ~~serial console for colos~~		O0 - switch-p20
	~~Valid cabinets are: cab3~~-~~6, cab5~~-~~16, cab3~~-~~5, cab3~~-~~9, cab3~~-~~10, cab2~~-~~8, cab2~~-~~3, cab4~~-9		O1 - switch-p21
			O2 - switch-p22
			O3 - switch-p23
			O4 - switch-p24
			O5 - switch-p25
			O6 - switch-p26
			O7 - switch-p27
			O8 - nat2
			O9 - firewall2
			O10 - backup3
			O11 - bwdb2

	~~Window 8~~: (~~i2b servers~~)		P6: (spare @ castle)
	~~0 - nat2 root shell~~
	~~1 - ns3c root shell, pwd = /etc/namedb/s~~
	~~2 - firewall2 root shell~~
	~~3 - backup3 root shell~~

	Window 9:		Window 9:

70.230.212.110: /* Overview */

2012-11-09T22:49:00Z

Overview

← Older revision		Revision as of 15:49, 9 November 2012
Line 4:		Line 4:
	#Safety. It allows for sensitive interactive work through sshd on unreliable network connections. Imagine if you were running a dump or restore of a filesystem, or running a newfs on a filesystem, or some other sensitive action that, if interrupted, would not only halt the action itself, but could jeopordize the targets of these actions by leaving them in a half-done state that cannot be resumed - all you could do is log back on, kill the process, and try to salvage what was left and start over. However, if you were running that process in a screen window, if your connection died you could simply reattach to that screen window - as if you had never lost connection at all.		#Safety. It allows for sensitive interactive work through sshd on unreliable network connections. Imagine if you were running a dump or restore of a filesystem, or running a newfs on a filesystem, or some other sensitive action that, if interrupted, would not only halt the action itself, but could jeopordize the targets of these actions by leaving them in a half-done state that cannot be resumed - all you could do is log back on, kill the process, and try to salvage what was left and start over. However, if you were running that process in a screen window, if your connection died you could simply reattach to that screen window - as if you had never lost connection at all.
	#Location Portability. If you are logged into a system from point A, and later you go to point B, you cannot regain the exact same session in point B - any new login to the system would be just that - a new login. However, if your session is "screened", you can detach it, and re-attach at the new location, and present yourself with the exact same login session as you started with.		#Location Portability. If you are logged into a system from point A, and later you go to point B, you cannot regain the exact same session in point B - any new login to the system would be just that - a new login. However, if your session is "screened", you can detach it, and re-attach at the new location, and present yourself with the exact same login session as you started with.
			# Organization. Because screen has multiple windows, and those windows can be nested, you can arrange a large number (no more than 100, practically speaking) of login sessions all in one ssh session. So you need only keep one single terminal window (or putty or secureCRT in Windows) open at any given time.
	# Organization

	Because screen has multiple windows, and those windows can be nested, you can arrange a large number (no more than 100, practically speaking) of login sessions all in one ssh session. So you need only keep one single terminal window (or putty or secureCRT in Windows) open at any given time.

	You start screen simply by logging into a system and running:		You start screen simply by logging into a system and running:
Line 48:		Line 45:

	# Do not run more than one screen session on the same host at the same time (update- we can do this if we run with –m). If you log in from one place and start a screen, and then login from another place and start a second screen, theoretically you can reattach to them selectively with their process IDs. However, if one or both of them is detached ungracefully (through loss of connection, rather than running ctrl-a, d, to detach) in practice one or both of them will be zombie-fied and will have to be killed from the command line - and all windows open in each screen will be killed off as well. So don't start more than one screen session on one host at the same time.		# Do not run more than one screen session on the same host at the same time (update- we can do this if we run with –m). If you log in from one place and start a screen, and then login from another place and start a second screen, theoretically you can reattach to them selectively with their process IDs. However, if one or both of them is detached ungracefully (through loss of connection, rather than running ctrl-a, d, to detach) in practice one or both of them will be zombie-fied and will have to be killed from the command line - and all windows open in each screen will be killed off as well. So don't start more than one screen session on one host at the same time.

	# Always force a detach of a screen before reattaching it. Generally, we are logged in and using a screen, and then we detach the screen with:		# Always force a detach of a screen before reattaching it. Generally, we are logged in and using a screen, and then we detach the screen with:

70.230.212.110: /* Overview */

2012-11-09T22:48:27Z

Overview

← Older revision		Revision as of 15:48, 9 November 2012
Line 3:		Line 3:

	#Safety. It allows for sensitive interactive work through sshd on unreliable network connections. Imagine if you were running a dump or restore of a filesystem, or running a newfs on a filesystem, or some other sensitive action that, if interrupted, would not only halt the action itself, but could jeopordize the targets of these actions by leaving them in a half-done state that cannot be resumed - all you could do is log back on, kill the process, and try to salvage what was left and start over. However, if you were running that process in a screen window, if your connection died you could simply reattach to that screen window - as if you had never lost connection at all.		#Safety. It allows for sensitive interactive work through sshd on unreliable network connections. Imagine if you were running a dump or restore of a filesystem, or running a newfs on a filesystem, or some other sensitive action that, if interrupted, would not only halt the action itself, but could jeopordize the targets of these actions by leaving them in a half-done state that cannot be resumed - all you could do is log back on, kill the process, and try to salvage what was left and start over. However, if you were running that process in a screen window, if your connection died you could simply reattach to that screen window - as if you had never lost connection at all.

	#Location Portability. If you are logged into a system from point A, and later you go to point B, you cannot regain the exact same session in point B - any new login to the system would be just that - a new login. However, if your session is "screened", you can detach it, and re-attach at the new location, and present yourself with the exact same login session as you started with.		#Location Portability. If you are logged into a system from point A, and later you go to point B, you cannot regain the exact same session in point B - any new login to the system would be just that - a new login. However, if your session is "screened", you can detach it, and re-attach at the new location, and present yourself with the exact same login session as you started with.

70.230.212.110: /* Overview */

2012-11-09T22:48:16Z

Overview

← Older revision		Revision as of 15:48, 9 November 2012
Line 2:		Line 2:
	Screen is essentially `nohup` on steroids. Screen is a userland application that allows one to start interactive login sessions, detach them, and later reattach them. Screen is extremely helpful in the following three manners:		Screen is essentially `nohup` on steroids. Screen is a userland application that allows one to start interactive login sessions, detach them, and later reattach them. Screen is extremely helpful in the following three manners:

	# Safety		#Safety. It allows for sensitive interactive work through sshd on unreliable network connections. Imagine if you were running a dump or restore of a filesystem, or running a newfs on a filesystem, or some other sensitive action that, if interrupted, would not only halt the action itself, but could jeopordize the targets of these actions by leaving them in a half-done state that cannot be resumed - all you could do is log back on, kill the process, and try to salvage what was left and start over. However, if you were running that process in a screen window, if your connection died you could simply reattach to that screen window - as if you had never lost connection at all.

	It allows for sensitive interactive work through sshd on unreliable network connections. Imagine if you were running a dump or restore of a filesystem, or running a newfs on a filesystem, or some other sensitive action that, if interrupted, would not only halt the action itself, but could jeopordize the targets of these actions by leaving them in a half-done state that cannot be resumed - all you could do is log back on, kill the process, and try to salvage what was left and start over. However, if you were running that process in a screen window, if your		#Location Portability. If you are logged into a system from point A, and later you go to point B, you cannot regain the exact same session in point B - any new login to the system would be just that - a new login. However, if your session is "screened", you can detach it, and re-attach at the new location, and present yourself with the exact same login session as you started with.
	~~connection died you could simply reattach to that screen window - as if you had never lost connection at all.~~

	# Location Portability

	If you are logged into a system from point A, and later you go to point B, you cannot regain the exact same session in point B - any new login to the system would be just that - a new login. However, if your session is "screened", you can detach it, and re-attach at the new location, and present yourself with the exact same login session as you started with.

	# Organization		# Organization
Line 192:		Line 187:

	Another note about this- you can also ctrl-a, then <escape> to get at screen history. This is usually only useful as a means to get at history which was lost in a “p” window. But note that this history will be all over the map as it includes history from any of the sub-p screens which the a screen contains.		Another note about this- you can also ctrl-a, then <escape> to get at screen history. This is usually only useful as a means to get at history which was lost in a “p” window. But note that this history will be all over the map as it includes history from any of the sub-p screens which the a screen contains.


	= Screen Organization =		= Screen Organization =