SGI: Security

You can even run another version of IRIX in your chroot. There are some limitations (IRIX 6.2 pthreads userland doesn't work on IRIX 6.5 kernel for example), but it's quite useful for building software etc.:


Pretty sure IRIX 5.3 never ran on IP35

I know I haven't posted often nor in a long time but I am still active with my IRIX use and trolling this forum but I still love all you guys who really make this site what it is and I should be ashamed for not making an effort for contributing more but I digress.

I want to keep the discussion of security alive more than ever. I am working on a project for fun that requires a few questionable tricks to make work but it does make the need for security more important than ever. I am working on providing the first ever and I assume to be the only ever, Bare-Metal provisioning of IRIX/MIPS. I know that there is no market for it nor any real use but I want to provide for the fun and amusement. If it was not for this site, I wouldn't have a chance in hell of pulling it off. I am a network engineer by trade and happen to love Ansible. It's dependency primarily on SSH makes this possible and for the tasks that I cant yet pull off solely on MIPS, I am using x86. I will note that any x86 machine used was sold and manufactured by SGI/Supermicro. This consists of an SGI 1100 and various Altix XE servers.

Anywho, any methods for securing and packages worth adding/removing to build the best IRIX 6.5.30 install base would be greatly appreciated. The first phase should be for a base install and the second should be for select-able options as a stack. The real trick is dual network interfaces and booting via fiber allowing for multiple pre-built images to save time and allow for quick re-imaging on the back-end. Using Ansible to talk to the core network switch and SAN it key and being sure the Boot/PROM are never effected.

Also, I want to host an online Quake server for IRIX users. The use of the server would be free but require a sign up process for requesting access to scheduled competition/co-op and allowing connection via an individual's IP to be orchestrated by building the custom ACL to allow the connection for each player. This would be to attempt to keep attacks and compromises to a minimum.

Cheers,
Rev.Bubba

Good to see you again Rev.Bubba!
What kind of packaging requirements are there for creating such a system? Will the vanilla tardist system for IRIX be sufficient, or does Ansible have its own way of packaging/distributing software?

As for booting systems via secondary interfaces, that might be an obstacle. Maybe someone else can chime in and provide details about whether this is possible.

Sorry for the late response. I may create a new post as to not highjack this thread as this discussion on security recommendations is important.

As for your first question, I am really attempting to cheat by basing it on the IRIX Bare Metal Recovery found at the link below.

http://www.backupcentral.com/wiki/index ... l_Recovery

There is much to alter with that method listed but starting with a vanilla 6.5.30 install, I want much of the orchestration for packages and user settings and such. There are options that enable and disable switch ports on the private network after provisioning leaving access via the automatically assigned public IP etc. That is the general idea.

I have been wondering about the benefit of control via console as well and if using an L1 or L2 controller would be worth playing with. I just need to understand it's use for anyone who has or still does use them. I admit that I may be misunderstanding the point of the device as well.

Rev.

Okay, reading the backupcentral article in full made me think about your endeavour. So here is me thinking out loud:

First things first, For all Bare Metal install or recovery of IRIX, you either need graphical/keyboard access or serial console. ARCS access via the network is not possible, unless you get some kind of automated basic IRIX install + ssh going and then log on. This might be done via a diskless boot, but then you have to edit nvram variables and run a bootp/tftpd server which guest access, which is inherently insecure unless you can restrict the traffic to a specific subnet or a single machine you can trust.

Also, the Bare Metal section only lists the procedure of doing system install or recovery, which is basically not really different from installing a system via CDROM/tape or remote directory. The only real difference described there is how exactly a recovery works when you have performed a system backup. This is actually neat info, since i must admit in all my years as IRIX admin have never done that myself.

The division of network interfaces is a good idea, so you can do the base install and recovery on default interfaces like ec0/ef0, and when the system is all set switch to a FC or Phobos ethernet interface doing the real stuff. This way you separate installation infrastructure from the live stuff.

I was going to type some more, but i have visitors. TTYL and i will split the post later...

I don't quite understand what "bare metal provisioning" is, but SGI had a product called RoboInst that automated a large part of the install process.

You are indeed correct in the RoboInst server and client software allowing the automated deployment of many IRIX machines over a network, but if i read the techpubs manual on it, it is not true Bare Metal because the RoboInst server needs to contact a client already running IRIX to accept a new sash in the volume header of the root disk and prepare miniroot environment to start installation when the client reboots.

If the client isn't running IRIX or the hard disk has been erased, you have to go Bare Metal by going to the (graphical) console and start the fx partitioning and IRIX installation accross the network 'by hand'.

The neat thing about RoboInst is the support of upgrading IRIX 5.3 clients to 6.5 (if they can handle the new OS and if the disk is big enough). It's just something i had never really considered because the number of SGI workstations in our department didn't exceed twenty, and all Indy's running 5.3 had crappy 1GB Seagate ST51080N Medalist which were too small for IRIX 6.5 and died if you pointed at them.

RoboInst, that sounds awesome but I understand Dexter1's point. Considering the issue with creating a true bare metal service, I had been looking for a way to cheat. It is also why I was wondering about FC HBA options and booting from SAN. Keeping fresh images for a quick inst by way of pointing to or re-assigning volumes was one thought. Is there not any way to handle all the fx partitioning and even a full install via the console port? If so that would be the way to go.

Rev.Bubba wrote: Is there not any way to handle all the fx partitioning and even a full install via the console port? If so that would be the way to go.

When we install an Origin or Challenge system it's all we have

But of course the trick is to do this from a script. The fx utility has a -s options which accept a text file as a script. This is basically the way RoboInst automates fx by putting the fx script as a subset of the inst miniroot script commands, if i interpret http://techpubs.sgi.com/library/tpl/cgi ... ame=1%20fx correctly.

The rest of inst can be automated in a similar way. The two remaining challenges is to 1) cold reset the machine and 2) direct the firmware to hold off booting from harddisk and stop at the menu.
2) can be achieved with setting either AutoLoad=no in the PROM (or setting bootmode=m on old systems).

