Tuesday May 28, 2013

Adding users in Solaris 11 with power like the initial account

During Solaris 11.1 installation, the system administrator is prompted for a user name and password which will be used to create an unprivileged account. For security reasons, by default, root is a role, not a user, therefore the initial login can't be to a root account. The first login must use the initial unprivileged account. Later, the initial unprivileged user can acquire privileges through either "su" or "sudo".

For enterprise class deployments, the system administrator should be familiar with RBAC and create users with least privileges.

In contrast, I'm working in a lab environment and want to be able to simply and quickly create new users with power like the initial user. With Solaris 10, this was straight forward, but Solaris 11 adds a couple of twists.

Create a new user jenny in Solaris 11:

# useradd -d localhost:/export/home/jenny -m jenny
# passwd jenny

Jenny can't su to root:

jenny@app61:~$ su -
Password:
Roles can only be assumed by authorized users
su: Sorry

Because Jenny doesn't have that role:

jenny@app61:~$ roles
No roles

Give her the role:

root@app61:~# usermod -R root jenny


And then Jenny can su to root:

jenny@app61:~$ roles
root

jenny@app61:~$ su -
Password:
Oracle Corporation      SunOS 5.11      11.1    September 2012
You have new mail.
root@app61:~#


But even when jenny has the root role, she can't use sudo:

jenny@app61:~$ sudo -l
Password:
Sorry, user jenny may not run sudo on app61.

jenny@app61:~$ sudo touch /jenny
Password:
jenny is not in the sudoers file.  This incident will be reported.


Oh no, she is in big trouble, now.

User jeff was created as the initial account, and he can use sudo:

jeff@app61:~$ sudo -l
Password:
User jeff may run the following commands on this host:
    (ALL) ALL


But jeff isn't in the sudoers file:

root@app61:~# grep jeff /etc/sudoers

So how do you make jenny as powerful as jeff with respect to sudo?

Turns out that jeff, created during the Solaris installation, is in here:

root@app61:~# cat /etc/sudoers.d/svc-system-config-user
jeff ALL=(ALL) ALL


My coworker, Andrew, offers the following advice: "The last line of /etc/sudoers is a directive to read "drop-in" files from the /etc/sudoers.d directory. You can still edit /etc/sudoers. It may better to leave svc-system-config-user alone and create another drop-in file for local edits. If you want to edit sudoers as part of an application install then you should create a drop-in for the application - this makes the edits easy to undo if you remove the application. If you have multiple drop-ins in /etc/sudoers.d they are processed in alphabetical (sorted) order.  There are restrictions on file names and permissions for drop-ins. The permissions must be 440 (read only for owner and group) and the file name can't have a dot or ~ in it. These are in the very long man page."



Wednesday May 22, 2013

Debugging Hadoop using Solaris Studio in a Solaris 11 Zone


I've found Orgad Kimchi's How to Set Up a Hadoop Cluster Using Oracle Solaris Zones to be very useful, however, for a development environment, it is too complex. When map/reduce tasks are running in a clustered environment, it is challenging to isolate bugs. Debugging is easier when working within a standalone Hadoop installation. I've put the following instructions together for installation of a standalone Hadoop configuration in a Solaris Zone with Solaris Studio for application development.

A lovely feature of Solaris is that your global zone may host both a Hadoop cluster set up in a manner similar to Orgad's instructions and simultaneously host a zone for development that is running a Hadoop standalone configuration.

Create the Zone

These instructions assume that Solaris 11.1 is already running in the Global Zone.

Add the Hadoop Studio Zone

# dladm create-vnic -l net0 hadoop_studio

# zonecfg -z 
hadoop-studio
Use 'create' to begin configuring a new zone.
zonecfg:
hadoop-studio> create
create: Using system default template 'SYSdefault'
zonecfg:
hadoop-studio> set zonepath=/ZONES/hadoop-studio
zonecfg:
hadoop-studio> add net
zonecfg:
hadoop-studio:net> set physical=hadoop_studio
zonecfg:
hadoop-studio:net> end
zonecfg:
hadoop-studio> verify
zonecfg:
hadoop-studio> commit
zonecfg:
hadoop-studio> exit


Install and boot the zone

# zoneadm -z hadoop-studio install
# zoneadm -z 
hadoop-studio boot

Login to the zone console to set the network, time, root password, and unprivileged user.

