Posts filed under 'OpenSolaris'

How much memory is in the box? (all UNIX, OpenVMS)

How much memory is in this machine?

It would seem that answering this question ought to be easy; it is - but every system has the answer in a different place. Most put an answer of some sort into kernel messages reported by dmesg (AIX apparently does not).

Most systems have a program for system inventory which reports a variety of things, including memory.

Rather than go into great detail about each one, we’ll just put these out there for all of you to reference. Each environment has multiple commands that give available memory; each command is listed below.

Without further ado, here are a few answers to this burning question:

Solaris

  1. dmesg | grep mem
  2. prtdiag | grep Memory
  3. prtconf -v | grep Memory

AIX

  1. bootinfo -r
  2. lsattr -E1 sys0 -a realmem
  3. getconf REAL_MEMORY

HPUX

  1. dmesg | grep Physical
  2. /opt/ignite/bin/print_manifest | grep Memory
  3. machinfo | grep Memory

Linux

  1. dmesg | grep Memory
  2. grep -i memtotal /proc/meminfo
  3. free

OpenVMS

  1. show mem /page

Update:

FreeBSD

  1. dmesg | grep memory
  2. grep memory /var/run/dmesg.boot
  3. sysctl -a | grep mem

Add comment 3 May 2008

Finding devices for your open source operating system

In a Windows environment, people have gotten used to just picking up any device (whether it is a CDROM, PCMCIA card, printer, or modem) and expecting it to work. While the concept of “plug and play” is not yet here, the fact is that when installed everything should work with Windows.

And it isn’t just Windows - other large commercial vendors have access that you and I do not. Apple comes to mind - MacOS X has much better support than Linux or FreeBSD, for example.

Open source operating systems rely on hardware manufacturers to make the details of their hardware available for free or low cost - and then for someone to come and craft the software drivers needed. Usually, the latter is not a big problem; the former is.

The problem can be deeper than that as well, since the label on the product is not the same as the label on the internal devices: so it is not possible to simply look for a brand and use it. Worse, manufacturers can change hardware vendors on the same model, so that discerning which model is which can occasionally be difficult - the revision becomes the determining factor as to which hardware was used.

First thing is to determine which devices are supported. Start with the release documents for the operating system and look for supported hardware. Another place to look is the man pages (or other documentation) for the drivers. Keep the list of specific hardware handy, on another screen or printed out.

Then, look for the device (or devices) at your chosen store. Write down what you find, even if it isn’t listed (and even if it is). Then look up the device on the Internet using your desired search engine. Pay attention to mailing list threads and watch what sort of trouble people had (or didn’t have). The mailing list threads should also help you identify the hardware sources used in otherwise unidentified products, and also will keep you up to date on people’s experiences.

Once you have a product chosen, given few problems on mailing lists and a well-supported and identified hardware chip set, then buy it. However, for best results, make sure there is a good return policy in case it doesn’t work - otherwise, you are taking a chance (albeit a very small one if you’ve done your homework).

I’ve gone through this with several wireless cards under FreeBSD. The first was the Netgear MA401 (researched as given here) - worked flawlessly until it was smushed. The second I received as a bonus with my laptop purchase was a Zonet 1502 (definitely a mistake, but it came with the laptop). I’m sure the Zonet works fine under Windows (and probably OpenBSD: they reverse engineered the driver). Currently, I’ve added a TP-Link TL-WN610G (again researched as described here) - also working flawlessly.

This isn’t just good practice for wireless cards, though - networking cards, mice, video - all benefit from this research. Even laptops: when I bought my laptop, I researched the two brands that were available (for sale used at my favorite local used computer store) and found that one had lots of difficulties and the other did not. Guess which one I bought?


Add comment 23 February 2008

Generating a coredump (gcore)

If you wish to examine a runaway program outside of its element, you may choose to use the utility gcore. This utility is found in Solaris, Linux, and HP-UX, and perhaps others. The program syntax is:

gcore [ -o corename ] pid

The pid is the process id of the process to dump core, and the corename is the base of the filename to use for the core dump - the full name is the base name plus period (”.”) and the process id number. The default is to use “core“.

