CalendarQuicksearchArchivesCategoriesBlog AdministrationPowered byLizenz/LicenseDer Inhalt dieses Blogs ist © Copyright 2009 Ralf Ertzinger. Jegliche Reproduktion und Wiederverwertung nur mit schriftlicher Genehmigung des Autors. The content of this blog is © Copyright 2009 Ralf Ertzinger. |
Saturday, March 28. 2009Login via serial consoleGetting a serial console (for login purposes) on OpenSolaris seems to be a two-sided operation. Either it is insultingly simple, or a convoluted mess. The two options I've discovered so far, in order of difficulty. h3. The easy way By default Solaris starts a login console on h3. The hard way Assuming that for whatever reason Historically a Login processes are handled by the Service Access Controller ( It looks like # svccfg -f - < Tuesday, March 24. 2009iSCSI: Opensolaris target, Fedora initiator, with CHAPFor some reason or another finding instructions on how to actually configure iSCSI for a rather simple and common use case (one target on Solaris, one initiator on Fedora, CHAP authentication) seems to be pretty hard. Either my google-fu is seriously broken today, or everyone except for me considers this to be so easy and obvious that it does not warrant documentation. Which, having done this for the last three hours, I seriously doubt. The Solaris side is actually documented quite well (I primarily used this blog entry by alasdair), the Linux side is lacking. It does not help matters that both sides use identically named tools that work in completely different ways. So, the deal is as follows: One OpenSolaris system, acting as iSCSI target (that is the system presenting the storage space). One Fedora Linux system, acting as iSCSI initiator (that is the system that wants to use the storage space) Create 100GB storage space on the target and let the initiator connect to this storage space and create a filesystem on in. The connection has to be authenticated one way (the initiator presents credentials to the target). h3. The Solaris side The system is running Nevada, the configuration here was done with build snv_110. First, the iSCSI target software needs to be installed and enabled: # gkp.pl -d /mnt/Solaris_11/Product SUNWiscsitgtu # svcadm enable iscsitgt:default # The backing store for the iSCSI volumes shall be provided by ZFS: # zfs create -o canmount=off tank/iscsi # zfs create -V 100G -o shareiscsi=on tank/iscsi/vol001 # iscsitadm list target -v Target: tank/iscsi/vol001 iSCSI Name: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8 Alias: tank/iscsi/vol001 [...] # The # iscsitadm create tpgt 1 # iscsitadm modify tpgt -i 212.51.12.90 1 # iscsitadm list tpgt -v 1 TPGT: 1 IP Address: 212.51.12.90 # iscsitadm modify target -p 1 tank/iscsi/vol001 # iscsitadm list target -v Target: tank/iscsi/vol001 [...] TPGT list: TPGT: 1 [...] # In order to secure access to this volume some more the initiator is required to authenticate itself using CHAP before access is granted. To do this three pieces of information are needed:
The initiator used here has an iqn of # iscsitadm create initiator -n iqn.2005-03.com.max:01.cb5c4c lain # iscsitadm modify initiator --chap-name lain lain # iscsitadm modify initiator --chap-secret lain [...] # iscsitadm list initiator -v Initiator: lain iSCSI Name: iqn.2005-03.com.max:01.cb5c4c CHAP Name: lain CHAP Secret: Set # iscsitadm modify target --acl lain tank/iscsi/vol001 # iscsitadm list target -v Target: tank/iscsi/vol001 [...] ACL list: Initiator: lain [...] # This concludes the Solaris side of things. h3. The Fedora side The system is running Fedora Rawhide, close to the Fedora 11 Beta release at the time of this writing. On the Linux side iSCSI is handled by the open-iscsi toolchain, packaged as # yum install iscsi-initiator-utils [...] # Since the system in question is a notebook, and the iSCSI target may not be available at all times, the iSCSI service must be instructed not to connect to configured devices automatically: # perl -pi -e 's/node.startup.*/node.startup = manual/' /etc/iscsi/iscsid.conf # The initiator name mentioned in the Solaris section above can be configured freely on the system. A random value is created during package installation and saved in # cat /etc/iscsi/initiatorname.iscsi InitiatorName=iqn.2005-03.com.max:01.cb5c4c # Be sure the name configured there matches the name defined in the initiator on the Solaris side. Even though a username/password pair was defined on the target credentials are not needed for target discovery (the process by which an initiator asks a target which iSCSI volumes are available): # iscsiadm -m discovery -t st -p 212.51.12.90 212.51.12.90:3260,1 iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8 # iscsiadm -m node 212.51.12.90:3260,1 iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8 # The discovery process has found a single volume exported by the target and added it to the local node list. The iqn matches the value shown above in the Solaris section. Now the CHAP credentials have to be added to the node so the initiator can actually connect to the volume: # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \ --name 'node.session.auth.authmethod' -v 'CHAP' # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \ --name 'node.session.auth.username' -v 'lain' # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \ --name 'node.session.auth.password' -v 'iscsipassword' # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' node.name = iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8 node.tpgt = 1 node.startup = manual [...] node.session.auth.authmethod = CHAP node.session.auth.username = lain node.session.auth.password = ******** [...] # Now the volume can finally be accessed: # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' --login Logging in to [iface: default, target: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8, portal: 212.51.12.90,3260] Login to [iface: default, target: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8, portal: 212.51.12.90,3260]: successful # After some seconds a device node for this volume should appear in # ls /dev/disk/by-path/ ip-212.51.12.90:3260-iscsi-iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8-lun-0 [...] # The disk is ready to be used.
Posted by Ralf Ertzinger
in Computer, Linux, Software, Solaris
at
00:16
| Comments (0)
| Trackbacks (0)
Monday, March 23. 2009Using pkgsrc on Opensolaris, Part 3h3. Initial install
The tarball already contains a pkgsrc directory at the top level, so it has to be unpacked under # wget ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.gz # gtar -xzf pkgsrc.tar.gz -C /usr # chown -R builder: /usr/pkgsrc This will unpack the tarball into the filesystem mounted at h3. Patching gcc Unfortunately the gcc suite as delivered with Solaris has a small flaw, which will cause some packages to be built incorrectly (the most famous example is openssl, which will build but not work afterwards). Fortunately the bug has been tracked down and a bandaid is available here. This file is a nice little hack in itself as it is a shell script and a C source file at the same time. If executed by a shell this file will be put though gcc three times to produce three object files, which are placed into a directory where the compiler can find them and use them instead of files that were delivered with the compiler. # bash ./values.c /usr/sfw/bin/gcc [....] # ls -l $(dirname $(/usr/sfw/bin/gcc -print-libgcc-file-name)) [...] -rw-r--r-- 1 root root 763 2009-02-21 17:34 values-Xa.o -rw-r--r-- 1 root root 763 2009-02-21 17:34 values-Xc.o -rw-r--r-- 1 root root 763 2009-02-21 17:34 values-Xt.o # h3. Bootstrapping With this particular bug out of the way # cd /usr/pkgsrc/bootstrap # PATH="$PATH:/usr/sfw/bin:/usr/xpg4/bin" ./bootstrap [....] # Bootstrapping will take a while, but it should run though cleanly. Afterwards there should be some files in h3. Vulnerabilities and updates Packages need to be kept up-to-date, for new features as much as for possible vulnerabilites. In the latter department the bootstrap installed two programs to help with identifying such programs.
Both programs should be used on a regular basis. Updates of packages (whether due to a vulnerability or not) are best done via CVS. Updates can be done on the whole package tree or on individual subtrees, as needed. Assuming an older installed version the following command will update the whole tree to 2008Q4: # su - builder $ cd /usr/pkgsrc $ cvs up -dPR -rpkgsrc-2008Q4 [...] $ It's important to check the output of the CVS command for eventual problems, especially if local modifications to packages have been done. h3. Host tools There are a number of tools that are used by a large number of packages during the build process. Among these tools are
GNU make and GNU tar are already installed, the rest of the packages can be found on the Solaris install media. The rest can easily be installed: # gkp.pl -d /mnt/Solaris_11/Product SUNWgm4 SUNWgnu-gettext SUNWgpch SUNWunzip \ SUNWbison SUNWflexlex [...] # Now # SUNWgm4 TOOLS_PLATFORM.m4= /usr/bin/gm4 TOOLS_PLATFORM.gm4= /usr/bin/gm4 # SUNWgmake TOOLS_PLATFORM.gmake= /usr/bin/gmake # SUNWgnu-gettext TOOLS_PLATFORM.msgfmt= /usr/bin/gmsgfmt # SUNWgtar TOOLS_PLATFORM.tar= /usr/bin/gtar TOOLS_PLATFORM.bsdtar= /usr/bin/gtar # SUNWgpch TOOLS_PLATFORM.patch= /usr/bin/gpatch TOOLS_PLATFORM.gpatch= /usr/bin/gpatch # TOOLS_PLATFORM.perl= /usr/bin/perl # SUNWunzip TOOLS_PLATFORM.unzip= /usr/bin/unzip # SUNWbison TOOLS_PLATFORM.bison= /usr/bin/bison TOOLS_PLATFORM.bison-yacc= /usr/bin/bison -y # SUNWflexlex TOOLS_PLATFORM.lex= /usr/bin/flex Tuesday, March 17. 2009Using pkgsrc on Opensolaris, Part 2Preparing the system for h3. Compiler environment The Solaris core installation does not come with a compiler, but a version of GCC 3 can be found on the DVD (3.4.3 in snv_109). In addition to the compiler itself several other programs are needed to get
The complete command line for installing all this is # gkp.pl -d /mnt/Solaris_11/Product SUNWarc SUNWgccruntime SUNWbinutils SUNWgcc \ SUNWgmake SUNWhea SUNWlibmr SUNWlibm SUNWxcu4 SUNWsprot The compiler is installed into h3. Directories and users By default
There is no good reason to change these defaults here. # zfs create -o mountpoint=/usr/pkg rpool/pkg # zfs create -o mountpoint=/usr/pkgsrc rpool/pkgsrc These two commands create two new filesystems on the root pool and set the mount points to the correct directories. The filesystems are automatically mounted and are immediately ready to be used. Having a special user for building packages instead of using root is a good idea in general. It protects the system from eventual errors in the build system, which might cause files to be written outside the build root (even if those files are completely harmless and not malicious they are a nuisance nonetheless). The build user should also have no special privileges on the system. # useradd -d /export/home/builder -m -s /usr/bin/bash -c "pkgsrc build user" builder Thursday, March 12. 2009Using pkgsrc on Opensolaris, Part 1Even though Solaris comes with a large selection of software these days (and some of it in recent versions) there still will be software that is not on the install media. In my case the greatest itch was rtorrent. I was not too keen on the idea of building everything from scratch the classic way ( All this sounded a lot like the FreeBSD ports system to me which I found to be unavailable on Solaris. But the general idea was sound, and in the immediate neighbourhood I discovered the NetBSD
On the other hand it can be instructed to use the compiler and tools supplied by the guest operating system, if those are available and recent enough, so that just software that the guest system does not supply is built by
Wednesday, March 11. 2009Building an OpenSolaris storage - Software, Part 6Since I tend to forget these things, here's a short list showing various package management tasks. |_. Task |_. RPM |_. pkg (Solaris) |
| List all installed packages |
Posted by Ralf Ertzinger
in Computer, Linux, Software, Solaris
at
19:50
| Comments (0)
| Trackbacks (0)
Friday, March 6. 2009Building an OpenSolaris storage - Software, Part 5Some releases ago Solaris introduces a Role Bases Access System (details and introduction here). The upshot of this is that Profiles can be attached to a user account, giving this account elevated privileges for some tasks. The main administrator account should probably be able to execute all command with root privileges. Linux/BSD systems use Almost all tutorials about # gkp.pl -d /mnt/Solaris_11/Product SUNWwbcor [...] # usermod -P'Primary Administrator' admin # su - admin $ id uid=500(admin) gid=100(users) $ pfexec id uid=0(root) gid=0(root) The admin user can now execute every command as root without needing the root password (or any password, for that matter) simply by prefixing it with Building an OpenSolaris storage - Software, Part 4After the newly installed system has booted for the first time it is time to make Solaris a bit more homely. This involves installing a number of packages, which brings me neatly to the first thing that annoys me (and probably a lot of other people used to current Linux distributions): the package management is an absolute mess. Most Linux distributions take a two-tiered approach to package management: there are low level tools that allow installation of one or more packages, reading from a local filesystem, removal of packages, listing information about packages and so on. RPM is an example of this, as is DPKG. Then there are high level tools that know about local and remote collections of packages, can resolve dependencies for package installation and removal. YUM, APT and PackageKit are examples of these tools. Unless something is severely broken the high level tools are used for package management in the usual cases. Noone actually wants to do all the manual dependency solving and package downloading themselves, that's what computers are for, after all. Unfortunately all Solaris provides are tools of the first category. While I understand that changing the low level tools is impossible for binary compatibility reasons I do not see a reason why high level tools for handling all the grunt work are not being provided. The logical response to this dilemma is to write a rudimentary high level tool which takes away some of the pain. My version is written in Perl (which, astoundingly, is part of the core install, and not even insultingly old). Currently all it can do is install packages. It relies on the dependency information in the Solaris packages, which is spotty at best. So, lets make this system a bit more habitable. mount -F nfs 10.200.200.1:/jumpstart /mnt gkp.pl -d /mnt/Solaris/Product SUNWgcmn SUNWwgetr SUNWwgetu SUNWntpr SUNWntpu SUNWgtar \ SUNWsshcu SUNWsshr SUNWsshu SUNWsshdr SUNWsshdu SUNWbash SUNWless SUNWdoc SUNWman \ SUNWgnu-coreutils SUNWtoo Among other things this will install
h3. Setting the root shell I probably won't make many friends here, but I like bash. And I also like a root shell I can actually work with. So, root gets a bash. Contrary to what other people might say this is an absolutely harmless change on modern Solaris systems. usermod -s /usr/bin/bash root h3. Configuring SSH Working on the console itself is tedious, so getting SSH up and running is important. Even though the packages are installed they are not configured or enabled yet. First, though, I usually define a special group to which accounts which are allowed to ssh into the system are added. Then the keys are generated, and finally ssh is enabled. groupadd sshusers echo "AllowGroups sshusers" >> /etc/ssh/sshd_config /lib/svc/method/sshd -c svcadm enable ssh h3. Security settings By default Solaris creates perl -pi -e 's/^CRYPT_DEFAULT=.*/CRYPT_DEFAULT=1/' /etc/security/policy.conf This will not change existing accounts. Only newly created password hashes are affected. This means that the root password should be set again, to create a new hash. h3. Adding normal users Working as root is a bad idea, so adding normal users is the order of the day to do normal work on the system. I prefer to have a special group containing all normal users, so this has to be added as well. In addition, giving every user a separate ZFS filesystem as home directory is a good idea. The dataset Since this is going to be a storage system without a lot of users there is no big problem with groupadd users zfs create rpool/export/home/admin useradd -g users -G sshusers -d /export/home/admin -s /usr/bin/bash \ -c "Admin User" -m admin chown -R admin:users ~admin The user becomes a member of the
(Page 1 of 1, totaling 8 entries)
|