Re: [Freeipa-devel] Instructions to build ipa under RHEL

2016-03-29 Thread Rob Crittenden

Lukas Slebodnik wrote:

On (29/03/16 10:16), Oleg Fayans wrote:

Hi team,

Is there any kind of $subj available? Like, which repos to enable, etc.
I'm raising the topic because I was unable to install a number of
build-time dependencies to build the official 4.3.1 packages under
RHEL-7.2 (I need freeipa-4.3.1 srpms to build ipa-tests package):

awk '/BuildRequires/ {print $2}' freeipa.spec.in  | xargs yum install -y
| grep "No package"

It's naive approach for installation of build dependencies
which ignore rpm conditions "%if (0%{?rhel} >= 7)"

Please you right tools in future yum-builddep.


This may have been based on the top-level BUILD file in the freeipa 
source. Perhaps that should be updated.



No package 389-ds-base-devel available.
No package svrcore-devel available.
No package samba-devel available.
No package libwbclient-devel available.
No package libtalloc-devel available.
No package libtevent-devel available.
No package xmlrpc-c-devel available.
No package python-gssapi available.
No package pylint available.
No package python-polib available.
No package libsss_idmap-devel available.
No package libsss_nss_idmap-devel available.
No package libunistring-devel available.
No package python-lesscpy available.
No package python-pytest-multihost available.
No package python-pytest-sourceorder available.
No package python-jwcrypto available.
No package custodia available.
No package libini_config-devel available.

Most of devel packages are in optional repositories.


No package python3-devel available.

python3 is not available in rhel7 and never will be.


No package libcmocka-devel available.
No package nss_wrapper available.


These dependencies are optional and required only
on fedora.


They are required by the spec he is using.

rob

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Instructions to build ipa under RHEL

2016-03-29 Thread Lukas Slebodnik
On (29/03/16 10:16), Oleg Fayans wrote:
>Hi team,
>
>Is there any kind of $subj available? Like, which repos to enable, etc.
>I'm raising the topic because I was unable to install a number of
>build-time dependencies to build the official 4.3.1 packages under
>RHEL-7.2 (I need freeipa-4.3.1 srpms to build ipa-tests package):
>
>awk '/BuildRequires/ {print $2}' freeipa.spec.in  | xargs yum install -y
>| grep "No package"
It's naive approach for installation of build dependencies
which ignore rpm conditions "%if (0%{?rhel} >= 7)"

Please you right tools in future yum-builddep.

>No package 389-ds-base-devel available.
>No package svrcore-devel available.
>No package samba-devel available.
>No package libwbclient-devel available.
>No package libtalloc-devel available.
>No package libtevent-devel available.
>No package xmlrpc-c-devel available.
>No package python-gssapi available.
>No package pylint available.
>No package python-polib available.
>No package libsss_idmap-devel available.
>No package libsss_nss_idmap-devel available.
>No package libunistring-devel available.
>No package python-lesscpy available.
>No package python-pytest-multihost available.
>No package python-pytest-sourceorder available.
>No package python-jwcrypto available.
>No package custodia available.
>No package libini_config-devel available.
Most of devel packages are in optional repositories.

>No package python3-devel available.
python3 is not available in rhel7 and never will be.

>No package libcmocka-devel available.
>No package nss_wrapper available.
>
These dependencies are optional and required only
on fedora.

LS

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] [PATCH] 0009 webui: Show certificates in useful format

2016-03-29 Thread Pavel Vomacka



On 03/16/2016 06:56 PM, Petr Vobornik wrote:

On 03/15/2016 01:23 PM, Pavel Vomacka wrote:

Hello,

patch for https://fedorahosted.org/freeipa/ticket/5311 is attached.

--
Pavel^3 Vomacka



Not tested, but can we avoid using  s with "white-space: pre" and 
therefore use only IPA.cert.pem_cert_format(text).


Also, it should be displayed in monospaced, so probably add:

.certificate-widget .certificate {
font-family: monospace;
overflow-x: auto;
white-space: pre;
}

Fixed.



Probably as a separate patch or ticket: we can add "download" button 
which would offer the certificate in form of data uri[1] with 
'download' attribute of 'a' element [2]. So user will get pem encoded 
file without any hassle.