# zlogin -C hadoop-studio

After the zone's initial configuration steps, nothing else needs to be done from within the global zone. You should be able to log into the Hadoop Studio zone with ssh as the unprivileged user and gain privileges with "su" and "sudo".

All of the remaining instructions are from inside the Hadoop Studio Zone.


Install extra Solaris software and set up the development environment

I like to start with both JDK's installed and not rely on the "/usr/java" symbolic link:

# pkg install  jdk-6
# pkg install --accept jdk-7


Verify the JDKs:

# /usr/jdk/instances/jdk1.6.0/bin/java -version
java version "1.6.0_35"
Java(TM) SE Runtime Environment (build 1.6.0_35-b10)
Java HotSpot(TM) Server VM (build 20.10-b01, mixed mode)

# /usr/jdk/instances/jdk1.7.0/bin/java -version
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) Server VM (build 23.3-b01, mixed mode)


Add VNC Remote Desktop software

# pkg install --accept solaris-desktop


Create a Hadoop user:

# groupadd hadoop
# useradd -d localhost:/export/home/hadoop -m -g hadoop hadoop
# passwd hadoop
# usermod -R root hadoop


Edit /home/hadoop/.bashrc:

export PATH=/usr/bin:/usr/sbin
export PAGER="/usr/bin/less -ins"
typeset +x PS1="\u@\h:\w\\$ "

# Hadoop
export HADOOP_PREFIX=/home/hadoop/hadoop
export PATH=$HADOOP_PREFIX/bin:$PATH

# Java
export JAVA_HOME=/usr/jdk/instances/jdk1.6.0
export PATH=$JAVA_HOME/bin:$PATH

# Studio
export PATH=$PATH:/opt/solarisstudio12.3/bin
alias solstudio='solstudio --jdkhome /usr/jdk/instances/jdk1.6.0'

Edit /home/hadoop/.bash_profile:

. ~/.bashrc

And make sure that the ownership and permission make sense:

# ls -l /home/hadoop/.bash*      
-rw-r--r--   1 hadoop   hadoop        12 May 22 05:24 /home/hadoop/.bash_profile
-rw-r--r--   1 hadoop   hadoop       372 May 22 05:24 /home/hadoop/.bashrc


Now is a good time to a start remote VNC desktop for this zone:

# su - hadoop

$ vncserver


You will require a password to access your desktops.

Password:
Verify:
xauth:  file /home/hadoop/.Xauthority does not exist

New '
hadoop-studio:1 ()' desktop is hadoop-studio:1

Creating default startup script /home/hadoop/.vnc/xstartup
Starting applications specified in /home/hadoop/.vnc/xstartup
Log file is /home/hadoop/.vnc/
hadoop-studio:1.log

Access the remote desktop with your favorite VNC client

The default 10 minute time out on the VNC desktop is too fast for my preferences:

System -> Preferences -> Screensaver
  Display Modes:
  Blank after: 100
  Close the window (I always look for a "save" button, but no, just close the window without explicitly saving.)



Download and Install Hadoop

For this article, I used the "12 October, 2012 Release 1.0.4" release. Download the Hadoop tarball and copy it into the home directory of hadoop:

$ ls -l hadoop-1.0.4.tar.gz
-rw-r--r--   1 hadoop   hadoop   62793050 May 21 12:03 hadoop-1.0.4.tar.gz

Unpack the tarball into the home directory of the hadoop user:

$ gzip -dc hadoop-1.0.4.tar.gz  | tar -xvf -
$ mv hadoop-1.0.4 hadoop


Hadoop comes pre-configured in Standalone Mode

Edit /home/hadoop/hadoop/conf/hadoop-env.sh, and set JAVA_HOME:

export JAVA_HOME=/usr/jdk/instances/jdk1.6.0

That is all. Now, you can run a Hadoop example:

$ hadoop jar hadoop/hadoop-examples-1.0.4.jar pi 2 10
Number of Maps  = 2
Samples per Map = 10
Wrote input for Map #0
Wrote input for Map #1
Starting Job
...
Job Finished in 10.359 seconds
Estimated value of Pi is 3.80000000000000000000



Install Solaris Studio:

Visit https://pkg-register.oracle.com/ to obtain Oracle_Solaris_Studio_Support.key.pem, Oracle_Solaris_Studio_Support.certificate.pem and follow the instructions for "pkg set-publisher" and "pkg update" or "pkg install"

