# built debian server to host tivo hd recordings, next steps?



## markmarz (Feb 3, 2002)

Woo hoo!! Installed debian on my new home-built off a usb drive (that was a challenge in itself); everything's cool! In fact I'm writing to you now from Iceweasal on the new server.

I know I'd like the server to run headless and I know that involves running xdmcp to allow me to bring up the desktop remotely, say on my windows laptop; and I know I need to share the filesystem(s) on the server, but I could use a hint how to accomplish all that.

Meantime I'll keep digging.

Thanks!


----------



## lrhorer (Aug 31, 2003)

Since you are posting from IceWeasel, I take it you are running a desktop already. That being the case, you already have X up and running. One thing (I don't recall) are you running an Intel or AMD system? I don't know if it has been fixed, but there was a small bug that caused some Intel based systems to lock up on boot if there was no display. It's a fairly easy fix if it happens, so report back if you cannot bring up your system without a monitor attached while running X.

The following assumes you have a secure network, specifically a NAT firewall providing internet access. If not, we will need to talk about implementing a firewall on the server. I recommend the external firewall, but if you don;t want to or for some reason are unable to implement the external firewall, ping back and we can secure your system before moving forward.

Meanwhile, the first step is to make sure the server has a fixed IP. A dynamic IP and servers do not mix well. Your clients really need to know where they can find the server without a lot of contortions.

Next you need to open up the system to respond to XDMCP requests.

Finally, you should have ssh enabled.

OK, to get started, open up a terminal session. Switch to the root user identity (please, no grumbles from paternalistic Linux types) by typing `su` and entering the root password at the password prompt. Type each of the following, allowing the system to install each software:


```
apt-get install vim
apt-get install openssh-server
```
To edit a file, issue the command


```
vim <filename>
```
Vi and vim are a bit arcane, but for your purposes all you need to know is pressing the <insert> key once enters insert mode. Pressing it successive times toggles between insert and overwrite mode. To exit either editing mode, press <Esc>. To save and quit the file, (after exiting the edit mode by pressing <Esc> ) press :wq! To exit without saving, type :q!

Edit the interfaces file by typing


```
vim /etc/network/interfaces
```
and make it look something like the following (choose the IP address as you like, making sure it is not an address your router will try to set automatically):


```
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.xxx.yyy
netmask 255.255.255.0
gateway 192.168.xxx.1
auto eth0
```
(This assumes your gateway router is 192,168.xxx.1)
Save and quit the file by pressing <Esc>:wq!

To enable the IP so you can use it without rebooting the machine, type

/etc/init.d/networking restart (Deprecated)


```
ifdown eth0
ifup eth0
```
The next step depends on whether you are using gdm or kdm as your display manager.

If you are using gdm, then editing the /etc/gdm/gdm.conf file to contain the lines


```
[xdmcp]
Enable=true
```
and then issuing the command


```
/etc/init.d/gdm restart
```
should allow you to log in to the server with an X-server such as X-ming or Exceed Hummingbird from a networked computer. Of course you will need to install the X-server of your choice on the remote machine, first. There is a free version of X-ming available for Windows.

If you are using kdm (which I prefer) as your display manager, then edit the /etc/kde4/kdm/kdmrc file to contain the same two lines. Note there are a great many more options in /etc/kde4/kdm/kdmrc, and you might like to study them to see what other options for logging in you may want to implement. Once again, issue the


```
/etc/init.d/kdm restart
```
command to enable your changes.


----------



## wmcbrine (Aug 2, 2003)

markmarz said:


> I know I'd like the server to run headless and I know that involves running xdmcp to allow me to bring up the desktop remotely


That's not really necessary. Unlike in Windows, in Linux you can do most of what you need to from the command line, so telnet or ssh is sufficient. On the rare occasions when I want to run an X app remotely, I just do an "ssh -X" and start the app from the command line.

Leaving an X environment running full-time on a headless server can be a waste of server resources.


----------



## markmarz (Feb 3, 2002)

Sounds good. So ssh -X will enable me to later kick off kmttg, right?

I avoid running X full-time by not kicking off xdmcp?

Sorry for the dumb questions .. long-time programmer, been using Solaris for years and now AIX at work, but novice linux administrator. I found this site this morning: http://www.linux-tutorial.info. Seems like a good start; there's some I know, but only picked up haphazardly. I learn best by starting at the beginning.


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> Since you are posting from IceWeasel, I take it you are running a desktop already. That being the case, you already have X up and running. One thing (I don't recall) are you running an Intel or AMD system?


amd-64



> if you don't want to or for some reason are unable to implement the external firewall, ping back and we can secure your system before moving forward.


ping!

I've been looking around at linux security since reading your reply and realize this is going to require a whole heck of a lot of background study. I'm not adverse to having the incantations handed over w/o much of an understanding in the interests of expediency! I'm going to hold off on further steps as you suggest until security is set up. I'll be trying to learn the basics in the meantime.



> The next step depends on whether you are using gdm or kdm as your display manager.


Don't know for sure but I think GDM. I'm using LXDE, is that a clue?


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> apt-get install vim
> apt-get install openssh-server


Well, I did just go ahead and attempted to add this software; didn't seem like that would hurt. Although vim installed fine, having a problem with openssh-server:


```
Media change: please insert the disc labeled
 'Debian GNU/Linux 6.0.5 _Squeeze_ - Official amd64 xfce+lxde-CD Binary-1 20120512-14:33'
in the drive '/media/cdrom/' and press enter
```
The sad thing is I didn't actually install from a physical cd; I installed from a cd image put to a usb stick via win32 disk imager because I don't have a cd player right now. Tried re-inserting usb stick but didn't help. I also know diddly-squat about filesystems on linux so no idea how to (say) point to the usb stick if pointing is what's needed. I will be getting a cd player in a few days; I could write the install image to it and try from there.


----------



## markmarz (Feb 3, 2002)

Okay, problem solved. Installed synaptic and disabled cd rom image from package sources, then installed openssh-server.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> Okay, problem solved. Installed synaptic and disabled cd rom image from package sources, then installed openssh-server.


Yep. The sources list is kept at /etc/apt/sources.list. I'm a little surprised the CD-ROM source was kept there, since you did a netinst installation.

I don't much like Synaptic, but it does get the job done. I much prefer kpackage, but for some bizarre reason they have decided to pull it from development. I'm using a back port. Don't worry about the file systems. Linux can take care of all that for you until you are ready to format your array (or whatever you decide to deploy). For a video server, I like XFS. It handles underlying arrays expeditiously, and it is very fast at creating and writing files. It tends to be a bit slow at deleting thousands of files, but on a video server, that almost never happens.


----------



## markmarz (Feb 3, 2002)

Thanks, I will go with XFS. Seems particularly well suited to my enormous TD HD files, which should be the overwhelming majority of user files.



> ping back and we can secure your system before moving forward


In the meantime, I would like to implement a software firewall (don't want to buy an external firewall) .. is this offer still on?

Other than wireless security (but this server is wired to switch as is the pc I plan to remote into it with), and whatever firewall features are implemented by default in the DLink 655 router, I'm not aware of any other security on the network.



> specifically a NAT firewall providing internet access


Don't know, but don't think I have that. I'm reluctant to move forward until the system is secure, or at least secure enough. Or does going forward with your instructions starting with


> the first step is to make sure the server has a fixed IP


 all I need to do?


----------



## lrhorer (Aug 31, 2003)

wmcbrine said:


> That's not really necessary. Unlike in Windows, in Linux you can do most of what you need to from the command line, so telnet or ssh is sufficient. On the rare occasions when I want to run an X app remotely, I just do an "ssh -X" and start the app from the command line.


It's true it is not strictly necessary, and I frequently spawn independent X apps in their own windows. There are some advantages to using a native Desktop manager, however. Among them are the ability to automatically launch a suite of apps on the server upon login under a single desktop, having multiple desktops, and I find operations like cut-and-paste to be much, much easier under KDE than Windows.



wmcbrine said:


> Leaving an X environment running full-time on a headless server can be a waste of server resources.


Yeah, but I don't think he is going to be doing it full time. Of course, neither way is terribly difficult. What's more, on modern systems, the use of resources by the X environment is not really aggressive compared to their capabilities. I have an XDMCP KDE session up right now on one of my servers with kmttg, five terminal sessions, kpackage, Gnome System Monitor, and KNUT client all running. One CPU is below 4%, and the other is running 26%, but only because the monthly array check is running. Ordinarily, they would both be well under 4%. Memory is 2.7G out of 4G, with 1G of swap. Normally, swap would be under 800K, but wine is using a pretty big chunk.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> Thanks, I will go with XFS. Seems particularly well suited to my enormous TD HD files, which should be the overwhelming majority of user files.


Yeah, it is.



markmarz said:


> In the meantime, I would like to implement a software firewall (don't want to buy an external firewall) .. is this offer still on?
> 
> Other than wireless security (but this server is wired to switch as is the pc I plan to remote into it with), and whatever firewall features are implemented by default in the DLink 655 router, I'm not aware of any other security on the network.


Unless you have its firewall disabled, the D-Link 655 *IS* an external firewall. As long as the firewall on the 655 is enabled and you have your wireless segments properly secured, that is all that is needed. We certainly could implement iptables, but it really is not necessary.



markmarz said:


> Don't know, but don't think I have that. I'm reluctant to move forward until the system is secure, or at least secure enough. Or does going forward with your instructions starting with all I need to do?


Yeah, just make sure your passwords are strong, and that the local wireless network is locked down tight. You can run an insecure guest network, if you like. Disallowing remote root logins (which should be the default) is a good idea.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> Sounds good. So ssh -X will enable me to later kick off kmttg, right?


On the Linux machine, yes. Of course you can, if you choose, run kmttg on a remote (presumably windows) machine and simply have it write to the server. For your purposes, it is probably 6 of one and half a dozen of the other.



markmarz said:


> I avoid running X full-time by not kicking off xdmcp?


Yes. Perhaps more to the point, the desktop manager is then Windows, not the Linux GUI.



markmarz said:


> Sorry for the dumb questions


They aren't dumb.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> amd-64


Oh, good. 'Definitely won't be a problem, then.



markmarz said:


> I've been looking around at linux security since reading your reply and realize this is going to require a whole heck of a lot of background study.


Yeah. Iptables is extremely powerful, but damnably arcane.



markmarz said:


> I'm not adverse to having the incantations handed over w/o much of an understanding in the interests of expediency! I'm going to hold off on further steps as you suggest until security is set up. I'll be trying to learn the basics in the meantime.


Well, OK, there may be some things in there you want to implement, but for now, as long as you have the firewall on the 655 set up properly and have that wireless network locked up tight, it should be fine.



markmarz said:


> Don't know for sure but I think GDM. I'm using LXDE, is that a clue?


No, I'm afraid not. I'm not very familiar with LXDE, but unless it has some requirements of which I am unaware, it should be able to run under either gdm or kdm. Indeed, until 2009, it had to run under one or the other of those. In 2009, LXDM, a display manager written specifically for LXDE was released, but I am not sure it is supported under Debian. (LXDE definitely is.)
There is a simple way to tell, though. Look at the contents of /etc/default-display-manager. It will tell you what display manager is in use.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> and I know I need to share the filesystem(s) on the server, but I could use a hint how to accomplish all that.


The short answer to that is: SAMBA.

Depending on the options you selected during install, SAMBA may already be installed. You can check using Synaptic, or just type


```
apt-get install samba
```
If it is not installed automatically, I also recommend


```
apt-get install swat
```
SWAT (SAMBA Web Administration Tool) allows one to configure and administer SAMBA via web browser from any machine on the LAN.

As always, if SAMBA or SWAT are already installed and configured, apt-get will notify you of the fact.

Now the first question is, "How secure does the share need to be?" If you want anyone on the LAN to be able to read, write, and delete files on the share, things get pretty simple. If you want to restrict access, they can get rather more complicated. Note there is absolutely nothing wrong with creating more than one directory on the array, with some of the directories being shared wide open and others being locked down. For example, I created several separate wide open shares for video, music, DVD rips, etc. I also created a personal directory for myself, one for my roommate, and one for each of her daughters. Both on the server itself and on the shares, no one but me can read or write my directory, only my roommate can read and write her directory, etc.

After you install SAMBA, you will need to create SAMBA users. These are very much like regular Linux users, and indeed it may be a good idea to create the same SAMBA users as Linux users. To that end, the use of mksmbpasswd before the first time SAMBA is run will copy all the Linux users over to the /etc/smbpasswd file. The passwords will not be copied. Once you have all your Linux users created, type:


```
cat /etc/passwd | /usr/sbin/mksmbpasswd > /etc/samba/smbpasswd
```
Then use the smbpasswd utility to create the passwords for SAMBA. Here is a good basic tutorial on setting up SAMBA. Below is a copy of my /etc/samba/smb.conf file:


```
RAID-Server:/usr/bin# cat /etc/samba/smb.conf
# Samba config file created using SWAT
# from UNKNOWN (192.168.1.5)
# Date: 2011/08/21 08:40:03

[global]
	workgroup = HOME
	map to guest = Bad User
	guest account = lrhorer
	printcap name = cups
	disable spoolss = Yes
	mangle prefix = 6
	domain master = No
	ldap ssl = no

[Server-Main]
	path = /RAID/Server-Main/
	valid users = lrhorer, lgates, "Leslie A Rhorer"
	admin users = lrhorer
	read only = No
	guest ok = Yes

[TiVo-Music]
	path = /RAID/Music/
	admin users = lrhorer
	read only = No
	guest ok = Yes

[Video]
	path = /RAID/Recordings/
	admin users = lrhorer
	read only = No
	guest ok = Yes

[Leslie]
	path = /RAID/Personal_Folders/Leslie/
	valid users = lrhorer, "Leslie A Rhorer"
	admin users = lrhorer, "Leslie A Rhorer"
	read only = No
	guest ok = No
	strict locking = No
	browseable = No

[Liza]
	path = /RAID/Personal_Folders/Liza/
	valid users = lgates
	admin users = lgates
	read only = No
	guest ok = No
	strict locking = No
	browseable = No

[Tiffany]
	path = /RAID/Personal_Folders/Tiffany/
	valid users = tgates
	admin users = tgates
	browseable = No
	strict locking = No

[Photos]
	path = /RAID/Photos/
	admin users = lrhorer
	read only = No
	guest ok = Yes

[DVD_Rip]
	path = /RAID/DVD
	valid users = lrhorer, root
	read only = No
	guest ok = Yes

[Thermostat]
	path = /usr/share/thermostat
	username = root
	valid users = lrhorer, root
	admin users = lrhorer, root
	read only = No
	guest ok = Yes

[html]
	path = /var/www
	valid users = lrhorer, root
	admin users = lrhorer, root
	read only = No
	guest ok = Yes
```
Note that I lock down the personal folders not only by setting guest = no and making the shares non-browseable, but I also set strict permissions on the Linux server itself. The personal directories and all the files and subdirectories in them are set for a permission of 700, 600, 500, 400, or 100 as the case may be, with the owner of every directory and file being the user themselves. By comparison, the /RAID/Photos, /RAID/Music, and /RAID/Recordings directories are set with permissions of 777, and most of the files are at least world readable and writable. Anyone can map those folders as drives on their PC.


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> As long as the firewall on the 655 is enabled and youhave your wireless segments properly secured, that is all that is needed


Perfect!


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> The short answer to that is: SAMBA.


Great! Thanks for the SAMBA intro, I'll get on it asap! Almost there!


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> Here is a good basic tutorial on setting up SAMBA.


And more than SAMBA; I hadn't found this site on my own, it's excellent for a Debian newbie. Heck, I didn't even know I was mispronouncing Debian in my head till I landed there.


----------



## lrhorer (Aug 31, 2003)

How were you pronouncing it? Duh-BEE'-un?

Of course, once SAMBA is set up, network clients more or less just think the file server is another Windows workstation (or a domain master) with network sharing enabled. If runing Windows, just map the drive as you would a drive from any other Windows machine. From another Linux machine, it is even easier, although for file sharing between Linux workstations, you might choose to employ NFS. NFS and SAMBA can easily be run on the same server, sharing the same directories on the LAN.


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> How were you pronouncing it? Duh-BEE'-un?


Dee' - bee - en

But Duh is good!



lrhorer said:


> Of course, once SAMBA is set up, network clients more or less just think the file server is another Windows workstation (or a domain master) with network sharing enabled.


Just curious .. is the transfer speed across SAMBA pretty much equivalent to FTP? Wondering if sending 10GB files between the server & my pc where I'll run videoredo is best with either? Anyway, I'll experiment on my own once I get it all set up. Very busy at work this week, may be awhile.


----------



## unitron (Apr 28, 2006)

markmarz said:


> And more than SAMBA; I hadn't found this site on my own, it's excellent for a Debian newbie. Heck, I didn't even know I was mispronouncing Debian in my head till I landed there.


Is

Deb--eee--an

not correct?

I don't see how the spelling would suggest anything else.


----------



## markmarz (Feb 3, 2002)

unitron said:


> Is
> 
> Deb--eee--an
> 
> ...





> 1.6 How does one pronounce Debian and what does this word mean?
> 
> The project name is pronounced Deb'-ian, with a short e, and emphasis on the first syllable. This word is a contraction of the names of Debra and Ian Murdock, who founded the project. (Dictionaries seem to offer some ambiguity in the pronunciation of Ian (!), but Ian prefers ee'-an.)


I was taught that a vowel is long when followed by a consonant followed by another vowel. So a short 'e' is irregular in my book. But it's actually a contraction of Debra, so Deb.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> Just curious .. is the transfer speed across SAMBA pretty much equivalent to FTP?


It depends on the client, but yeah, mostly. The biggest time differential may be in file creation time, but with multi-Gig files, that is pretty much insignificant.



markmarz said:


> Wondering if sending 10GB files between the server & my pc where I'll run videoredo is best with either?


Sending via SAMBA will certainly take less of *YOUR* time, since you don't have to have an FTP step in between. It also means a lot less time overall, since you can edit the video file directly on the server.

What I did was create a series of directories on my Server-Main share (mapped to s: on the VideoRedo workstation) and a directory for videos (mapped to v: on the workstation). I have kmttg automatically run the videos through tivodecode to convert them .mpg and toss them to a directory on s:. Thhen kmttg automatically runs comskip on the videos to create a VRD project (.prj) file in the same directory. I edit the raw video files using the .prj files directly from the server, and then have the Batch Builder process the .prj files, implementing the cuts and recoding to h.264 in a .mp4 container, writing the temporary files to the local (to VRD) hard drive and writing the finished file to v: (or one of its directories if the program is a movie franchise installment or TV series episode). What I do then is push the processed files to one of the TiVos to check their integrity. After the files all transfer without error, I then run a routine that moves the metafiles over from the s: drive, does some extra processing on the metafiles - some interactive and some automatic, touches up the names of the video files, marks them as valid, and deletes the files on the s: drive.

Here is the script, if you or anyone else are interested:


```
#!/bin/bash
runDir=/usr/share/VideoScribe
logDir=$runDir/Logs
logFile=$logDir/verified.txt
recDir=/RAID/Recordings
metaDir=/RAID/Server-Main/Movies/TiVo_MPG
tmpDir=/tmp
monthList="Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec"

[email protected]

test=1
if [[ $1 == "--test" ]] || [[ $1 == "-t" ]]
then
	test=0
	filespec=$( echo $filespec | cut -d" " -f2- )
else
	echo "Usage note: --test or -t => test for verification only"
fi

force=1
if [[ $1 == "--force" ]] || [[ $1 == "-f" ]]
then
        force=0
	filespec=$( echo $filespec | cut -d" " -f2- )
else
        echo "Usage note: --force or -f => force processing of files"
fi

DefaultIFS=$IFS
abort=\<Abort\>
[[ -z $filespec ]] && echo No Args! && exit
#clear

find "$recDir" -iname "*$filespec*.mp[4g]" > "$tmpDir"/Verify1.tmp

if [[ $force == 1 ]] && [[ $test == 1 ]]
then
	while read fileName
	do
		grep -q "$fileName" "$logFile" || echo $fileName >> "$tmpDir"/Verify2.tmp
	done < "$tmpDir"/Verify1.tmp
	mv "$tmpDir"/Verify2.tmp "$tmpDir"/Verify1.tmp
fi

IFS=$'\n'
fileList=$( cat "$tmpDir"/Verify1.tmp )

select fileName in $fileList $abort
do
	IFS=$DefaultIFS
	[[ "$fileName" == $abort ]] && exit
	shortName=${fileName##*/}
	echo $shortName
	echo
	echo -n is this correct \(Y\)?
	tput cub 3
	read response < /dev/tty
	[[ -z $response || "$response" == "y" ]] && break
done < /dev/tty

if [[ $test == 0 ]]
then
	echo
	grep -q "$fileName" /usr/share/VideoScribe/Logs/verified.txt
	if [[ $? == 0 ]]
	then
		echo $shortName is already on the list of verified movies.
	else
		echo $shortName is not on the list of verified movies.
	fi
	echo
	exit 0
fi

dirName=${fileName%/*}
stubName=${shortName%.mp[4g]*}
PrjName=$stubName.VPrj
prjName=$stubName.Vprj
fileType=.mpg
echo $shortName | grep -q .mp4 && fileType=.mp4
echo

cd /usr/share/pyTivo/Unverified
[ -a "$shortName" ] && rm "$shortName"
[ -a "$shortName.txt" ] && rm "$shortName.txt"

cd "$metaDir"
[[ -a "$PrjName" ]] && rm "$PrjName"
[[ -a "$prjName" ]] && rm "$prjName"
[[ -a "$shortName" ]] && rm "$shortName"
[[ -a "$stubName.mpg" ]] && rm "$stubName.mpg"
[[ -a "$stubName.mpg.txt" ]] && mv "$stubName.mpg.txt" "$fileName.txt"
[[ -a "$stubName.edl" ]] && rm "$stubName.edl"
[[ -a "$stubName.txt" ]] && rm "$stubName.txt"
[[ -a "$stubName.log" ]] && rm "$stubName.log"
[[ -a "$stubName.logo.txt" ]] && rm "$stubName.logo.txt"

[[ $force == 0 ]] && grep -v "$fileName" $logFile > $logFile.tmp
[[ -a $logFile.tmp ]] && mv $logFile.tmp $logFile

grep -q "$fileName" "$logFile"
if [[ $? == 0 ]]
then
	echo $shortName is already on the list of verified movies.
	echo
	exit 0
else
	echo Renaming File...
	newName=$dirName/$( "$runDir/Rename" "$fileName" )
	echo "$newName" >> "$logFile"
	sort $logFile > "$logFile.tmp"
	mv "$logFile.tmp" "$logFile"
fi

cd "$dirName"
[[ "$newName" != "$fileName" ]] && [[ -a "$fileName.txt" ]] && mv "$fileName.txt" "$newName.txt"
[[ "$newName" != "$fileName" ]] && [[ -a "$fileName.jpg" ]] && mv "$fileName.jpg" "$newName.jpg"

if [[ $fileType == ".mp4" ]] && [[ -a "$stubName.mpg" ]]
then
	echo
	echo -n Remove "$stubName.mpg" \(N\)?
	tput cub 3
	read response < /dev/tty
	if [[ "$response" == "Y" || "$response" == "y" ]]
	then
		rm "$stubName.mpg"
		[[ -a "$stubName.mpg.txt" ]] && mv "$stubName.mpg.txt" "$stubName.mp4.txt"
		[[ -a "$stubName.mpg.jpg" ]] && mv "$stubName.mpg.jpg" "$stubName.mp4.jpg"
	fi
fi

touch "$newName.txt"
touch "$newName.jpg"
sync
"$runDir"/NameFix "$newName.txt"
"$runDir"/NoSpace "$newName.txt"

echo
echo Updating Links...

LinkName=`echo ${newName##*/RAID/Recordings/} | sed 's/\//-/'`       # Get the root file name after the Recordings dirname for the video link
LinkMeta="$LinkName".txt	# Set the name of the Metafile link
LinkThumb="$LinkName".jpg	# Set the name of the Thumbnail link

# Set up the Genre name array
Genre="Action..... Adventure.. Animated... Biography.. Classic.... Comedy..... Crime...... Documentary Drama...... Family..... Fantasy.... Film_Noir.. Holiday.... Horror..... Musical.... Mystery.... Nature..... Romance.... Science.... SciFi..... Series..... Thriller... Tragedy.... War........ Western.... Done"

echo
echo ${newName##*/}
echo
grep vProgramGenre "$newName.txt"
grep vSeriesGenre "$newName.txt"
echo

Gselect=""
x=0
select Gselect in $Genre;	# Assign Genres to the video
do
	if [ "$Gselect" == "Done" ]
	then
		break;
	else
		Gselect=`echo $Gselect | tr -d '.'`
		cd /usr/share/pyTivo/pyshares/$Gselect
		[[ -h "$LinkName" ]] || ln -s "$newName" "$LinkName"
		[[ -h "$LinkMeta" ]] || ln -s "$newname.txt" "$LinkMeta"
		[[ -h "$LinkThumb" ]] || ln -s "$newName.jpg" "$LinkThumb"
		x=$(( $x + 1 ))
		metaFields[$x]=$Gselect
	fi
done < /dev/tty
grep -v vProgramGenre "$newName.txt" | grep -v vSeriesGenre > "$newName.txt.tmp"

for (( y=1; y<=$x; y++ ))
do
	echo ${metaFields[$y]}
	echo "vProgramGenre : ${metaFields[$y]}" >> "$newName.txt.tmp"
done
mv "$newName.txt.tmp" "$newName.txt"

vName=${newName##*/}.txt
datName=${newName##*Recorded }
vName=${vName% (Recorded*}
x=1
for mon in $monthList
do
	[[ $mon == ${datName:4:3} ]] && monNum=$(( 22 - $x ))
	x=$(( $x + 1 ))
done
if [[ ${datName:8:1} == "0" ]]
then
	dayNum=$(( 41 - ${datName:9:1} ))
else
	daynum=$(( 41 - ${datName:8:2} ))
fi
yearNum=$(( 3200 - ${datName:12:4} ))
grep -q "$yearNum" "$newName.txt" || echo "recordDate : $yearNum$monNum$dayNum" >> "$newName.txt"
grep -iq "isEpisodic : true" "$newName.txt" || grep -iq "firstAlpha : " "$newName.txt"
if [[ $? != 0 ]]
then
	vTitle=$( grep title "$newName.txt" )
	firstAlpha=${vTitle:8:1}
	[[ $firstAlpha == [*\(\?] ]] && firstAlpha=${vTitle:9:1}
	[[ ${vTitle:8:4} == "The " ]] && firstAlpha=${vTitle:12:1}
	[[ ${vTitle:8:2} == "A " ]] && firstAlpha=${vTitle:10:1}
	[[ $firstAlpha == [0-9] ]] && firstAlpha="0 - 9"
	echo "firstAlpha : $firstAlpha" >> "$newName.txt"
fi

grep \| "$newName.txt" | grep -q ":"
if [[ $? == 0 ]]
then
	echo -n > "$newName.txt.tmp"
	while read metaText
	do
		echo $metaText | grep \| | grep -v "description" | grep -q ":"
		if [[ $? == 0 ]]
		then
			colonPos=$( expr index "$metaText" ":" )
			pipePos=$( expr index "$metaText" "\|" )
			nameLength1=$(( ${#metaText} - $pipePos -1 ))
			[[ $nameLength1 -lt 0 ]] && nameLength1=0
			nameLength2=$(( $pipePos - $colonPos - 1 ))
			[[ $nameLength2 -lt 0 ]] && nameLength2=0
			echo -e "${metaText: 0: $colonPos} ${metaText: $pipePos: $nameLength1}${metaText: $colonPos: $nameLength2}\r" >> "$newName.txt.tmp"
		else 
			echo $metaText >> "$newName.txt.tmp"
		fi
	done < "$newName.txt"
	mv "$newName.txt.tmp" "$newName.txt"
fi

grep -q "callsign : " "$newName.txt"
if [[ $? != 0 ]]
then
	echo -n > "$newName.txt.tmp"
	x=0
	while read line
	do
		echo $line >> "$newName.txt.tmp"
		x=$(( x + 1 ))
		if [[ $x == 5 ]]
		then
			callSign=${newName##*, }
			echo callsign : ${callSign%%)*} >> "$NewName.txt.tmp"
		fi
	done < "$newName.txt"
	mv "$newName.txt.tmp" "$newName.txt"
fi

echo Done!
```
I apologize just a bit for the lack of comments. This is pretty short and I wrote it for my own use.


----------



## markmarz (Feb 3, 2002)

wmcbrine said:


> On the rare occasions when I want to run an X app remotely, I just do an "ssh -X" and start the app from the command line.
> 
> Leaving an X environment running full-time on a headless server can be a waste of server resources.


Okay, I've got X-Ming working on my pc and have been able to login to my tivo server at a static ip with putty and then kick off a gui (Leafpad) as a test, thanks to lrhorer.

But I'm still a little confused about the idea of not running X windows 'all the time' on my tivo server. I think you're saying that if I run "ssh -X" when logged in with putty that I can somehow kick off a gui on the tivo server. I tried that and got a syntax error.


```
[email protected]:~$ ssh -X
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-W host:port] [-w local_tun[:remote_tun]]
           [[email protected]]hostname [command]
[email protected]:~$
```
Even so, if this did work, what would actually be happening? Would I be kicking off X on the tivo server, and if yes, how would that enable me to see the gui on my pc if I'm not running an X server there? Or maybe you're saying I do need to run X-Ming on my pc, but no X server needs to run on the tivo server all the time, instead I can kick it off adhoc using ssh -X (or whatever actually works)?

And if I wanted to not run X all the time on the tivo server, how exactly do I disable or prevent it from running and yet be available adhoc?

This is just for my knowledge, I haven't come down on either side of whether or not to run X all the time on a headless server because I don't know enough to form an intelligent position.


----------



## wmcbrine (Aug 2, 2003)

markmarz said:


> I think you're saying that if I run "ssh -X" when logged in with putty that I can somehow kick off a gui on the tivo server.


No. You'd be using ssh to log in. Not really relevant if you want to use PuTTY. "-X" is just an ssh option that makes it easier to start X apps from the login session. I don't suppose PuTTY has an equivalent, but really, all you have to do is export the DISPLAY variable appropriately, and make sure the client isn't blocked from connecting to your X server by a firewall.



> _Or maybe you're saying I do need to run X-Ming on my pc_


Yes.



> _but no X server needs to run on the tivo server all the time, instead I can kick it off adhoc using ssh -X (or whatever actually works)?_


No X server needs to run on the tivo server _ever_. You can run X apps (clients) one at a time, and all they need is an X server _on any machine_ to connect to. The one on your PC will do fine.



> _And if I wanted to not run X all the time on the tivo server, how exactly do I disable or prevent it from running and yet be available adhoc?_


Usually it's a matter of changing the runlevel. This varies by distro. I don't know offhand for Debian.


----------



## lrhorer (Aug 31, 2003)

One thing that may be confusing you (it confuses a lot of people) is that the X client / server relationship is a little backwards from what most people expect. Most "servers" run on a dedicated machine, often one without a console or mouse attached. PyTivo, for example, is perfectly happy running on a headless machine. Most "clients" run on potentially multiple machines with users sitting at them. The X server (in your case Xming) is different, however. The X server runs on user machines, while the X clients run on a possibly console-less machine, but the application puts up its display on the machines running an X server.

It doesn't particularly matter from what machine the client is spawned nor on which machine the client is displayed. One could, for example log in to machine B from machine A using telnet, set the $DISPLAY variable to point to machine C, and spawn an X app on machine B. The app would then pop up on machine C, assuming it is available and running an X server. Neither machine A nor machine B need to be running an X server in this scenario, nor do they need to be running a GUI. Either or both can be doing so, but it is not required for this example. One could also run a cron job on an X client machine to spawn a client at regular intervals. The app would then pop up on the targeted machines every time cron spawned it.


----------



## lrhorer (Aug 31, 2003)

wmcbrine said:


> No. You'd be using ssh to log in. Not really relevant if you want to use PuTTY. "-X" is just an ssh option that makes it easier to start X apps from the login session. I don't suppose PuTTY has an equivalent, but really, all you have to do is export the DISPLAY variable appropriately, and make sure the client isn't blocked from connecting to your X server by a firewall.


Right you are, of course. IOW, any means of running the X app on the client machine can be employed. It doesn't even have to be something remote to the client, but it can be. One can use rsh, ssh, telnet, PuTTY, a canned utility built in to the X server, whatever. Anything that can export the $DISPLAY variable and then run the app will work.



wmcbrine said:


> No X server needs to run on the tivo server _ever_.


He may not even have one installed. The Debian installer does not install an X server by default. As you pointed out, he also does not necessarily need to run a display manager, unless he wants to run the GUI on the TiVo server, either from the console or from XDMCP (or other remote desktop software such as VNC).



wmcbrine said:


> Usually it's a matter of changing the runlevel. This varies by distro. I don't know offhand for Debian.


Well, that is handled by the init scripts and the display manager. Both GDM and KDM are enabled for all runlevels other than 0, 1, and 6. I'm not certain about the display manager Mark is using, but it is likely the same. Dropping to runlevel 1 (single user) would disable the GUI, but it also disables networking. Runlevels 0 and 6 shut down the machine.

One way to disable the GUI completely is to simply disable the display manager. This can be accomplished by putting an `exit 0` statement at the top of the init script, or by changing the runlevel parameters in the init script and updating using the update-rc.d command. I don't recommend any of these methods, however, especially if he might ever want to use the GUI.

Now you are perfectly correct that running a GUI on a server is not considered best practice. You are also perfectly correct that having a GUI display up full time is a waste of at least some resources on the server. It is not such a terrible waste of resources, however, to leave the display manager daemon (which is tiny and uses almost no resources) running. One can also disable the GUI for the console. OTOH, even the greeter (not the full GUI) running on the console only really uses resources on the video display, and that is pretty much irrelevant to the operation of the server as a whole.

Really, I would say as long as he does not log in on the console and does not leave an XDMCP session up all the time, he is mostly just as well not to worry about it. If he really, really wants to minimize resources, though, as I say he can disable his DM for the console but leave it active for remote logins.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> Okay, I've got X-Ming working on my pc and have been able to login to my tivo server at a static ip with putty and then kick off a gui (Leafpad) as a test, thanks to lrhorer.


That is not a GUI. Leafpad is an X client displayed in an X-window on your X server. The GUI in this case is Windows, and the only GUI running on the server is (possibly) whatever is on the server's console, probably just the greeter.

Between this and William's and my other responses, do you get the picture? This is a screenshot of KDE, the GUI I am using on my Linux systems:


----------



## markmarz (Feb 3, 2002)

wmcbrine said:


> .. but really, all you have to do is export the DISPLAY variable appropriately, and make sure the client isn't blocked from connecting to your X server by a firewall.


Okay, I'll dig further and figure out what that means.

In the meantime, thanks!



> No X server needs to run on the tivo server _ever_. You can run X apps (clients) one at a time, and all they need is an X server _on any machine_ to connect to. The one on your PC will do fine.


Gotcha, thanks!


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> That is not a GUI. Leafpad is an X client displayed in an X-window on your X server. The GUI in this case is Windows, and the only GUI running on the server is (possibly) whatever is on the server's console, probably just the greeter.


I get the picture (literally) . I was speaking loosely when I said Leafpad was a gui; of course it isn't itself a gui like windows. Then again, it's not a command line text editor; it has a graphical user interface.


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> One thing that may be confusing you (it confuses a lot of people) is that the X client / server relationship is a little backwards from what most people expect.


You hit the nail on the head, thanks! And thanks for the $DISPLAY variable explanation.


----------



## lrhorer (Aug 31, 2003)

unitron said:


> Is
> 
> Deb--eee--an
> 
> not correct?


Yes, with the accent on the second syllable.



unitron said:


> I don't see how the spelling would suggest anything else.


Well, first of all, the accent could be on the first syllable, or even the third. Secondly, the "Deb" could be pronounced deh, duh, or dih. The ian could be pronounced eean or eyeun. Finally, the b could be part of the first or second syllable: deh-bee-un or deb-ee-un.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> I get the picture (literally) . I was speaking loosely when I said Leafpad was a gui; of course it isn't itself a gui like windows. Then again, it's not a command line text editor; it has a graphical user interface.


Well, to be pedantic, it *requires* a GUI. It's a graphical app. Windows desktop, KDE, Gnome, CDE, etc are all GUIs, sometimes called "desktop environments". (Note the "DE" in KDE, CDE, LXDE, etc.)


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> If he really, really wants to minimize resources, though, as I say he can disable his DM for the console but leave it active for remote logins.


Sounds good. How do I do that? If it's somewhere in your reply, sorry I can't find it after numerous re-reads.

KDM is my (default) display manager, though GDM is installed, and LXDE is my desktop environment.


----------



## lrhorer (Aug 31, 2003)

I think you're using a DM with which I am not familiar, so I'm not sure. The man pages should tell you, or the configuration file may make it readily evident. Again, look under /etc/default-display-manager. It will list something like /usr/bin/lxdm, /usr/bin/kdm, etc. Assuming it is /usr/bin/lxdm, then there is probably a directory something like /etc/lxde/lxdm. That will contain the config files. One of them should be able to specify that the console not run the GUI. Barring that, you could probably just put a trap in /etc/X11/Xsession or /etc/X11/xinit/xinitrc to check for the active display.


----------



## markmarz (Feb 3, 2002)

Thanks, I'll dig around.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> KDM is my (default) display manager, though GDM is installed, and LXDE is my desktop environment.


Oh, heck, how did I miss that? I'm very familiar with KDM. I don't recall at the moment off the top of my head how to disable KDM on the console, but are you really sure you want to bother? KDM just really does not eat up much in the way of resources. If you insist, I can dig into it, though.

I don't recall if you mentioned. How much memory is on that box?


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> Oh, heck, how did I miss that? I'm very familiar with KDM. I don't recall at the moment off the top of my head how to disable KDM on the console, but are you really sure you want to bother? KDM just really does not eat up much in the way of resources. If you insist, I can dig into it, though.
> 
> I don't recall if you mentioned. How much memory is on that box?


4GB ram, but I could easily up that if there's a reason; I'm trying to conserve energy as much as practical and so far haven't seen a need for more ram. Right now without anything really going on the server consumes 50 watts with 3 out of 5 drives in standby. When it's humming around 80 watts tops.

I don't insist of course! I've been digging around this whole issue and unfortunately getting more and more confused. Considering taking LXDE out of the equation, so I can more easily follow instructions for KDM/KDE. Mainly I just want to be able to turn off X unless I'm remotely logged in.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> 4GB ram, but I could easily up that if there's a reason


No, that should be more than sufficient, with or without KDE or LXDE running on the console.



markmarz said:


> I'm trying to conserve energy as much as practical and so far haven't seen a need for more ram. Right now without anything really going on the server consumes 50 watts with 3 out of 5 drives in standby. When it's humming around 80 watts tops.


That's not bad, at all.



markmarz said:


> I don't insist of course! I've been digging around this whole issue and unfortunately getting more and more confused. Considering taking LXDE out of the equation, so I can more easily follow instructions for KDM/KDE.


Well, that's not necessary, unless you like KDE more than LXDE. You may find yourself using neither one. As William pointed out, it is quite workable to administer the server via ssh / PuTTY and the odd X-window here and there. If you like and prefer using KDE or LXDE, then I suggest you not let performance considerations hinder you. There is a performance hit, but it is a small one, especially in a case like yours. I seriously doubt you would ever know the difference. It's also not going to impact the power consumption.



markmarz said:


> Mainly I just want to be able to turn off X unless I'm remotely logged in.


Well, it's not a matter of "turning X off". Indeed, unless you want to exclusively administer the server using ssh or PuTTY (or telnet) directly, then you probably won't be "turning X off". OTOH, it is possible if one really wants to shut down the X listener, and this would be one option - albeit a bit of a clumsy one - for disabling KDM for the console. Note there is a significant difference between shutting down X entirely and merely not having any X sessions running. It is the individual X sessions that can potentially eat up some resources on the server, not merely having the X framework and X listener in place. It is having permanently running X sessions to which William was referring.


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> If you like and prefer using KDE or LXDE, then I suggest you not let performance considerations hinder you. There is a performance hit, but it is a small one, especially in a case like yours. I seriously doubt you would ever know the difference. It's also not going to impact the power consumption.


That's all encouraging! LXDE and KDE are equally new to me; haven't used a windowing environment on the AIX or Solaris servers at work. But then I haven't administered Linux before. Thought maybe a GUI would help me ease into that, and it has been helpful at times. Other times I just get exasperated with the limitations and drop to the command line.

I'd like to keep the GUI around as an _option_. From what I've read LXDE is particularly suited to low-power boxes like my own.



lrhorer said:


> Note there is a significant difference between shutting down X entirely and merely not having any X sessions running. It is the individual X sessions that can potentially eat up some resources on the server, not merely having the X framework and X listener in place. It is having permanently running X sessions to which William was referring.


I think grasping this is what's really hanging me up. Right now my server when booted brings up LXDE (and I guess KDM behind it, and X behind them both .. unless that premise is wrong, too). Anyway, isn't the GUI itself an X session on the server? Or are we only talking about X sessions in terms of remote X sessions when I'm using X-Ming on my pc?

I think an ideal working scenario would be that Debian boots up in console mode. From there I could bring up the GUI if I wished, whether locally on the server or when remotely controlling the server. But as an option in either case. But with all the information you've given me re resources, I'm fine with having the server come up as it does now with LXDE running. If that doesn't mean I have an X session up all the time.

Clear as mud, right?


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> Thought maybe a GUI would help me ease into that, and it has been helpful at times. Other times I just get exasperated with the limitations and drop to the command line.


Well, that's good. It proves the CL is not daunting to you, so it always exists as an easy option, whether primary or secondary.



markmarz said:


> I'd like to keep the GUI around as an _option_. From what I've read LXDE is particularly suited to low-power boxes like my own.


Yours isn't all that low power, in terms of CPU and memory horsepower. For low power think: 512M of RAM and 800MHz Pentium 4. Yours is in the middle. That said, I am indeed given to understand LXDE is light on processor and memory demands, while KDE is on the heavy side. 'Still nothing like Windows, though.



markmarz said:


> I think grasping this is what's really hanging me up. Right now my server when booted brings up LXDE (and I guess KDM behind it, and X behind them both .. unless that premise is wrong, too).


It depends on what you mean by "behind". X is the graphical system. It is the basis for all windowed operations in Linux. One cannot run any sort of graphical application, either remotely or locally, without it. The Display Manager ( XDM, KDM, GDM, LXDM, etc ) is merely a gateway to the local Desktop Environment. If a local DE (KDE, LXDE, Gnome, CDE, etc. ) is not being used, then the DM is not necessary. This is the case for text logins and for graphical apps using a remote DE. In the example of using ssh or PuTTY to log in to the workstation and bring up a window on a Windows machine, the DE is Windows, and neither a local DM nor a local DE is required for that instance. In the case of a local DE either from the console or via XDMCP, the local DM provides the login facilities and also typically allows one to select between several DEs. It's only a gateway facility, though, and essentially evaporates for the current terminal after it hands over control to the DE.



markmarz said:


> Anyway, isn't the GUI itself an X session on the server?


Yes, it is.



markmarz said:


> Or are we only talking about X sessions in terms of remote X sessions when I'm using X-Ming on my pc?


Not exclusively, no, but that is one example.



markmarz said:


> I think an ideal working scenario would be that Debian boots up in console mode.


In this context, Debian doesn't exactly boot up in any mode. It sounds to me like you are thinking of Linux as if it were a single user system like Windows. Each terminal has its own display attributes, and any one can be graphical or text mode. It just happens that by default Linux outputs its boot display to the console. That can be easily changed, however. Many Linux boxes output their boot display to a serial port, for example.



markmarz said:


> But with all the information you've given me re resources, I'm fine with having the server come up as it does now with LXDE running. If that doesn't mean I have an X session up all the time.


It isn't running, though, unless you log in to the console (or set up an automatic, password-less console login) or through one or more XDMCP sessions. That's my point. The system you have in place right now is quite considerate of your PC's resources, and will operate swimmingly as a general purpose server, just like it sits.

Try the following. Log out of the console, leaving the greeter (this is KDM) running. If you have any XDMCP sessions running, log out of them, as well. (You don't need to shut them down, necessarily, just log out.) Use telnet, ssh, or PuTTY to open a text terminal on the server and ps | grep for kde (or lxde, or whatever). You will see something like the following:


```
Backup:~# ps -ef | grep kde
root     18775 18774  0 23:18 ?        00:00:01 /usr/lib/kde4/libexec/kdm_greet
root     25883 18792  0 23:23 pts/0    00:00:00 grep kde
```
As you can see, KDE is not running, only a single thread per active terminal for the KDM greeter. The CPU resources used by the greeter are totally trifling, and the memory eaten up by it is quite small, especially compared to 4G. Now if you log in to the GUI on one of the terminals and run the same command, you will get something like the following:


```
Backup:~# ps -ef | grep kde
root     20883 18774  0 23:42 ?        00:00:00 /bin/sh /usr/bin/startkde
root     21054 20883  0 23:42 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
root     21057     1  0 23:42 ?        00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
root     21099     1  0 23:42 ?        00:00:00 /usr/lib/kde4/libexec/start_kdeinit +kcminit_startup
root     21100     1  0 23:42 ?        00:00:00 kdeinit4: kdeinit4 Running...                  
root     21101 21100  0 23:42 ?        00:00:00 kdeinit4: klauncher [kdeinit] --fd=9           
root     21103     1  0 23:42 ?        00:00:00 kdeinit4: kded4 [kdeinit]                      
root     21109 21100  0 23:42 ?        00:00:00 kdeinit4: ksmserver [kdeinit]                  
root     21169     1  0 23:42 ?        00:00:00 /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1 -session 10b7d1636b000127518319700000031170007_1339647497_902533
root     21171     1  0 23:42 ?        00:00:00 kdeinit4: konsole [kdeinit] -session 10b7d1636b000125714857500000109760011_1339647497_902916
root     21231     1  0 23:42 ?        00:00:00 kdeinit Running...                      
root     21234     1  0 23:42 ?        00:00:00 dcopserver [kdeinit] --nosid --suicide  
root     21236 21231  0 23:42 ?        00:00:00 klauncher [kdeinit] --new-startup       
root     21240     1  0 23:42 ?        00:00:00 kded [kdeinit] --new-startup            
root     22674 21100  0 23:43 ?        00:00:00 kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-root/klauncherT21101.slave-socket local:/tmp/ksocket-root/krunners21132.slave-socket
root     24090 18792  0 23:44 pts/0    00:00:00 grep kde
```
Those are some of the resources of which William was speaking, and although they are not massive, they do represent a little something in the way of a drain on the server. This can be completely avoided, however, by simply not logging in.


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> It depends on what you mean by "behind". X is the graphical system. It is the basis for all windowed operations in Linux. One cannot run any sort of graphical application, either remotely or locally, without it. The Display Manager ( XDM, KDM, GDM, LXDM, etc ) is merely a gateway to the local Desktop Environment. If a local DE (KDE, LXDE, Gnome, CDE, etc. ) is not being used, then the DM is not necessary. This is the case for text logins and for graphical apps using a remote DE. In the example of using ssh or PuTTY to log in to the workstation and bring up a window on a Windows machine, the DE is Windows, and neither a local DM nor a local DE is required for that instance. In the case of a local DE either from the console or via XDMCP, the local DM provides the login facilities and also typically allows one to select between several DEs. It's only a gateway facility, though, and essentially evaporates for the current terminal after it hands over control to the DE.


Yes! The fog is clearing!



lrhorer said:


> In this context, Debian doesn't exactly boot up in any mode. It sounds to me like you are thinking of Linux as if it were a single user system like Windows. Each terminal has its own display attributes, and any one can be graphical or text mode. It just happens that by default Linux outputs its boot display to the console. That can be easily changed, however. Many Linux boxes output their boot display to a serial port, for example.


I knew nothing about this; this explanation helps a lot.



lrhorer said:


> It isn't running, though, unless you log in to the console (or set up an automatic, password-less console login) or through one or more XDMCP sessions. That's my point. The system you have in place right now is quite considerate of your PC's resources, and will operate swimmingly as a general purpose server, just like it sits.


Great! But I'm unclear on whether or not I'm running an XDMCP session ever. I think this is the protocol that would be used by (say) X-Ming, right? If that's the case then I'd only have such a session if I kicked off X-Ming, I reckon. Tried grepping xdmcp variations from ps, no show.



lrhorer said:


> Try the following. Log out of the console, leaving the greeter (this is KDM) running. If you have any XDMCP sessions running, log out of them, as well. (You don't need to shut them down, necessarily, just log out.)


See above re XDMCP. Here's something I didn't notice before: the login (greeter?) screen has a menu option at the bottom of the screen which offers Console Login as an option. Great! That gives me half of what I need.

How, after logging in on the console on the server, can I switch to a GUI session on the server? I tried logging out and that will pop up the initial greeter screen where I have this option. The Samba daemon (for example) still is happily running. But I imagine if I were to kick off a program from the command line, say pyTivo, then logging out would kill it. Right? Soon I'm going to attempt your init.d scripts for pyTivo and pyhme so they run as daemons. That'll probably open some questions on that thread!



lrhorer said:


> Use telnet, ssh, or PuTTY to open a text terminal on the server and ps | grep for kde (or lxde, or whatever). You will see something like the following:


Indeed I did.



lrhorer said:


> As you can see, KDE is not running, only a single thread per active terminal for the KDM greeter. The CPU resources used by the greeter are totally trifling, and the memory eaten up by it is quite small, especially compared to 4G. Now if you log in to the GUI on one of the terminals and run the same command, you will get something like the following:


I didn't. Tried grepping lxde, xde, kdm .. still same display as before. What I did was open a new Putty session using SSH, as usual. Then I kicked off X-Ming and then Leafpad, which displayed correctly on my pc. Then tried ps -ef | grep lxde and so on with no change. This I'm sure is not an essential point; something is running somewhere to support my X session!
*
Thanks a million!*


----------



## markmarz (Feb 3, 2002)

BTW .. and this is amazing to me .. now at idle the server is pulling 25 watts , and when doing all I can imagine I'd want it to do at once .. ie, pushing an avi, syncing raid (using SnapRaid, my bad), and just for the heck of it adding a file through Samba on my windows client & pulling another at the same time .. it uses 35 - 40 watts with a momentary peak at 45. In other words, the energy bill is halved!!

I might replace the 160gb boot drive with a solid state drive and should be able to chop off another 6 watts. Man, 19 watts for a server with 12TB+ ?! Woo hoo!! :up::up::up:



markmarz said:


> *
> Thanks a million!*


Worth repeating!


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> Great! But I'm unclear on whether or not I'm running an XDMCP session ever.


You certainly don't have to, but in some cases it can be convenient. For example, having multiple Xterms active using the tabbed terminal feature of KDE can be very handy. Cut-and-paste is much easier and more powerful under KDE than under Windows, etc.



markmarz said:


> I think this is the protocol that would be used by (say) X-Ming, right?


Well, it is one of them. X-Ming provides all the protocol support for X-Server operation, including XDMCP, X-Windows, etc. It allows you to import an X display into a window, export a DE into a window, replace the Windows DE with a foreign one, and so forth. The latter two are done via XDMCP. XDMCP stands for X Display Manager Control Protocol. Basically, it is a means of bringing a DM remotely. If the user is not going to log in to a DE, then he doesn't need a DM. If he doesn't need a DM, then he doesn't need XDMCP. Using ssh or PuTTY to log in to an X machine and export an X client to some other machine (not necessarily the machine from which the ssh / PuTTY session is spawned), then no DE, DM, or XDMCP is required or will be running on the local server for any sessions spawned from that Xterm. An X-server (in this case X-Ming) is required, however.



markmarz said:


> If that's the case then I'd only have such a session if I kicked off X-Ming, I reckon.


Well, X-Ming is required for any X-server operations, not just XDMCP. It supplies the display(s) on the remote machine, whether for XDMCP, X-window client sessions, whatever.



markmarz said:


> Tried grepping xdmcp variations from ps, no show.


Oh, well, yeah, you won't. XDMCP is not an application, it is a protocol supported by most X-servers, plus it runs on the X-server, not the X-client machine. The DM and then the DE run from the client machine, at the behest of the XDMCP protocol running on the X-server.



markmarz said:


> See above re XDMCP. Here's something I didn't notice before: the login (greeter?)


Yep.



markmarz said:


> screen has a menu option at the bottom of the screen which offers Console Login as an option.


Yep, as well as options to spawn one of a number of different DEs (if installed) and the ability to spawn a DE from a different X-client machine.



markmarz said:


> Great! That gives me half of what I need.


I think it gives you all of what you need, really.



markmarz said:


> How, after logging in on the console on the server, can I switch to a GUI session on the server?


Well, it might be possible to run KDM, but there is no reason to do that. You already had KDM running, and simply exiting will take you back to KDM.



markmarz said:


> I tried logging out and that will pop up the initial greeter screen where I have this option. The Samba daemon (for example) still is happily running. But I imagine if I were to kick off a program from the command line, say pyTivo, then logging out would kill it. Right?


That is an entirely different matter, and it won't make any difference if pyTiVo or anything else that has not been daemonized is run from a parent session. Killing that session will kill the child process, whether the parent is a text app or a GUI.

To daemonize an app that is not a daemon binary (like SAMBA, FTPD, telnetd, etc.) requires two steps. The first is to spawn the app in the background, rather than the forground. This is very easy to accomplish. Simply add an ampersand (&) to the very end of the command line. This sequesters the app into a separate, non-interactive thread tree and returns console control to the parent. Note this won't work very well if the spawned app requires any input from the user.

The second step is to use a detachment utility to spawn the app as a detached process. At a high level, what this does is prevent the spawned app from responding to signals from the parent app. At a low level what happens is the app is detached from the PID of the parent app and attached to the init thread (PID 1). The utility most often used to accomplish this is called `nohup`, which is short for NO-HangUP. It provides for a number of options, including automatic re-direction of stdout and stderr.

In the simplest incantation, daemonizing pyTivo can be done by merely typing


```
nohup python pyTivo.py &
```
Whether invoked from a GUI, an ssh text session, or an automated script, that session of pyTivo wil not terminate when the parent terminates.



markmarz said:


> Soon I'm going to attempt your init.d scripts for pyTivo and pyhme so they run as daemons. That'll probably open some questions on that thread!


OK. That is precisely what I would recommend. The System V init utility provides some very powerful and elegant ways to handle the starting and stopping of system daemons. If you are at all familiar with modular scripting methods, then the init files will be a breeze. If not, then it can take a bit to understand the structure of these utilities, but the use of them is dead simple. One simply types the qualified name of the init file and then the single option start, stop, restart, or reload. Any time the init utility implements a runlevel change, the scripts are all invoked in appropriate order with the command tail appropriate to the runlevel being entered.



markmarz said:


> I didn't. Tried grepping lxde, xde, kdm .. still same display as before. What I did was open a new Putty session using SSH, as usual. Then I kicked off X-Ming and then Leafpad, which displayed correctly on my pc. Then tried ps -ef | grep lxde and so on with no change. This I'm sure is not an essential point; something is running somewhere to support my X session!


No, no. It is an essential point to your stated intent. LXDE and KDE were *NOT* running. That is why nothing but the KDM reference showed up. I think this has in fact accomplished everything you really want to happen. If you spawn an XDMCP session from the Windows PC, or if you log in to the console on your Linux machine, you will see quite a few threads related to KDE (or LXDE, or both) running on the machine. Just spawning an X-window or ten won't.



markmarz said:


> *Thanks a million!*


Really? Small bills, please.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> BTW .. and this is amazing to me .. now at idle the server is pulling 25 watts , and when doing all I can imagine I'd want it to do at once .. ie, pushing an avi, syncing raid (using SnapRaid, my bad), and just for the heck of it adding a file through Samba on my windows client & pulling another at the same time .. it uses 35 - 40 watts with a momentary peak at 45. In other words, the energy bill is halved!!


Go green.

There's some cool stuff going on there, isn't there?



markmarz said:


> I might replace the 160gb boot drive with a solid state drive and should be able to chop off another 6 watts. Man, 19 watts for a server with 12TB+ ?! Woo hoo!! :up::up::up:


Yeah that would work just fine. A USB thumb drive would save a bit more even and would cost less, too. The server performance would not suffer, and the UI performance would not be hideous.


----------



## markmarz (Feb 3, 2002)

As usual you've given me a lot to absorb, but I'll study what you've given me and of course do some background reading as well. Can't tell you enough how grateful I am to you!


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> A USB thumb drive would save a bit more even and would cost less, too.


You know I actually have installed Debian on a thumb drive and ran it from there fine. Only concern is I've been picking up .. right or wrong .. that thumb drives tend to be less reliable than ssd's, and even the latter has problems. It so happens that I had been storing a few movies on a 64gb thumb drive and when I tried to pull them off, I had read errors on a couple. There's also wear leveling considerations, etc etc. So I haven't yet come down on the ssd/thumb drive decision.

I'll be reviewing your comments in another thread about backup strategies for the boot drive.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> that thumb drives tend to be less reliable than ssd's, and even the latter has problems. It so happens that I had been storing a few movies on a 64gb thumb drive and when I tried to pull them off, I had read errors on a couple. There's also wear leveling considerations, etc etc. So I haven't yet come down on the ssd/thumb drive decision.


That is quite correct, which is why if you do go with a bootable thumb drive, you want to make some changes to the Linux configuration. First of all, you want to have /var, /tmp and the swap plus any other directories that get written on a continual basis on the hard drive, not the thumb drive. Then there are certain other changes that need to be implemented to place certain Linux facilities either on the hard drive or in memory. Basically, you want to make sure the system is not writing to the media continuously.


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> First of all, you want to have /var, /tmp and the swap plus any other directories that get written on a continual basis on the hard drive, not the thumb drive.


Yes, I'd like to move as much as possible to part of that 4GB of ram I'm not currently using. If I'm going with flash I'd rather avoid writing to a spinning hard drive as well. The more I do that, the less it makes sense to use flash.


----------



## markmarz (Feb 3, 2002)

Also even if the boot drive is spinning 24 (though usually idle & spinning) hours a day .. which may be the case since for some reason it ignores my spindown command .. the rough average cost per day is 2 to 3 cents.

Maybe I'm getting a bit crazy on the green side. Of course there's more to the cost than dollars and cents. But that's a whole other discussion. Mainly just trying to get some perspective.


----------



## lrhorer (Aug 31, 2003)

markmarz said:


> Yes, I'd like to move as much as possible to part of that 4GB of ram I'm not currently using. If I'm going with flash I'd rather avoid writing to a spinning hard drive as well. The more I do that, the less it makes sense to use flash.


Well, using loop devices, it is possible to move all writes off any sort of drive. That's how a lot of embedded Linux systems do it. The down side is one looses any log information whenever the system crashes or gets rebooted. That in turn can make it devilishly difficult to troubleshoot kernel panics or other problems. OTOH, on a very stable system like a server, it is not at all an unreasonable thing to do, and in such a case the frailty of a USB drive is minimized. One can even boot from CD-ROM. It doesn't get cheaper than that, or easier to make backups.


----------



## markmarz (Feb 3, 2002)

lrhorer said:


> Well, using loop devices, it is possible to move all writes off any sort of drive. ... One can even boot from CD-ROM. It doesn't get cheaper than that, or easier to make backups.


Both very interesting subjects to explore, thanks!

Just one question re CD-ROM boots .. why would a backup of the boot drive be necessary? I'm presuming all write activity to the boot drive is suppressed, so there would be no adjunct files on some writable media to backup, right? If that's the case then you might backup the CD-ROM once for safety and never again. Unless you change things. Right?


----------



## lrhorer (Aug 31, 2003)

That's right. Of course, at about $0.10 a copy, I think you could afford at least two.


----------