[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/data_URIs
[2] https://developer.mozilla.org/en/docs/Web/HTML/Element/a
The download button is really good idea. There is attached another patch 
which adds this button. If we need new ticket let me know and I will 
file it.


--
Pavel^3 Vomacka
>From d50fcd65531efa56b17cd8e63e1be518cf3fbcba Mon Sep 17 00:00:00 2001
From: Pavel Vomacka 
Date: Tue, 15 Mar 2016 11:51:35 +0100
Subject: [PATCH] Show certificate in useful format

Certificates are shown in PEM format which includes BEGIN and END CERTIFICATE string
and all lines are wrapped at 64 characters.

https://fedorahosted.org/freeipa/ticket/5311
---
 install/ui/ipa.css| 8 
 install/ui/src/freeipa/certificate.js | 3 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/install/ui/ipa.css b/install/ui/ipa.css
index f419eb224252aa03eaf4b25bb03435f4c9a6de9b..a1910560641d703557b06cd7ce8efa73296950d4 100644
--- a/install/ui/ipa.css
+++ b/install/ui/ipa.css
@@ -555,3 +555,11 @@ table.scrollable tbody {
 font-weight: bold;
 font-size: 1.1em;
 }
+
+/* --- Certificates --- */
+
+.certificate-widget .certificate {
+font-family: monospace;
+overflow-x: auto;
+white-space: pre;
+}
diff --git a/install/ui/src/freeipa/certificate.js b/install/ui/src/freeipa/certificate.js
index ae05ebb3d45974cd1df50c16e19d0ab9fd27a19b..670bc3b0902bc87b1a6fbcb6e34d23ed8fa31b8d 100755
--- a/install/ui/src/freeipa/certificate.js
+++ b/install/ui/src/freeipa/certificate.js
@@ -1056,9 +1056,10 @@ IPA.cert.cert_widget = function(spec) {
 
 if (l && that.certs_visible) {
 for (var i=0; iFrom ca9e0eaf930ac9d5344404fd0737fd1876477513 Mon Sep 17 00:00:00 2001
From: Pavel Vomacka 
Date: Tue, 29 Mar 2016 11:24:50 +0200
Subject: [PATCH] Add download button for certificates

Add button for each certificate which allows user to download certificate to PEM
formatted file.

https://fedorahosted.org/freeipa/ticket/5311
---
 install/ui/ipa.css|  5 +
 install/ui/src/freeipa/certificate.js | 19 ++-
 install/ui/test/data/ipa_init.json|  2 ++
 ipalib/plugins/internal.py|  2 ++
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/install/ui/ipa.css b/install/ui/ipa.css
index a1910560641d703557b06cd7ce8efa73296950d4..99a09132a7e81493316ce790f3a5c31fcd1d8bee 100644
--- a/install/ui/ipa.css
+++ b/install/ui/ipa.css
@@ -563,3 +563,8 @@ table.scrollable tbody {
 overflow-x: auto;
 white-space: pre;
 }
+
+.certificate-widget .certificate a {
+font-family: 'Open Sans', Helvetica, Arial, sans-serif;
+float: right;
+}
diff --git a/install/ui/src/freeipa/certificate.js b/install/ui/src/freeipa/certificate.js
index 670bc3b0902bc87b1a6fbcb6e34d23ed8fa31b8d..8edbba5d800dae075282a27191119d3881961bb9 100755
--- a/install/ui/src/freeipa/certificate.js
+++ b/install/ui/src/freeipa/certificate.js
@@ -1049,6 +1049,13 @@ IPA.cert.cert_widget = function(spec) {
 return status;
 };
 
+that.create_data_uri = function(cert) {
+var format = 'data:,';
+var uri_new_line = '%0A';
+
+return format + cert.replace(/\n/g, uri_new_line);
+};
+
 that.create_certs = function() {
 
 that.content_el.empty();
@@ -1057,10 +1064,20 @@ IPA.cert.cert_widget = function(spec) {
 if (l && that.certs_visible) {
 for (var i=0; i

Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Jan Pazdziora
On Tue, Mar 29, 2016 at 11:21:05AM +0200, Lukáš Hellebrandt wrote:
> 
> Right, we only have to deal with path as the protocol is already in HBAC
> rules.

I don't see protocol in HBAC rules -- there are HBAC (~ PAM) service
name and canonical hostname of the machine. But there isn't protocol
(scheme) there, there isn't service host name there, and there isn't
port there.

Can you please show (here or in the design page) how you envision
the situation

https://www.redhat.com/archives/freeipa-devel/2016-March/msg00462.html

would be modeled?

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Jan Pazdziora
On Tue, Mar 29, 2016 at 10:59:13AM +0200, Lukáš Hellebrandt wrote:
> 
> No change compared to how it works now: if the public part doesn't
> require any authorization at all, the application won't even ask for
> authorization.

In other words, it won't be possible to enable unauthenticated access
centrally (in IPA)?

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 02:39 PM, Rob Crittenden wrote:
> Adam Young wrote:
>> On 03/24/2016 05:43 AM, Jan Pazdziora wrote:
>>> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
 I created a design page for the feature:

 http://www.freeipa.org/page/URI-based-HBAC-design
>>> I try to put separate areas of concerns into separate emails to make
>>> it easy to keep track.
>>>
>>> The document says
>>>
>>> There is a new field in HBAC rule details for adding URI PCRE
>>> as plain text.
>>>
>>> We need an easy way for the user to enter multiple URLs for the same
>>> rule. The primary case is obviously the http / https duality
>>>
>>> http://www.example.com/
>>> https://www.example.com/
>>
>> Yes, let's split up the Hostname and the URI matching into two entities.
> 
> I wasn't entirely clear when I brought this up. The design is a little
> fuzzy whether the previous HBAC elements are all required but
> potentially we _already_ have the hostname that this applies to. I think
> dealing with just the path would be much more straightforward. Of course
> that doesn't take into account virtual hosts/SNI, so maybe host is
> relevant after all.
> 

Right, we only have to deal with path as the protocol is already in HBAC
rules.


-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Jan Pazdziora
On Tue, Mar 29, 2016 at 10:50:08AM +0200, Lukáš Hellebrandt wrote:
> > 
> > The benefit of this approach is that if you need to evaluate access
> > to say
> > 
> > /application/data/
> > 
> > and you already have rule for
> > 
> > /application/   [ users/ ]
> > 
> > cached either in SSSD or in the application (Apache module), you know
> > you don't have to refetch additional rules because if they existed,
> > their existence would be noted in the sub-URL "exclusion" list.
> > 
> > You will achieve similar functionality to what you propose with the
> > regular expression approach, except the computers will do the work
> > of keeping things in sync, not users.
> 
> This solution would, effectively, mean DENY rules. Without them, adding

Well, yes, but addressing the inherent problem of DENY rules, which is
"if you miss the record for the DENY rule", you will go with the ALLOW
rule. Because every ALLOW rule would have the automatically-maintained
list of "excludes" or "scope limits", if you see the ALLOW rule, you
will know that it does not apply to what it shouldn't apply to.

> "/application/users/admin/" wouldn't change anything as the first rule
> would allow "/application/users/.*" and the added rule would explicitly
> allow "/application/users/admin/.*", changing nothing.

My proposal is for IPA to do automatically the housekeeping,
maintaining the information about

/application/users/admin/

existence in the "parent" rule (/application/users/).

> Furthermore, in some cases you might, for example, allow access to any
> user except users starting with "admin_", which is a problem if there is

How do you proposed to do that? You'd have to have a user group.

> unknown or infinite or large number of those users. Regular expressions
> seem to be more powerful.

More powerful: certainly. But your proposal also makes them much more
complex and dangerous to use, if you want to be able to address
typical Web applications and their layout.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 01:41 PM, Jan Pazdziora wrote:
> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
>> I created a design page for the feature:
>>
>> http://www.freeipa.org/page/URI-based-HBAC-design
> 
> Could you please elaborate on unauthenticated accesses?
> 
> Many web applications have completely public parts, and then
> authenticated sections, with more restricted access to subsections
> underneath. How do you envision configuration to look like, and how
> will the (missing) user identity be handled in that case?
> 

No change compared to how it works now: if the public part doesn't
require any authorization at all, the application won't even ask for
authorization.

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 01:31 PM, Jan Pazdziora wrote:
> On Wed, Mar 23, 2016 at 06:39:45PM +0100, Petr Vobornik wrote:
>> On 03/23/2016 04:41 PM, Lukáš Hellebrandt wrote:
>>> I created a design page for the feature:
>>>
>>> http://www.freeipa.org/page/URI-based-HBAC-design
>>
>> 1. The design page doesn't mention if mod_authnz_pam will be extended or
>> some new 'pam_sss' Apache module will be created. Or is it actually
>> mod_hbacauthz_pam as said in 'how to test'?
> 
> If PAM is used and pam_sss is extended to accept the URL in PAM
> environment for pam_acct_mgmt, I'd expect patch would be proposed
> against mod_authnz_pam.
> 
> If that turns out not to be a viable option, using SSSD's D-Bus
> interface might the way to go, in which case it would likely be new
> module, something like mod_authz_sssd.
> 

I have created my own Apache module serving just for this purpose
(mod_hbacauthz_pam), but extending mod_authnz_pam is a matter of minutes
and I will likely do that, too.

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 10:31 AM, Jan Pazdziora wrote:
> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
>> I created a design page for the feature:
>>
>> http://www.freeipa.org/page/URI-based-HBAC-design
> 
> In the document, you say
> 
>   In all of them [ approaches ], I use only the part of URI
>   after hostname as hostname and service are already matched
>   as part of selecting HBAC rules to evaluate in terms of
>   matching URI. 
> 
> This is not correct.
> 
> The hostname of the machine may be
> 
>   cloud-123-567.example.com
> 
> The service (principal) might be HTTP/cloud-123-567.example.com.
> 
> The HBAC service (== PAM service) might be 'application', or 'httpd'.
> 
> But the URL might be
> 
>   http://wiki.example.com/wiki
> 
> or
> 
>   https://issues.example.com/
> 
> or
> 
>   http://www.example.com:8080/
> 
> Distinct applications and content, with completely distinct URLs,
> locations, and security requirements, hosted on the same machine and
> under the same HBAC service.
> 
> The full URL needs to be taken into account. There can be situations
> like
> 
>   http:///wiki
> 
> where the hostname is ommitted in the rule but it has to be an
> explicit decision of the user (admin) editing the rules, not something
> built into the mechanism.
> 

Actually, admin can specify whatever he wants in URI attribute. The only
question here is what the application should send. So this is merely a
matter of the Apache module in my case.

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] URI in HBAC - design page

2016-03-29 Thread Lukáš Hellebrandt
On 03/24/2016 10:24 AM, Jan Pazdziora wrote:
> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
>> I created a design page for the feature:
>>
>> http://www.freeipa.org/page/URI-based-HBAC-design
> 
> The way most web applications (that I see as the first use for this
> feature) are structured, they have more openly accessible areas at
> "top" URLs like
> 
>   /application/
> 
> which might have unrestricted access, with authenticated or otherwise
> narrowed access underneath, like
> 
>   /application/users/
> 
> with yet more restricted areas in sub-URLs, for example
> 
>   /application/users/admin/
> 
> Since obviously allow rule for /application/users/ would match access
> to /application/users/admin/ as well and we don't want that, there
> needs to be a way to "override" the /application/users/ rule with
> a more specific one.
> 
> You present two solutions to the problem -- deny rules, and regular
> expressions.
> 
> Having to use
> 
>   ^/application/users/(?!admin/).*
> 
> rule to make sure it does not match /application/users/admin/ means
> that when you add
> 
>   /application/users/helpdesk/
> 
> you will not only have to edit that rule, but also amend the
> 
>   ^/application/users/(?!admin/).*
> 
> rule and add helpdesk there. That will be extremely volatile and
> error-prone if you have dozens of sub-locations that require
> separate, more restrictive access. Users cannot be expected to keep
> these separate rules in sync.
> 
> My preferred solution would be to treat the URL as left prefix, and
> maintain for each URL/rule list of/links to sub-URLs/sub-rules for
> which the URL/rule no longer applies.
> 
> So when you have rule for
> 
>   /application/users/
> 
> and add rule for
> 
>   /application/users/admin/
> 
> the first one gets automatically amended to be
> 
>   /application/users/ [ admin/ ]
> 
> And when you add
> 
>   /application/
> 
> it will automatically get
> 
>   /application/   [ users/ ]
> 
> because there is already a rule that limits the scope.
> 
> The benefit of this approach is that if you need to evaluate access
> to say
> 
>   /application/data/
> 
> and you already have rule for
> 
>   /application/   [ users/ ]
> 
> cached either in SSSD or in the application (Apache module), you know
> you don't have to refetch additional rules because if they existed,
> their existence would be noted in the sub-URL "exclusion" list.
> 
> You will achieve similar functionality to what you propose with the
> regular expression approach, except the computers will do the work
> of keeping things in sync, not users.
> 

This solution would, effectively, mean DENY rules. Without them, adding
"/application/users/admin/" wouldn't change anything as the first rule
would allow "/application/users/.*" and the added rule would explicitly
allow "/application/users/admin/.*", changing nothing.

Furthermore, in some cases you might, for example, allow access to any
user except users starting with "admin_", which is a problem if there is
unknown or infinite or large number of those users. Regular expressions
seem to be more powerful.

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Instructions to build ipa under RHEL

2016-03-29 Thread Oleg Fayans
Petr, Martin, thanks guys!

On 03/29/2016 10:37 AM, Petr Vobornik wrote:
> On 03/29/2016 10:16 AM, Oleg Fayans wrote:
>> Hi team,
>>
>> Is there any kind of $subj available? Like, which repos to enable, etc.
>> I'm raising the topic because I was unable to install a number of
>> build-time dependencies to build the official 4.3.1 packages under
>> RHEL-7.2 (I need freeipa-4.3.1 srpms to build ipa-tests package):
>>
>> awk '/BuildRequires/ {print $2}' freeipa.spec.in  | xargs yum install -y
>> | grep "No package"
>> No package 389-ds-base-devel available.
>> No package svrcore-devel available.
>> No package samba-devel available.
>> No package libwbclient-devel available.
>> No package libtalloc-devel available.
>> No package libtevent-devel available.
>> No package xmlrpc-c-devel available.
>> No package python-gssapi available.
>> No package pylint available.
>> No package python-polib available.
>> No package libsss_idmap-devel available.
>> No package libsss_nss_idmap-devel available.
>> No package libunistring-devel available.
>> No package python-lesscpy available.
>> No package python-pytest-multihost available.
>> No package python-pytest-sourceorder available.
>> No package python-jwcrypto available.
>> No package custodia available.
>> No package libini_config-devel available.
>> No package libcmocka-devel available.
>> No package nss_wrapper available.
>> No package python3-devel available.
>>
>> This leads to quite expected failure to build srpms.
>>
> 
> Some of the packages are not in RHEL 7.2. It's the usual case with
> FreeIPA major version newer than the one in latest RHEL.
> 
> Usually if some version of FreeIPA is rebased in RHEL then the
> dependencies are also included.
> 
> This gap could be solved, e.g., by COPR repositoris - the official one
> for 4.3 is:  @freeipa/freeipa-4-3-centos7
> 
> Martin Babinsky is working on including 4.3.1 also with the test package
> there - progress can be viewed at:
> https://copr.fedorainfracloud.org/coprs/mbabinsk/freeipa-4-3-centos-7/builds/
> 

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Instructions to build ipa under RHEL

2016-03-29 Thread Martin Babinsky

On 03/29/2016 10:33 AM, Oleg Fayans wrote:

OK, I enabled the following repo:
http://cosmos.lab.eng.pnq.redhat.com/idmqe-extras/rhel/7Server/x86_64/
and that gave me:
pylint
python-polib
python-pytest-multihost
python-pytest-sourceorder

But the rest is still unavailable

On 03/29/2016 10:16 AM, Oleg Fayans wrote:

Hi team,

Is there any kind of $subj available? Like, which repos to enable, etc.
I'm raising the topic because I was unable to install a number of
build-time dependencies to build the official 4.3.1 packages under
RHEL-7.2 (I need freeipa-4.3.1 srpms to build ipa-tests package):

awk '/BuildRequires/ {print $2}' freeipa.spec.in  | xargs yum install -y
| grep "No package"
No package 389-ds-base-devel available.
No package svrcore-devel available.
No package samba-devel available.
No package libwbclient-devel available.
No package libtalloc-devel available.
No package libtevent-devel available.
No package xmlrpc-c-devel available.
No package python-gssapi available.
No package pylint available.
No package python-polib available.
No package libsss_idmap-devel available.
No package libsss_nss_idmap-devel available.
No package libunistring-devel available.
No package python-lesscpy available.
No package python-pytest-multihost available.
No package python-pytest-sourceorder available.
No package python-jwcrypto available.
No package custodia available.
No package libini_config-devel available.
No package libcmocka-devel available.
No package nss_wrapper available.
No package python3-devel available.

This leads to quite expected failure to build srpms.




Hi Oleg,

If you can wait for a day or two I will push 4.3.1 to our Centos copr 
repo, you should be able to install 4.3.1 on RHEL from there.


--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Instructions to build ipa under RHEL

2016-03-29 Thread Petr Vobornik

On 03/29/2016 10:16 AM, Oleg Fayans wrote:

Hi team,

Is there any kind of $subj available? Like, which repos to enable, etc.
I'm raising the topic because I was unable to install a number of
build-time dependencies to build the official 4.3.1 packages under
RHEL-7.2 (I need freeipa-4.3.1 srpms to build ipa-tests package):

awk '/BuildRequires/ {print $2}' freeipa.spec.in  | xargs yum install -y
| grep "No package"
No package 389-ds-base-devel available.
No package svrcore-devel available.
No package samba-devel available.
No package libwbclient-devel available.
No package libtalloc-devel available.
No package libtevent-devel available.
No package xmlrpc-c-devel available.
No package python-gssapi available.
No package pylint available.
No package python-polib available.
No package libsss_idmap-devel available.
No package libsss_nss_idmap-devel available.
No package libunistring-devel available.
No package python-lesscpy available.
No package python-pytest-multihost available.
No package python-pytest-sourceorder available.
No package python-jwcrypto available.
No package custodia available.
No package libini_config-devel available.
No package libcmocka-devel available.
No package nss_wrapper available.
No package python3-devel available.

This leads to quite expected failure to build srpms.



Some of the packages are not in RHEL 7.2. It's the usual case with 
FreeIPA major version newer than the one in latest RHEL.


Usually if some version of FreeIPA is rebased in RHEL then the 
dependencies are also included.


This gap could be solved, e.g., by COPR repositoris - the official one 
for 4.3 is:  @freeipa/freeipa-4-3-centos7


Martin Babinsky is working on including 4.3.1 also with the test package 
there - progress can be viewed at: 
https://copr.fedorainfracloud.org/coprs/mbabinsk/freeipa-4-3-centos-7/builds/

--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Instructions to build ipa under RHEL

2016-03-29 Thread Oleg Fayans
OK, I enabled the following repo:
http://cosmos.lab.eng.pnq.redhat.com/idmqe-extras/rhel/7Server/x86_64/
and that gave me:
pylint
python-polib
python-pytest-multihost
python-pytest-sourceorder

But the rest is still unavailable

On 03/29/2016 10:16 AM, Oleg Fayans wrote:
> Hi team,
> 
> Is there any kind of $subj available? Like, which repos to enable, etc.
> I'm raising the topic because I was unable to install a number of
> build-time dependencies to build the official 4.3.1 packages under
> RHEL-7.2 (I need freeipa-4.3.1 srpms to build ipa-tests package):
> 
> awk '/BuildRequires/ {print $2}' freeipa.spec.in  | xargs yum install -y
> | grep "No package"
> No package 389-ds-base-devel available.
> No package svrcore-devel available.
> No package samba-devel available.
> No package libwbclient-devel available.
> No package libtalloc-devel available.
> No package libtevent-devel available.
> No package xmlrpc-c-devel available.
> No package python-gssapi available.
> No package pylint available.
> No package python-polib available.
> No package libsss_idmap-devel available.
> No package libsss_nss_idmap-devel available.
> No package libunistring-devel available.
> No package python-lesscpy available.
> No package python-pytest-multihost available.
> No package python-pytest-sourceorder available.
> No package python-jwcrypto available.
> No package custodia available.
> No package libini_config-devel available.
> No package libcmocka-devel available.
> No package nss_wrapper available.
> No package python3-devel available.
> 
> This leads to quite expected failure to build srpms.
> 

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


[Freeipa-devel] Instructions to build ipa under RHEL

2016-03-29 Thread Oleg Fayans
Hi team,

Is there any kind of $subj available? Like, which repos to enable, etc.
I'm raising the topic because I was unable to install a number of
build-time dependencies to build the official 4.3.1 packages under
RHEL-7.2 (I need freeipa-4.3.1 srpms to build ipa-tests package):

awk '/BuildRequires/ {print $2}' freeipa.spec.in  | xargs yum install -y
| grep "No package"
No package 389-ds-base-devel available.
No package svrcore-devel available.
No package samba-devel available.
No package libwbclient-devel available.
No package libtalloc-devel available.
No package libtevent-devel available.
No package xmlrpc-c-devel available.
No package python-gssapi available.
No package pylint available.
No package python-polib available.
No package libsss_idmap-devel available.
No package libsss_nss_idmap-devel available.
No package libunistring-devel available.
No package python-lesscpy available.
No package python-pytest-multihost available.
No package python-pytest-sourceorder available.
No package python-jwcrypto available.
No package custodia available.
No package libini_config-devel available.
No package libcmocka-devel available.
No package nss_wrapper available.
No package python3-devel available.

This leads to quite expected failure to build srpms.

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code