Getting started with Linux in VFX

Useful entry level reading for someone that's never used linux before....

http://www.creativecrash.com/tutorials/the-unix-shell-for-vfx-artists#tabs

VFX pipeline diagram - real world example

Taken from a pipeline design meeting. 

Credit to Simon Maddison I think

How to setup a reverse ssh tunnel

Ever wanted to know how you can ssh into your work desktop/server? Well do not worry any longer.....

1. All you need to do is create a reverse tunnel from your Work Desktop/Server to your home server.
   
   
   • ssh -nNT -R 5000:local_server:22 username@remote_server
   • Now from the remote_server run this
     ssh -p5000 localhost.... now we are in our work desktop/server.
2. Lets brake this down a bit..
   
   
   • The -n option Redirects stdin from /dev/null. This must be used when ssh is run in the background.
   • The -N option does not execute a remote command. This is useful for just forwarding ports.
   • The -T option disables pseudo-tty allocation.
   • The -R option does tha job of setting up the reverse tunnel.
   • Port 5000 is the port that will be listening on the remote_server (this can be any random port over 1024, if you want to run this as a non-root user).
   • local_server is the desktop/server that you are creating the connection from.
   • Port 22 is the port that you are making the ssh connection to.
   • user_name@remote_server is where you are making the ssh connection to for the reverse tunnel.
We need to make sure we keep this connection open.
• In /etc/ssh/sshd_config we need to make sure this is set TCPKeepAlive yes.\

This page was stolen from somewhere else, I can't remember where. Sorry to the original author..

Running a script as root

The problem:

In theory, running a script as it's owner (in our case root) is simple, all you have to do is set the 'setuid' bit (sometimes mistakenly called the 'sticky' bit) by using 'chmod 4755' (or chmod 4***, depending on what mode you need). The problem is, that the 'setuid' bit functionality has been disabed on most Linux based distros for security reasons. This affects only scripts, not compiled code which should still work.

Solutions:

binary wrapper

The 'setuid' bit still works for compiled files. So what you can do is write a little c wrapper that will execute the script you want to run as root.

#include 
#include 
#include 
#include 

using namespace std;

int main(int argc, char* argv[]) {
    setuid( 0 );
    string cmd = "/opt/local/cmd.sh";
    for (int i = 1; i < argc; i++) {
        string arg (argv[i]);
        cmd += " ";
        cmd += arg;
    }
    int exitcode;
    exitcode = system(cmd.c_str());
    return WEXITSTATUS(exitcode);
}

Safe this as 'runscript.c', then compile and do the following:

gcc runscript.c -o runscript
sudo chown root:root runscript
sudo chmod 4750 runscript

You should now be able to run this command as root.

sudo wrapper

Add the following line to your sudoers file, with 'group' being the group you want to give access to your script.

group    ALL = NOPASSWD: /path/to/script

Then write a wrapper, executing you script with sudo.

sudo /path/to/script

Also your script will have to perform a 'setuid(0)' to make sure that all child processes are executed as root.

A couple of things to note:

• it's not enough to do 'chmod 4***' on the binary, you also have to use 'setuid' inside the code.
• an additional problem on Mac OS X is, that by default the 'setuid' bit is disabled on NFS mounts.

x forward session with xdmcp

XDMCP allows logging into a remote host, but displaying the desktop on your own host.

1) edit /etc.gdm/custom.conf

[xdmcp]
Enable=true

[security]
DisallowTCP=false
AllowRemoteRoot=true

2) restart X (telinit 3; telinit 5)

3) login as root and run:

gdmsetup

4) On the remote tab, change 'style' to 'same as local'

5) On the security tab, tick 'allow local system administrator login' and 'allow local system administrator login'

6) restart X

To test, log off your host, and press F10 in the login GDM login window. You can enter the name of the remote host to login too here.

Forward user x sessions

When logging into a remote host as root, you lose the ability to forward x sessions after an su to another user.

To allow x-forwarding after you perform an su, you need to request the cookie for the current server:

ssh root@somehost

xauth list

returns:

 somehost.somedomain/unix:10  MIT-MAGIC-COOKIE-1  d9fc3512df83a70ea8054dff21f58e28

Now, su to the user:
 

su - someuser

xauth add somehost.somedomain/unix:10  MIT-MAGIC-COOKIE-1  d9fc3512df83a70ea8054dff21f58e28

now x apps will forward correctly - test with xterm.