# sudo pkg set-publisher \
          -k /var/pkg/ssl/Oracle_Solaris_Studio_Support.key.pem \
          -c /var/pkg/ssl/Oracle_Solaris_Studio_Support.certificate.pem \
          -G '*' -g https://pkg.oracle.com/solarisstudio/support solarisstudio

# pkg install developer/solarisstudio-123/*


If your network requires a proxy, you will need set the proxy before starting Solaris Studio:

proxy.jpg


Start Solaris Studio:

$ solstudio

(Notice the alias in .bashrc that adds --jdkhome to the solstudio start up command.)

Go to "Tools -> Plugins.

Click on "Reload Catalog"

Load the Java SE plugins. I ran into a problem when the Maven plug in was installed. Something that I should diagnose at a future date.

plugins.jpg



Create a New Project:

File -> New Project

Step 1:
- Catagory: Java
- Project: Java Application
- Next

NewProject.jpg

Step 2: Fill in similar to this:

NewJavaApplication.jpg

Copy the example source into the project:

$ cp -r \
    $HADOOP_PREFIX/src/examples/org/apache/hadoop/examples/* \
    ~/SolStudioProjects/examples/src/org/apache/hadoop/examples/


Starting to look like a development environment:

DevEnvironment.jpg


Modify the Project to compile with Hadoop jars. Right-click on the project and select "Properties"

properties.jpg


Add in the necessary Hadoop compile jars:

CompileJars.jpg

I found that I needed these jars at run time:

RunJars.jpg

Add Program Arguments (2 10):

Arguments.jpg

Now, if you click on the "Run" button. PiEstimators will run inside the IDE:

PiRuns.jpg

And the set up behaves as expected if you set a break point and click on "Debug":

debug.jpg

Tuesday May 21, 2013

non-interactive zone configuration

When creating new Solaris zones, at initial boot up, the system administrator is prompted for the new hostname, network settings, etc of the new zone. I get tired of the brittle process of manually entering the initial settings and I prefer to be able to automate the process. I had previously figured out the process for Solaris 10, but I've only recently figured out the process for Solaris 11.



As a review, with Solaris 10, use your favorite editor to create a sysidcfg file:

system_locale=C
terminal=dtterm
security_policy=NONE
network_interface=primary {
                hostname=app-41
}
name_service=DNS {
    domain_name=us.mycorp.com
    name_server=232.23.233.33,154.45.155.15,77.88.21.211
    search=us.mycorp.com,yourcorp.com,thecorp.com
}
nfs4_domain=dynamic
timezone=US/Pacific
root_password=xOV2PpE67YUzY


1) Solaris 10 Install: Using sysidcfg to avoid answering the configuration questions in a newly installed zone:

After the "zoneadm -z app-41 install" you can copy the sysidcfg file to "/ZONES/app-41/root/etc/sysidcfg"  (assuming your "zonepath" is "/ZONES/app-41") and the initial boot process will read the settings from the file and not prompt the system administrator to manually enter the settings.

2) Solaris 10 Clone: Using sysidcfg when cloning the zone 

I used a similar trick on Solaris 10 when cloning old zone "app-41 to new zone "app-44":

#  zonecfg -z app-41 export | sed -e 's/app-41/app-44/g' | zonecfg -z app-44
#  zoneadm -z app-44 clone app-41
#  cat
/ZONES/app-41/root/etc/sysidcfg | sed -e 's/app-41/app-44/g' > /ZONES/app-44/root/etc/sysidcfg
#  zoneadm -z app-44 boot




With Solaris 11, instead of a small human readable file which will containing the configuration information, the information is contained in an XML file that would be difficult to create using an editor. Instead, create the initial profile by executing "sysconfig":

# sysconfig create-profile -o sc_profile.xml
# mkdir /root/profiles/app-61
# mv sc_profile.xml /root/profiles/app-6
1/sc_profile.xml

The new XML format is longer so I won't include it in this blog entry and it is left as an exercise for the reader to review the file that has been created.

1) Solaris 11 Install

# dladm create-vnic -l net0 app_61

# zonecfg -z app-61
Use 'create' to begin configuring a new zone.
zonecfg:p3231-zone61> create
create: Using system default template 'SYSdefault'
zonecfg:app-61> set zonepath=/ZONES/app-61
zonecfg:app-61> add net
zonecfg:app-61:net> set physical=app_61
zonecfg:app-61:net> end
zonecfg:app-61> verify
zonecfg:app-61> commit
zonecfg:app-61> exit

# zoneadm -z app-61 install -c /root/profiles/app-61
# zoneadm -z app-61 boot
# zlogin -C app-61


2) Solaris 11 Clone: If you want to clone app-61 to app-62 and have an existing sc_profile.xml, you can re-use most of the settings and only adjust what has changed:


# dladm create-vnic -l net0 app_62

# zoneadm -z app-61 halt

# mkdir /root/profiles/app-62

# sed \
-e 's/app-61/app-62/g' \
-e 's/app_61/app_62/g' \
-e 's/11.22.33.61/11.22.33.62/g' \
< /root/profiles/app-61/sc_profile.xml \
> /root/profiles/app-62/sc_profile.xml

# zonecfg -z app-61 export | sed -e 's/61/62/g' | zonecfg -z app-62

# zoneadm -z app-62 clone -c /root/profiles/app-62 app-61
# zoneadm -z app-62 boot
# zlogin -C app-62

I hope this trick saves you some time and makes your process less brittle.


Thursday May 16, 2013

Hadoop Java Error logs

I was having trouble isolating a problem with "reduce" tasks running on Hadoop slave servers. 

After poking around on the Hadoop slave, I found an interesting lead in /var/log/hadoop/userlogs/job_201302111641_0057/attempt_201302111641_0057_r_000001_1/stdout:

$ cat /tmp/hadoop-hadoop/mapred/local/userlogs/job_201302111641_0059/attempt_201302111641_0059_r_000001_1/stdout

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfe67cb31, pid=25828, tid=2
#
# JRE version: 6.0_35-b10
# Java VM: Java HotSpot(TM) Server VM (20.10-b01 mixed mode solaris-x86 )
# Problematic frame:
# C  [libc.so.1+0xbcb31]  pthread_mutex_trylock+0x29
#
# An error report file with more information is saved as:
# /tmp/hadoop-hadoop/mapred/local/taskTracker/hadoop/jobcache/job_201302111641_0059/attempt_201302111641_0059_r_000001_1/work/hs_err_pid25828.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.

The HotSpot crash log (hs_err_pid25828.log in my case) will be very interesting because it contains information obtained at the time of the fatal error, including the following information, where possible:

  • The operating exception or signal that provoked the fatal error
  • Version and configuration information
  • Details on the thread that provoked the fatal error and thread's stack trace
  • The list of running threads and their state
  • Summary information about the heap
  • The list of native libraries loaded
  • Command line arguments
  • Environment variables
  • Details about the operating system and CPU

Great, but hs_err_pid25654.log had been cleaned up before I could get to it. In fact, I found that the hs_err_pid.log files were available for less than a minute and they were always gone before I could capture one.

To try to retain the Java error log file, my first incorrect guess was:

 <property>
   <name>keep.failed.task.files</name>
   <value>true</value>
 </property>


My next approach was to add "-XX:ErrorFile=/tmp/hs_err_pid%p.log" to the Java command line for the reduce task.

When I tried adding the Java option to HADOOP_OPTS in /usr/local/hadoop/conf/hadoop-env.sh, I realized that this setting isn't applied to the Map and Reduce Task JVMs.

Finally, I found that adding the Java option to the mapred.child.java.opts property in mapred-site.xml WORKED!!

$ cat /usr/local/hadoop/conf/mapred-site.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- Put site-specific property overrides in this file. -->

<configuration>

     <property>
         <name>mapred.job.tracker</name>
         <value>p3231-name-node:8021</value>
     </property>

     <property>
         <name>mapred.child.java.opts</name>
         <value>-XX:ErrorFile=/tmp/hs_err_pid%p.log</value>
     </property>


</configuration>


Now I can view the Java error logs on my Hadoop slaves:

$ ls -l /tmp/*err*
-rw-r--r--   1 hadoop   hadoop     15626 May 16 15:42 /tmp/hs_err_pid10028.log
-rw-r--r--   1 hadoop   hadoop     15795 May 16 15:43 /tmp/hs_err_pid10232.log

About

user12620111

Search

Archives
« May 2013 »
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
23
24
25
26
27
29
30
31
 
       
Today