HP-UX systems will accept multiple process ids instead of just one. Solaris has several additional flags (as well as multiple pids). The additional Solaris flags won’t be covered here.

Once core has been dumped, the program continues operation; it does not stop. Thus, gcore is especially useful for taking a snapshot of a running process.

For example, consider a program with the process id 6674:

gcore 6674

This command generates a core file in the current directory with the name “core.6674“. This file then can be read by the GNU debugger gdb. Solaris also provides the dbx(1), mdb(1), and pstack(1) utilities. HP-UX provides gdb as well as the HP adb(1) utility. Both Solaris and HP-UX provide a core management utility coreadm(1m) - which is a topic for another day.

This article has an excellent description of working with core files in Solaris.


Add comment 16 January 2008

When root is locked out…

When root is locked out of a system, it can be a real problem. It’s even worse when you are root, yes?

There are many legitimate reasons this can happen:

  • You purchased a used system with operating system installed, and the root login is unknown.
  • The root password expired. (This has happened!)
  • You have taken on a new system as a system administrator, and no one knows what the root password is (or what the box is, or what it does…)
  • You have taken on a job as a new system administrator, and the previous administrator didn’t leave all of the passwords.
  • You just plain forgot the system password (uhoh…).

We are going to assume that single user mode is locked out or not available. We are also going to skip talking about taking the system down (which is going to be necessary in any case).  We are also going to assume that you have legitimate physical access to the system.

In most situations, the system admin’s adage holds true: if you have physical access to the box, then there’s no stopping you from breaking in.  That’s why many operating systems make it fairly easy to access the system with physical access - and this is the reason you must physically secure your servers.  Putting them behind locked doors is the easiest and best way to go.  With physical access, it generally becomes easy to get into the system.

If you can access single user mode (such as booting HP-UX with “hpux -is” or booting Linux with “linux single“) then you can do all of the password recovery steps quite easily.

No matter what the operating system, if you have physical access to the system itself, then it is generally possible to crack it. There is a method that will work with any system:

  1. Convert the disk into a “secondary” data disk in some fashion.
  2. Boot into another operating system that can read and write the now secondary data disk.

There are several ways to do this. One way is to use a bootable floppy, CDROM, or DVDROM to enter into a maintenance mode, then access the original boot disk in the system. Sun Solaris has this capability using the install disk, as does Red Hat Enterprise and OpenSUSE. There are also bootable floppies and CDROMs that run on Linux all over everywhere.

Another way is to physically extract the hard disk from the system, and to use it as a data disk on another (identical) system. Macintosh laptops have this capability “builtin”: it’s called Target Mode, and turns the laptop into a large disk on a Firewire connection to a desktop or other system.

Remember, however, that the Macintosh uses NetInfo to manage its data; you’ll probably have to manipulate the NetInfo database on the other system in some fashion, or at least, turn it off.  That’s currently beyond our knowledge (but who knows…).

Under HP-UX, the boot disk is probably a single volume group, vg00: this volume group would have to be vgexported and vgimported in some fashion. The LVM structures would have to be accounted for.

Once the once bootable system is correctly mounted (read and write) as a data disk on another system, the easiest thing to do (with UNIX and Linux) is to change root’s password to null, by making the password entry empty in the /etc/password file. With NT, you may be able to extract the SAM file and use a cracker like L0pht to reveal the password.

With OpenVMS, the steps are more complicated, but the concept is the same: use a different security environment (an alternate UAF) and change the password in the original environment (the original UAF). First, alter the booting process to make OpenVMS boot into a sysboot> prompt. At this prompt, enter the command to use an alternate UAF:

sysboot> set uafalternate 1
sysboot> continue

The username and password to login will be null, so login by pressing enter until the prompt appears. Then we need to go about changing the password entry for SYSTEM:

$ define/system/executive sysuaf sys$system:sysuaf.dat
$ set def sys$system
$ run authorize
Authorize> modify system/password=newpass/nopwdexp
Authorize> exit

Then restore the alternate UAF setting back to zero so that the system UAF will be used on reboot:

$ run sys$system:sysman
sysman> param use current
sysman> param set uafalternate 0
sysman> param write current
sysman> exit

