Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 36

Thread: Issues with OpenSolaris installation

  1. #11

    Default

    Quote Originally Posted by dustin View Post
    Nick -- Thanks again! We'll need to integrate these two packages, then.

    if you can post what you have to github or a similar service so that everyone can browse it, that would be even better than emailing tarballs. We're trying to do more development "in the open"

    [url]http://wiki.zmanda.com/index.php/Fork_Amanda_on_Github[/url] or, less preferably, send the tarball to me and I'll post it to my git repo.
    OK, I've got to admit being a little befuddled by Git. I cloned your repository, but when I browse it, I don't see the packaging/sun-pkg directory. And, I sometimes get different results (sun-pkg directory there or not there) depending on how I get there. Any idea what I need to do to make my clone have the change set I need?

  2. #12
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    Git can be a bit confusing, as can GitHub

    It looks like you've cloned the repository correctly -- I see the desired branch at
    [url]http://github.com/duckhead/amanda/tree/sun-pkg[/url]

    You should be able to clone that:
    git clone git://github.com/duckhead/amanda.git
    then 'cd amanda' and get a local branch copied from the remote branch with
    git co -b sun-pkg origin/sun-pkg
    A 'git log' should show you the "preliminary sun packaging materials" commit.

  3. #13

    Default

    Ahh, it's in a branch. I still can't figure out how I am supposed to know that. And, I promise the sun-pkg directory wasn't showing on my clone webpage earlier, I checked that way too many times.

    In any event, I've got my changes completed and tested out. It's not perfect, I really really want to review Nick's changes first. But, it builds better than before, and has some of the OpenSolaris cleaning done. I need to switch the server build script to build in your preferred directories, and then I'll start trying to check this in and push the changeset.

    Jason

  4. #14
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    sounds great!

    FWIW, everything's in a branch in git -- the default branch name is "master", but it's no different than any other branch.

    To be honest, I didn't make it very clear, though, by just posting in the URL. I should have said that it's in my github repository in the "sun-pkg" branch.

  5. #15

    Default git commits

    OK, I've got my first changeset ready to commit. Basically, this is just a script cleanup. It should be fine on any Solaris box. It does things like turn of debugging on the script, turns off verbose on the tarball extraction, exits if the configure or make fails, actually defines a log file. Silly stuff like that.

    I don't have anything other that OpenSolaris to test one, so feel free to give it a whirl.

    According to the github directions, all I should need to do is to run a "git push origin master", but that reports back that everything is up-to-date, and it doesn't show my changes when I rerun a git diff. Am I in trouble with branches again?

  6. #16
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    Let's see -- have you committed your changes locally yet? Git can be confusing because it tends to operate with a lot of repositories. In your case, there are three: your local repository on your machine, your github repository (duckhead/amanda), and my github repository (djmitche/amanda). The steps to pushing a change are:

    1. commit the change locally
    git commit -m "Script cleanup. It should be fine on any Solaris box. It does things like turn of debugging on the script, turns off verbose on the tarball extraction, exits if the configure or make fails, actually defines a log file. Silly stuff like that."

    2. push that to the sun-pkg branch on your github account (the "origin" remote)
    git push origin sun-pkg

    If you've already done all of that, and it didn't work, let me know what 'git status' and 'git log -2' show you. I'm also in #amanda on freenode if you'd like to work it out quickly. Thanks for your patience

  7. #17

    Default

    Ahh github docs don't mention the local repository piece. It's making more better sense now. This learning curve is silly. If you had svn, cvs, rcs, or PVCS I'd have been in like flynn.

    I've sent you the first changeset for your review. It does not contain any of the OpenSolaris fixes yet. This should continue to work on the older Solarii, but do so in a more responsible fashion. When that's done, and we get the bugs hashed out, we can do the OpenSolaris bits. That way, all Solarii get the benefits of the normal fixes.

  8. #18

    Default

    I've got my changes ready to to upload onto github but it's going to take me a while to work out how to use it!

    Therefore here is a ZIP of my changes for people to look at.

    What's done and what's not done.

    Done.

    1. SMF manifest for amanda/udp service
    2. Updating /etc/inet/services
    3. Creating a default $AMANDAHOME/.amandahosts file
    4. Creating the 'amanda' user (value taken from --amanda-user)
    5. Generating the package version
    6. Adding of ZFS privileges

    Not done

    1. Creating SSH / Kerberos keys etc
    2. Much more
    3. Server side package prototype and configuration

    Regards,

    Nick
    Attached Files Attached Files

  9. #19
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    Thanks, Nick! For the moment I put your changes on github:
    [url]http://github.com/djmitche/amanda/commit/bb7313c1454bdb22f9c039d4eb52359c21e66158[/url]

    Most of this is over my head, but two questions jump out at me. First, does it make sense to take values from configure, rather than set constant defaults directly in the packaging scripts? At the end of this process, I would like Zmanda to start running these scripts and providing binaries for download, just like we do for RPMs, etc., and if the content of those packages depends on how we choose to run ./configure, then it is not immediately obvious to others how to rebuild the package identically.

    Second, in *.manifest, I see
    3 # Copyright 2004 Sun Microsystems, Inc. All rights reserved.
    4 # Use is subject to license terms.
    what are the implications of including this in the Amanda source?

    Now .. how do your changes and duckhead's changes get along together?

  10. #20

    Default

    Quote Originally Posted by dustin View Post
    Thanks, Nick! For the moment I put your changes on github:
    [url]http://github.com/djmitche/amanda/commit/bb7313c1454bdb22f9c039d4eb52359c21e66158[/url]

    Most of this is over my head, but two questions jump out at me. First, does it make sense to take values from configure, rather than set constant defaults directly in the packaging scripts? At the end of this process, I would like Zmanda to start running these scripts and providing binaries for download, just like we do for RPMs, etc., and if the content of those packages depends on how we choose to run ./configure, then it is not immediately obvious to others how to rebuild the package identically.
    My thinking was that the default build script would call configure with the default parameters from Zmanda to build the package, build it and then finally package it. Then if the package build has special requiremnts for pre-configuring the client package for instance then they can call configure directly and still be able to create a package.

    Quote Originally Posted by dustin View Post
    Second, in *.manifest, I see
    3 # Copyright 2004 Sun Microsystems, Inc. All rights reserved.
    4 # Use is subject to license terms.
    what are the implications of including this in the Amanda source?

    Now .. how do your changes and duckhead's changes get along together?
    I didn't spot the Copyright! Can someone more knowledgable in this area give any input? The [i,r].manifest files could be read from their default /usr/sadm/install/scripts location on [Open]Solaris so that they are not as such included in the Amanda source only in the pre-built binaries (would this help?).

    I'll have to check duckhead's changes before I can comment on the compatibility.

    Regards,

    Nick

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •