Grouper Users - Open Discussion List

["Black, Carey M." <>]

Maybe a "better middle ground" would be to provide a standard way to extract 
such information from the image/running process?
        That way the project could automate that process and would not 
require "constant documentation updates" per release.
        The versions would be automatically kept current as the project 
naturally upgrades and moves forward with the tools.
        The recent move to maven as a build process should provide a good 
hook for the Java libs/dependencies too.

Maybe a page under "Miscellaneous" could list all the things and their 
versions in the image?
    By reading a CSV that is packaged up during the build process? ( nothing 
in the DB, just a "manifest" of the image.)


And on the deployer side, they would need to know what the are using in the 
container too. 
   Example: If you are not using the shibboleth sp in the container, then 
that info does not apply/matter to you. 
   Example: If you are not using the Apache in the container, then that info 
does not apply/matter to you.

-- 
Carey Matthew 

-----Original Message-----
From:  
<> On Behalf Of Baron Fujimoto
Sent: Saturday, July 4, 2020 3:21 PM
To: Hyzer, Chris <>
Cc: Grouper Users <>
Subject: Re: [grouper-users] containerized grouper noob questions

I can't speak for others, but I think having this sort of version manifest 
listed separately in the release notes would be helpful for us, thanks!

On Fri, Jul 03, 2020 at 07:25:54PM +0000, Hyzer, Chris wrote:
>we could list this on the release notes page if you like so its easy to see, 
>but yeah, right now you would have to go in and look.  if you wanted to 
>maintain that in subimage you could yum update the java, and you could unzip 
>the latest 7.0.* tomee.  ok?
>
>thanks
>Chris
>________________________________
>From: Baron Fujimoto <>
>Sent: Friday, July 3, 2020 1:27 PM
>To: Hyzer, Chris <>
>Cc: Grouper Users <>
>Subject: Re: [grouper-users] containerized grouper noob questions
>
>On Fri, Jul 03, 2020 at 06:25:23AM +0000, Hyzer, Chris wrote:
>>>
>>> As I understand it on a really high level, the container is a collection 
>>> of all of the
>>> components that Grouper will need. With out current deployment, we 
>>> independently manage
>>> those components, such as Tomcat and Java. A significant part of managing 
>>> those components
>>> is tracking their versions, particularly with an eye towards relevant bug 
>>> and security
>>> patches. How do we do we identify and track these versions with the 
>>> Grouper containers?
>>
>>1. If there is an issue that is not addressed in a container, tell me about 
>>it and we can make a new container
>>2. -or- you can make a subimage that upgrades or replaces part of the 
>>container
>>
>>As soon as 2.5.30 is released (which is delayed since its substantial, and 
>>should be out in the next week or two), we will go back to release 
>>approximately every other week
>>
>>> I think I understand that any such patches get incorporated into new 
>>> container versions,
>>> but how do we perform the risk assessment for currently deployed 
>>> containers? Generally I'm
>>> trying to determine how we respond to our security groups when they come 
>>> asking about vulnerabilities.
>>
>>Was this answered in the above answer?  Its similar to what you would do 
>>today I would think...  if you want a schedule for upgrades, then you need 
>>to make a new image on that schedule I think
>
>Not quite I'm afraid. I mean, currently, as new vulnerabilities are 
>disclosed in say Java or Tomcat, there's typicaly some way to perform a risk 
>assessment for your deployments based on the version #s and other 
>supplementantary information they provide. But how do you determine what 
>versions of these components are included in the Grouper containers (say, 
>short of looking for logged information on startup or something like that)? 
>Or perhaps non-securitywise, some features or configuration options may only 
>be available for certain versions of Tomcat for example.
>
>>> Is there a difference between the TIER/ITAP(?) containers and those 
>>> available via the
>>> Grouper site? My cursory Googling seems to turn up Grouper 2.4 associated 
>>> with TIER,
>>> but the Grouper site features 2.5? I'm a little unclear on the 
>>> relationship.
>>
>>Theres one container for Grouper.  Anything else is for training or 
>>integration POCs and is a subimage of the Grouper container...
>>
>>Good luck!
>
>--
>UH Information Technology Services : Identity & Access Mgmt, Middleware
>minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

-- 
UH Information Technology Services : Identity & Access Mgmt, Middleware
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum