Running pkg server as regular user

I wanted to run the pkg server a regular user, to be able to publish into the repository via the file protocol without giving the user any extra privileges. It turned to be quite easy to achieve:

Export the current configuration to a file:

svccfg export pkg/server > pkg.xml 

Modify the file so that it looks like the below example. I added the <method_context> and modified the inst_root property. Also the port has to be > 1024 to be usable by ordinary user.

<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<service_bundle type='manifest' name='export'>
  <service name='application/pkg/server' type='service' version='0'>
    <create_default_instance enabled='true'/>
    <dependency name='fs' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/system/filesystem/local'/>
    </dependency>
    <dependency name='autofs' grouping='optional_all' restart_on='none' type='service'>
      <service_fmri value='svc:/system/filesystem/autofs'/>
    </dependency>
    <dependency name='ntp' grouping='optional_all' restart_on='none' type='service'>
      <service_fmri value='svc:/network/ntp'/>
    </dependency>
    <dependency name='network' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/milestone/network'/>
    </dependency>
    <exec_method name='start' type='method' exec='%{pkg/pkg_root}/lib/svc/method/svc-pkg-depot %m' timeout_seconds='0'>
    <method_context>
        <method_credential
        user='test'
        group='staff' />
    </method_context>
    </exec_method>
    <exec_method name='stop' type='method' exec='%{pkg/pkg_root}/lib/svc/method/svc-pkg-depot %m %{restarter/contract}' timeout_seconds='30'/>
    <property_group name='pkg' type='application'>
      <propval name='cfg_file' type='astring' value=''/>
      <propval name='content_root' type='astring' value='usr/share/lib/pkg'/>
      <propval name='debug' type='astring' value=''/>
      <propval name='log_access' type='astring' value='none'/>
      <propval name='log_errors' type='astring' value='stderr'/>
      <propval name='mirror' type='boolean' value='false'/>
      <propval name='pkg_root' type='astring' value='/'/>
      <propval name='proxy_base' type='astring' value=''/>
      <propval name='readonly' type='boolean' value='false'/>
      <propval name='socket_timeout' type='count' value='60'/>
      <propval name='sort_file_max_size' type='astring' value=''/>
      <propval name='ssl_cert_file' type='astring' value='none'/>
      <propval name='ssl_dialog' type='astring' value='smf'/>
      <propval name='ssl_key_file' type='astring' value='none'/>
      <propval name='threads' type='count' value='10'/>
      <propval name='writable_root' type='astring' value=''/>
      <propval name='port' type='count' value='10000'/>
      <propval name='inst_root' type='astring' value='/export/home/test/repo'/>
    </property_group>
    <property_group name='pkg_secure' type='application'>
      <property name='read_authorization' type='astring'/>
      <property name='ssl_key_passphrase' type='astring'/>
    </property_group>
    <property_group name='startd' type='framework'>
      <propval name='duration' type='astring' value='child'/>
    </property_group>
    <stability value='Unstable'/>
    <template>
      <common_name>
        <loctext xml:lang='C'>image packaging repository</loctext>
      </common_name>
    </template>
  </service>
</service_bundle>

And import the settings back:

svccfg import pkg.xml

Do not forget to make the service log file writable for the user, otherwise the pkg server will not start:

pfexec chown test /var/svc/log/application-pkg-server:default.log

Refreshing the file list in kde-solaris

Often when we upgrade a package or change something in the build process (e.g. recently we started putting the debug information into separate files), the build fails because either some files are missing or new files appear or both.
In the log something like this is found:


pkgbuild: ## Validating control scripts.
pkgbuild: ## Packaging complete.
pkgbuild: error: Installed (but unpackaged) file(s) found:
pkgbuild:         /opt/foss/bin/amd64/imginfo.debug
pkgbuild:         /opt/foss/bin/amd64/tmrdemo.debug
pkgbuild:         /opt/foss/bin/amd64/imgcmp.debug
pkgbuild:         /opt/foss/bin/amd64/jasper.debug
pkgbuild:         /opt/foss/bin/jasper.debug
pkgbuild:         /opt/foss/bin/tmrdemo.debug
pkgbuild:         /opt/foss/bin/imgcmp.debug
pkgbuild:         /opt/foss/bin/imginfo.debug
pkgbuild:         /opt/foss/lib/libjasper.so.1.0.0.debug
pkgbuild:         /opt/foss/lib/amd64/libjasper.so.1.0.0.debug
pkgbuild: pkgbuild: FOSSjasper.spec(118): Installed (but unpackaged) file(s) found
--- command output ends --- finished at Wed Mar 17 03:44:06 CET 2010