Then reboot the system and the SYSTEM password should be newpass.

This sequence hints at one reason a root password might “go bad” - if your root password expires, then you are undone. These steps still work, but instead of changing the password, one will have to reset the expired account so you can login again.


Add comment 17 December 2007

Implementing Security (and the NSA)

The NSA is, of course, the United States National Security Agency. It’s their job to a) keep the nations computers secure; b) find out how to break everyone else’s (ah, the dichotomy of national intelligence!). Thus, some of the best computer security minds are at the NSA - it was the NSA that brought us SELinux (and still does!).

They also have a vast array of security guides available for download. These include guides on securing Solaris 8 and 9, MacOS X 10.3 and 10.4, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and more.

Use a security guide next time you secure a box - and not necessarily just one. Do some research. Implement all of the security you can on all of your boxes - even if it is not on the Internet. One day, someone might just crack through - then all of your internal systems will be at risk. Each system should be able to withstand an assault without falling.


Add comment 5 December 2007

SystemTap (and DTrace)

SystemTap is one amazing piece of work - it is a programmer-friendy and admin-friendly interface to KProbes (which are included in the Linux 2.6 kernel).  When you compare its capabilities to what has gone before, it is truly amazing.  Here are some of the things you can do:

  • Quantify disk accesses per disk per process (or per user)
  • Quantify the number of context switches that are a result of time outs
  • List all accesses to a particular file and the process that accessed it

This is only the tip of the iceberg. There is a wiki with more details, including “war stories.”  There is a language reference there as well.

There was an excellent article in Red Hat Magazine, “Instrumenting the Linux Kernel with SystemTap” by William Cohen.

One controversy that came up was that the initial impetus for creating SystemTap was to implement something like Sun’s DTrace for Solaris but under the GNU Public License.  Solaris and DTrace are licensed with Sun’s Common Development and Distribution License (CDDL), which many feel makes DTrace incompatible with the GPL-licensed Linux kernel.

Apparently, the CDDL is also incompatible with the BSD-licensed FreeBSD, as FreeBSD 7.0 will not have DTrace either.  There appears to be some licensing issues.

According to the Wikipedia entry on the CDDL, it was designed to be both GPL-incompatible and BSD-incompatible.  With regard to the GPL, the entry suggests that Sun never clarified why; as to the BSD, Sun did not want Solaris to wind up in proprietary products - which the BSD license allows.

On a brighter note, Eugene Teo was able to get the SystemTap tool to work on the Nokia N800.  The article seems to be behind a wall at LiveJournal; the article is still in Google’s cache.  However, it does requires some amazing convolutions:

  • A kprobes-enabled kernel must be installed on the N800
  • The SystemTap programs (like stap) must be installed on the N800
  • Any traces must be cross-compiled on another host
  • The kernel module thus created must be moved to the N800
  • Once the kernel module is in place, then the trace can be done.

So every desired trace requires precross-compilation on a desktop (sigh)…  Oh, well.

There is even a GUI for SystemTap in the works.


1 comment 4 December 2007

IBM z/Series and OpenSolaris

In the past, the z/Series has been known for its virtualization of Linux servers (over 10,000 possible!). Now, someone is showing OpenSolaris running on z/Series at the Gartner Data Center Conference in Las Vegas. There is an excellent write-up from the Mainframe blog, and another post from Marc Hamilton.

There is also an excellent open source IBM zSeries emulator called Hercules which can run Linux, MVS, DOS/VSE and others - and now, soon, OpenSolaris.

There is a very interesting speech given at Linuxworld by Guru Vasudeva from Nationwide about how his company implemented virtual Linux machines on IBM zSeries with z/VM.

When I first saw this (from IBM’s web site) I thought it was laugh out loud funny - and it still is. It also gives a hint at the power of the IBM z/Series, and shows one of the reasons I’m excited about the power one of these has.

I just love the deadpan Joe Friday responses from the cops, and some of the quotes:

  • “Could it be an inside job? We’re inside, right?”
  • “I need my pills!”
  • “What’s a server?”

Add comment 30 November 2007

Running Linux/UNIX under VMware Server 1.0

