Recommendations

[vishnu]

I am still running Irix systems on the Internet. This are private projects, like the nekoware mirror and I had never problems with it. Our company used around the year 2000 a Challenge S as a secondary nameserver. This server was located at another Internet service provider (for free) and we simply forget this server. When this company moved the location some years ago, they asked us if we still using this server. So we got it back and examined it, it was running Irix 6.2 and never get hacked after 10 years running without any administration.

So wait, by decree of the IETF every domain name has to have at least two nameservers, with different IP addresses, serving the domain. So did you guys forget about that nameserver or just not worry about it since it was working? Cuz otherwise I don't see how you could actually literally forget about one of your nameservers, unless you had dozens, which admittedly the big providers do...

[diegel]

So wait, by decree of the IETF every domain name has to have at least two nameservers, with different IP addresses, serving the domain. So did you guys forget about that nameserver or just not worry about it since it was working? Cuz otherwise I don't see how you could actually literally forget about one of your nameservers, unless you had dozens, which admittedly the big providers do...

First of all we are using more than one secondary and we are spreading this over more than one network provider. And of course we first moved the service to more modern hardware before we forget this server.

[vishnu]

irst of all we are using more than one secondary and we are spreading this over more than one network provider. And of course we first moved the service to more modern hardware before we forget this server.

Oh, the joys, of a life in IT. https://groups.google.com/forum/#!forum/alt.sysadmin.recovery

[armanox]

If you want to secure your installation....

Minimize running services. If you want to really see the ins-and-outs of your SGI machine, run a Nessus scan on there. If you are running it for yourself a Tenable allows home users to download it for free (there are some limitations, such as how many hosts you can scan and you can not do compliance checking). That should give you a very good starting point on where to start disabling extra running software, and should point you at a lot of out dated software.

Step two: Update your software. For things that you are using, use the most updated copy you can. Nekoware provides a lot of easy to install tardists that are much newer then what SGI provided, and you can also consider building your own software.

Step three: Secure your network. Firewalls, IPS/IDS, and such are your friends.

Disclaimer: I am a former employee of Tenable Network Security. This is not a paid advertisement, nor do I represent the company in any way, shape, or form. I just think they still make the best Vulnerability Scanner on the market.

[necron2600]

Plus.. you could place any services you are running inside a chroot. Call it a form of virtualization... IRIX-containers, IRIX-zones, IRIX-jails, etc.. (yeah, i know its not virtualization.. but its probably as close as we'll get with IRIX).

Chroot's can still be broken out of.. but better than giving a remote attacker full access immediately to your root filesystem that comes complete with exploitable binaries and apps.

octane 14# gtar xpvf chroot-irix.tar
chroot-irix/
chroot-irix/dev/
chroot-irix/dev/zero
chroot-irix/dev/null
chroot-irix/dev/random
chroot-irix/dev/urandom
chroot-irix/sbin
chroot-irix/incoming/
chroot-irix/usr/
chroot-irix/usr/lib32/
chroot-irix/usr/lib32/libc.so.1
chroot-irix/bin/
chroot-irix/bin/chmod
chroot-irix/bin/chown
chroot-irix/bin/groups
chroot-irix/bin/ldd
chroot-irix/bin/ln
chroot-irix/bin/ls
chroot-irix/bin/mkdir
chroot-irix/bin/mv
chroot-irix/bin/pwd
chroot-irix/bin/rm
chroot-irix/bin/rmdir
chroot-irix/bin/scp
chroot-irix/bin/sh
chroot-irix/bin/csh
chroot-irix/lib32/
chroot-irix/lib32/libc.so.1
chroot-irix/lib32/rld
chroot-irix/lib32/libcrypto.so.0
chroot-irix/lib32/libz.so
chroot-irix/etc/
chroot-irix/etc/passwd
chroot-irix/etc/group

octane 15# cd chroot-irix
octane 16# chroot . /bin/sh
# pwd
/

Place a /usr/nekoware/lib/ dir in the chroot with any required libraries for your app.. and your good to go inside a chroot. Run a webserver, mailserver, etc.. Will take some fiddling to get the required libs and dirs in place.

-Kevin

[jan-jaap]

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.:

Code: Select all

speedo 3# chroot /build53 /bin/ksh
# uname -a
IRIX speedo 5.3 07202013 IP35 mips
#


Pretty sure IRIX 5.3 never ran on IP35

[Rev.Bubba]

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

[dexter1]

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.

[Rev.Bubba]

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.

[dexter1]

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...

[robespierre]

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.

[dexter1]

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.

[Rev.Bubba]

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.

[dexter1]

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.

[robespierre]

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