Fixing the file list manually can lead to errors and is time-consuming, so it's easier to use the scripts available in the repository:
First, the file names are extracted from the log:

perl tools/extract-plist.pl < ~/logs/FOSSxz.log |sort -u> a

And then a new plist is constructed:

perl tools/extract-plist-2.pl <  a 

Of course you can join them into a oneliner:

perl tools/extract-plist.pl < ~/logs/FOSSxz.log |sort -u|perl tools/extract-plist-2.pl

Copying a zone

I wanted to play a bit with the KDE4 build flags and I needed a playground. The idea I had was to use a copy of the existing KDE build zone, so as to save time configuring it and downloading all the dependencies.

Well, I have to admit I sort of failed in this one ...

zoneadm clone wasn't really an option as I need to have freedom creating and destroying snapshots on both zones. zoneadm clone -m copy probably never worked.
I spent a lot of time with zfs send|zfs receive, esp. with the idea of

# /usr/sbin/zfs snapshot -r tank/zones/build@1move
# /usr/sbin/zfs send tank/zones/build/ROOT/zbe@1move > build.backup
# zfs create tank/zones/debugbuild
# zonecfg -z debugbuild
zonecfg:debugbuild> export
create -b                                                               
set zonepath=/tank/zones/debugbuild                                
set brand=ipkg                                                          
set autoboot=true                                                       
set ip-type=shared                                                      
add fs                                                                  
set dir=/home                                                           
set special=/export/home                                                
set type=lofs                                                           
end                                                                     
add net                                                                 
set address=10.10.2.44                                                  
set physical=e1000g0                                                    
end

# cat build.backup|zoneadm -z debugbuild attach  -r zfs

but it never worked. I spent hours trying, looking into the scripts in /usr/lib/brand/ipkg/, but it was probabaly not meant to be working anyway.

So in the end I hacked it like this:

# /usr/sbin/zfs snapshot -r tank/zones/build@1move
# /usr/sbin/zfs send tank/zones/build/ROOT/zbe@1move > build.backup
# zfs create tank/zones/debugbuild
# chmod 700  tank/zones/debugbuild
# zonecfg -z debugbuild 
# zoneadm -z debugbuild install
# cat build.backup| pfexec /usr/sbin/zfs receive -F tank/zones/debugbuild/ROOT/zbe@1test
# zoneadm -z debugbuild boot

Not really a clean way, since I had to waste some extra bandwidth and time, but a working one.

KDE 4.4.1 on OpenSolaris

A screenshot of KDE 4.4.1 running on OpenSolaris b132. Some things still crash, but we're definitely improving. 

Welcome to the ghetto

One week after the renewed (and reinforced) train station shelters were put in place and we're in a ghetto again.
The yellow rectangle in the middle is the timetable - wisely put to the place of least interest of the grafitti heroes. It stayed there about two more days ...

Breaching a patent

I came across a post on cnet linking to my ooooold blog post on silecing the mouse clicks. The interesting stuff is that the post also linked a patent that is covering the same issue albeit with a slightly different approach.

So was I breaching the patent? Would I be if I started producing silenced rodents? I don't know, there's just too many things to consider
1) Is the patent same as my hack? To me it looks like there are big-enough differences
2) I published it before the patent was published, but after it was filed. How does it work in such cases?
3) Fortunately, I'm not US citizen (the patent was filed in the USA). However there are international treaties regarding IP, so who knows ...

Was the hack worth commecializing?
Quick googling revealed that Gregory Maroun (the guy behind the patent) registered the quietmouse.com domain about the same day he filed the patent application. He was selling the silenced mice for 40-50$ and right now his site states that he's preparing a second generation of the mice that should be out in Spring this year.
So it seems one can do a business around this :-)

Good luck Greg and don't sue me :-)

KDE 4.4.1 on Solaris 10 (Amarok2 included)

Mark Wright and Ben Taylor did enormous amounts of work on porting KDE4 to Solaris 10. About half of the known universe had to be rebuilt, but the result was definitely worth it. Yesterday Mark sent a screenshot of his KDE 4.4.1 session to the mailing list.
As you can see, Amarok2 is there as well - we weren't building it for some time due to the unresolved dependency on MySQL embedded, but fortunately Mark found a workaround.
As of now there are no binary packages available, Ben will probably publish them at some point, although he might need more +1s to motivate him.