As for 1) most older workstations just cold reset when you powercycle by either pressing the button or pull and reconnect the plug.
Origin and some Onyx2 systems have a serial console and separate L1 or MSC port, or sometimes a combined L1 console. With the L1 or MSC you can cold reset the machine. See http://techpubs.sgi.com/library/dynaweb ... /ch05.html for a SGI solution of remotely managing consoles and L1's which they named "SGIConsole"

Fuels and Tezro's should have something similar.

Most of this is from reading docs, so please don't take my word as gospel, since i only have experience with Origin 200's.

You could automate the earliest stage of installation by using a terminal server connected to each machine's console port.

dexter1 wrote: As for 1) most older workstations just cold reset when you powercycle by either pressing the button or pull and reconnect the plug.

I had planned on using a switched PDU to allow for a system not in use to stay offline until needed and also for reboots. That would be rather simple as well.

robespierre wrote: You could automate the earliest stage of installation by using a terminal server connected to each machine's console port.

That was my thought as well. It was about the only use I thought I may have for the SGI 1100 server. Add one of these pci cards and you should be good to go.

http://www.comtrol.com/rocketport-multi ... i-octa-db9

It would have many other uses as well.

Rev.Bubba wrote: I had planned on using a switched PDU to allow for a system not in use to stay offline until needed and also for reboots. That would be rather simple as well.

robespierre wrote: You could automate the earliest stage of installation by using a terminal server connected to each machine's console port.

I have much of this in place: I have a pair of APC 7953 PDUs (one in my 19" rack, one behind the workstations). This allows me to remotely switch power to just about anything. Admittedly, my motivation was not having to bend over an Onyx ever again to reach for the breaker, but it works really well.

I also have an Cyclades ACS48 Console Server connected to just about anything with a serial console port. The amount of wiring is .... something.

Both of these I picked up for reasonable amounts of money and because they are enterprise hardware they come with neat goodies like scriptability, support for Radius etc in addition to a web interface.

As far as RoboInst is concerned: I believe it works best if the dist server and the target run the same IRIX version, and I also believe it requires a license. But I never messed with it myself.

At this point I would replace any accessible services with ones from xBSD or Gnu/Linux. Probably even consider a SSH or VPN host to go through to get to the SGI. Not sure about client apps on the SGI - I do occasionally use Firefox, but generally for "trusted" sites (for whatever degree of validity "trusted" is ... not much).