1. litmis Avatar litmis
  2. Open Source Projects for IBM i
  3. ibmichroot
  4. Issues

rpm spec and project file reorg

Issue #47 resolved
Aaron Bartell created an issue

I noticed the root README.md still references pkg* stuff. I then realized the chroot/README.md really should be the root README.md.

My questions is if I make the change to git mv everything from chroot/ to the root of the project whether that will cause issues with the rpm spec file for the newly created ibmichroot rpm? Guessing it will, but I also believe this change needs to be made for the sake of final cleanup of the previous approach.

Thoughts @ThePrez @abmusse ?

Comments (24)

  1. Musse

    @aaronbartell Yes I agree that the root README.md change needs to be made.

    There is a PR out right now where I deleted the chroot/README.md and updated the the root README.md.

    There seems to be merge conflict on it currently though. I think it can be resolved by just allowing the deletion of the chroot/README.md.

  2. Jesse G

    Two thoughts from me:

    1) the chroot/README.md is really geared towards advanced users, in my opinion. I would like to keep that content out of the main README.md. The takeaway from the main README should be "this is simple! Create a chroot like so" (and it can link the more advanced README). I don't object to moving everything up a directory, but perhaps chroot/README.md becomes something like README_ADVANCED.md.

    2) It won't cause issues with the RPM spec file. The spec file will need to be updated (only so that the chroot_setup symlink points to the new spot), but we will just create a new .spec file when the new commit is tagged with v2.0.1

  3. Aaron Bartell reporter

    There is a PR out right now where I deleted the chroot/README.md and updated the the root README.md.

    For future things like this it would be better to do git mv so we don't lose the history of a file.

    There seems to be merge conflict on it currently though.

    Shoot, that was because of a change I made. Feel free to delete my changes and I will make them again.

  4. Jesse G

    Also, @abmusse, your PR removes the chroot/README.md, but some of the content there is not replaced or moved to anywhere else. That's advanced stuff that should still stick around somewhere (in my opinion)

  5. Aaron Bartell reporter

    1) the chroot/README.md is really geared towards advanced users, in my opinion. I would like to keep that content out of the main README.md. The takeaway from the main README should be "this is simple! Create a chroot like so" (and it can link the more advanced README). I don't object to moving everything up a directory, but perhaps chroot/README.md becomes something like README_ADVANCED.md.

    Could we just create a # Advanced section at the bottom of the root README.md? In my opinion most of the advanced stuff (i.e. generating lst files) was removed with this PR and now it is more about "extended use" or normal documentation.

  6. Musse

    For future things like this it would be better to do git mv so we don't lose the history of a file.

    @aaronbartell Noted.

    Since the PR is not merged yet we have a chance to consider suggestions from @ThePrez :

    Using chroot/README.md to hold advanced information about the chroot. (contents of the Propsed README.md inside the PR)

    And use the root README.md as a quick example including a link to the chroot/README.md for more detailed info.

    I'm Ok with going this route.

    Thoughts?

  7. Musse

    Could we just create a # Advanced section at the bottom of the root README.md? In my opinion most of the advanced stuff (i.e. generating lst files) was removed with this PR and now it is more about "extended use" or normal documentation.

    I'm also good with going this route.

  8. Aaron Bartell reporter

    I gave my opinion in this post. I am fine with either. More important that we get the repo up to date because right now it isn't in a workable state regarding documentation.

  9. Aaron Bartell reporter

    Ha ha! Hot dog. Bitbucket needs to make these Issue pages more real-time. We're not seeing each other's next posts before we finish responding.

    Anyways, @ThePrez can have the final say this time and I will get my turn on the next one ;-)

  10. Jesse G

    I propose, as a final solution:

    • Add the missing-in-the-PR contents in an # Advanced section
    • git mv the files in the chroot directory up one parent directory
    • When that PR (or PR's) lands, we tag the latest commit with v2.0.1
  12. Musse

    @ThePrez The Missing contents from the old chroot/README are no longer part of this version:

    I Removed the Dynamic Global Variables & the Builders chroot_xxx.lst Sections For the current PR.

    Was there something else I missed?

  14. Musse

    Right. Those features are not included.

    Builders Chroot: The chroot_OPS.lst files may become out of date with IBM i PTFS. Therefore we created a new script 'gen_chroot_OPS_lst' to generate chroot_gen_OPS_xxx.lst files from PTF manifest We ran gen_chroot_OPS_lst tool and updated this project. You may run this utility on your own machine for new IBM PTFs anytime.

    Figured above was no longer need because of YUM we no longer worry about OPS.

  15. Aaron Bartell reporter

    @Musse , are you saying that the new ibmichroot version doesn't support those old features?

    On that note...

    Global parms need to be reinstated.

    I should have noticed this was removed (my bad). @abmusse, please make sure to include removal of features in future PRs. This PR had good detail but didn't include mention that the Global Variable feature was removed.

    Further, the introduction of user interactivity with chroot_setup will cause issues with existing production implementations that expect silent installs. I've created a separate issue for this so it can be tracked.

  16. Musse

    Mainly added interactivity for 2 cases:
    1. When a path was provided for a chroot that already exists. To confirm you want to add a chroot there.
    2. When you call chroot_setup chroot_path w/o chroot types confirming you want to create a minimal w/ includes chroot.

    Both prompts can be chopped easily.

    As for as the global parameters go how should go about implementing it?

    The old way version would ensure that

    $1 = chroot type ie: minimal.lst

    $2 = chroot path

    any other parameters would be considered global variables.

    Now that we can pass multiple chroot types ie:chroot_setup chroot_path minimal includes

    We need a way to specify that the parameter being passed is a global variable and not a chroot type.

    Maybe an option -g or --global followed by the name=value.

    Opinions? @aaronbartell @ThePrez

  17. Aaron Bartell reporter

    Both prompts can be chopped easily.

    I think prompts are good; especially for noobs. And I actually think we'll probably have more prompts in the future. But they need to be able to be silenced for scenarios where chroot_setup is being used in "batch" mode (automation without sys admin intervention).

    Maybe an option -g or --global followed by the name=value.

    That sounds like a great approach to me. It actually cleans up the existing feature by having it called out with an option vs. assuming.

    Also, it's worth going the whole 9yards on making this right because I do believe we'll have many more shell scripts for PASE admin that we'll be authoring and we can look back at this project for how to do things like options (both short and long form, -g and --global)

  20. Aaron Bartell reporter

    @abmusse, try this one:

    chroot_ssh.lst:

    :chmod
750 /home
750 /home/myuser
700 /home/myuser/.ssh
600 /home/myuser/.ssh/id_rsa
644 /home/myuser/.ssh/id_rsa.pub
644 /home/myuser/.ssh/authorized_keys
700 /home/myuser/.ssh/known_hosts
1777 /tmp

    To test:

    chroot_setup /QOpenSys/c1 /path/chroot_ssh.lst -g myuser=MUSSE
  21. Musse

    I created a few options -y = auto yes -v = vebose -g = globals. if you run chroot_setup -vg myuser=MUSSE /QOpenSys/Ok/ ssh

    One thing to note is that options must be placed at the start of the command: Usage: [OPTIONS] [CHROOT DIRECTORY] [CHROOT TYPE]*

    You get back:

    =====================================
Creating chroot based on chroot_ssh.lst
=====================================
Running Sed for Globals

action = :chmod
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 750 /home"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 750 /home/MUSSE"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 700 /home/MUSSE/.ssh"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 777 /home/MUSSE/.ssh/id_rsa"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 644 /home/MUSSE/.ssh/id_rsa.pub"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 644 /home/MUSSE/.ssh/authorized_keys"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 700 /home/MUSSE/.ssh/known_hosts"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 1777 /tmp"

To enter Your Chroot
RUN: chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/sh


DONE!
  22. Aaron Bartell reporter

    If I needed multiple global variables would it look like this?

    chroot_setup -vg mydir=/QOpenSys/Ok -g myuser=MUSSE /QOpenSys/Ok/ ssh

    Also, it should prompt by default and then automated processes can opt for automated responses when -y is specified (just like yum). I wasn't sure if that's how you currently have it. This is obviously a breaking change, but since other changes were breaking it should be fine (automated scripts need to be touched regardless and now they can just add in the -y option so they can remain automated).

  23. Musse

    right when -y is not specifed you will be prompted but using -y you can skip the prompts. I just skipped showing the prompt in the output.

    Yes we can run multiple -g variables To Test updated the chroot_ssh.lst to be 

    :chmod
750 /home
750 /home/myuser
700 /home/myuser/mydir
777 /home/myuser/mydir/id_rsa
644 /home/myuser/mydir/id_rsa.pub
644 /home/myuser/mydir/authorized_keys
700 /home/myuser/mydir/known_hosts
1777 /tmp

    Yes for example I ran chroot_setup.sh -vg myuser=MUSSE -g mydir=.ssh /QOpenSys/Ok/ ssh

    output is:

    action = :chmod
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 750 /home"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 750 /home/MUSSE"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 700 /home/MUSSE/.ssh"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 777 /home/MUSSE/.ssh/id_rsa"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 644 /home/MUSSE/.ssh/id_rsa.pub"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 644 /home/MUSSE/.ssh/authorized_keys"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 700 /home/MUSSE/.ssh/known_hosts"
chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/bsh -c "chmod 1777 /tmp"

To enter Your Chroot
RUN: chroot /QOpenSys/Ok/ /QOpenSys/usr/bin/sh


DONE!
  25. Log in to comment
Assignee
Type
proposal
Priority
major
Status
resolved
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!