I have the distinct pleasure of having tried a number of systems under VMware Server, including OpenSUSE 10.3, Kubuntu 7.10, OpenBSD, and Solaris Express Developer Edition.  All work quite nicely.

There is one caveat - this environment uses a dual-monitor setup for Windows, and if the emulator autodetects the desktop size it expands to something approximating the two monitors put together.  The emulated environment works just fine (usually) with this screen, but it can’t be used in full-screen mode (since that goes to one screen only).

In that line of video mishaps, Solaris detected the video but only wants to allow 1024×768 (I’ve 1280×1024 here).  Whatever.

I also did not try OpenBSD as a desktop environment - I’ve actually yet to really put it through its paces that way (although I did set up OpenBSD 3.0/Mac68k with WindowMaker a while back….).

Which one do I like the most?  Currently I find myself looking toward OpenSUSE 10.3 more and more - and loving to use it.  The new KDE menu is a pleasure to use, and I love the immense selection of RPMs (and I do like RPM as it is).

The fact that they split up the KDE RPMs seems ghastly to me - too many things to choose.  For example, KDE Office is available in all its little bits - as is KDE Toys, KDE Games, and whatever else.  Nicer just to choose to install KDE Toys or not… I’m not sure whether I like having KDE 3 as a base with all of the KDE 4 applications available - but it seems to work alright.

I’d like to install BeleniX next, but they’ve not updated their system yet - the last hard disk install was buggy. I’m waiting eagerly….


Add comment 29 November 2007

Sun passes up SAMBA

Sun decided to put CIFS support directly into the Solaris kernel instead of using SAMBA. Serverwatch reported on it, as did TechRepublic.

This sounds like a good idea: put support into the kernel where it is faster and has access to more of the insides of the kernel (rather than going through interfaces).  It is like programming on the bare metal instead of using the standard toolbox calls (or API).

However, the downside is not often reported: this will make the kernel even larger and opens up security risks as well.  I tend more to believe in the small kernel more than anything, and Solaris already appears to be one of the largest kernels in the open source arena.

Time will tell whether this was a good idea or not.


Add comment 28 November 2007

OpenSolaris on a MacBook

OpenSolaris is very interesting, and since the introduction of dtrace and ZFS has enthralled many. I tried to install it onto my HP Compaq E300 laptop (which it was unsuitable for), and tried to install it onto an HP Compaq 6910p laptop. In this case, the networking was unsupported: both the ethernet and the wireless drivers were not included with OpenSolaris Express (Developer Edition).

In any case, I expect I might just be shopping for a laptop in the next year - and it’s nice to see that OpenSolaris does run on the Apple MacBook.  This article goes into detail about how the writer got it to work, and each of the steps that were taken to make it happen.  Paul Mitchell from Sun discusses dual-partitioning a MacBook in this context as well.  Alan Perry (also from Sun) had done the same thing with a Mac Mini, and Paul extended it to the MacBook.  Both entries are detailed and have to do with MacOS X and Solaris dual-booting.

An a different note, check out the graph of library calls from dtrace in this article.  From what I’ve heard of dtrace, it’s the ultimate when it comes to debugging…


Add comment 22 November 2007

Previous Posts


David Douthitt

David is an experienced UNIX and Linux system administrator, a former Linux distribution maintainer, and author of two books ("Advanced Topics in System Administration" and "GNU Screen: A Comprehensive Manual").

View David Douthitt's profile on LinkedIn

Top Posts

Calendar

May 2008
M T W T F S S
« Apr    
 1234
567891011
12131415161718
19202122232425
262728293031  

Recent Posts

Recent Comments

ddouthitt on Core Linux - packages
GRUBówka « Bl… on Installing GRUB on FreeBS…
monsun on Installing GRUB on FreeBS…
hictio on Core Linux - packages
locky on Installing GRUB on FreeBS…

Category Cloud

BSD Career Debian Debugging Fedora FreeBSD HPUX Learning Linux MacOS X Mind Hacks Mobile Computing NetBSD Networking OpenBSD OpenSolaris Open Source OpenVMS Personal Notes Portable Presentations Programming Red Hat Scripting Security Solaris Tips Ubuntu UNIX Wheel Group

Archives

Links