Re: abiword

2016-04-14 Thread Yasha Karant

On 04/14/2016 02:01 PM, R P Herrold wrote:

On Thu, 14 Apr 2016, R P Herrold wrote:


The content is now at:
ftp://ftp.owlriver.com/pub/local/ORC/abiword/
and will move to:
ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/

just got a clean build with RawHide's
abiword-3.0.1-4.orc7.src.rpm

which I have pushed and will appear in 'local'

-- R


This probably will require either EPEL or someone on this list who can 
generate a working binary.  A naive rpmbuild --rebuild yields:


error: Failed build dependencies:
aiksaurus-devel is needed by abiword-1:3.0.1-4.el7.x86_64
aiksaurus-gtk-devel is needed by abiword-1:3.0.1-4.el7.x86_64
asio-devel is needed by abiword-1:3.0.1-4.el7.x86_64
goffice-devel is needed by abiword-1:3.0.1-4.el7.x86_64
gtkmathview-devel is needed by abiword-1:3.0.1-4.el7.x86_64
librevenge-devel is needed by abiword-1:3.0.1-4.el7.x86_64
libwmf-devel is needed by abiword-1:3.0.1-4.el7.x86_64
libwpd-devel is needed by abiword-1:3.0.1-4.el7.x86_64
libwpg-devel is needed by abiword-1:3.0.1-4.el7.x86_64
link-grammar-devel is needed by abiword-1:3.0.1-4.el7.x86_64
loudmouth-devel is needed by abiword-1:3.0.1-4.el7.x86_64
ots-devel is needed by abiword-1:3.0.1-4.el7.x86_64
poppler-devel is needed by abiword-1:3.0.1-4.el7.x86_64
t1lib-devel is needed by abiword-1:3.0.1-4.el7.x86_64
telepathy-glib-devel is needed by abiword-1:3.0.1-4.el7.x86_64
wv-devel is needed by abiword-1:3.0.1-4.el7.x86_64

and when I start with the first failed dependency:

yum install aiksaurus-devel
No package aiksaurus-devel available.
Error: Nothing to do

Hopefully, someone will have both the time (and required effort) to 
build abiword (more or less current) and to be able to
release either a consistent and ready to build set of rpm.src files for 
SL7, etc., or a built binary RPM along with whatever other built
RPMs are required again for SL7. As it appears that there are business 
restrictions that prevent Owlriver from offering any such binaries,
I hope that someone else may -- or EPEL will come through in short 
order. (I was under the impression that a business could offer executable
software without cost for download provided the usual "disclaim all" was 
part of the download and use "license".)   abiword  is available for

 ubuntu http://abiword.en.uptodown.com/ubuntu/download
(not to claim that Ubuntu LTS is somehow better than SL) from at least 
one site on the web .


Yasha Karant


Re: abiword

2016-04-14 Thread R P Herrold
On Thu, 14 Apr 2016, R P Herrold wrote:

> The content is now at: 
>   ftp://ftp.owlriver.com/pub/local/ORC/abiword/ 
> and will move to: 
>   ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ 

just got a clean build with RawHide's 
abiword-3.0.1-4.orc7.src.rpm

which I have pushed and will appear in 'local'

-- R


Re: abiword

2016-04-14 Thread R P Herrold
On Thu, 14 Apr 2016, Yasha Karant wrote:


> Thank you very much for providing the above URLs.
> 
> From the above reference web site, I am guessing that only 
> orc7 (owlriver 7) extension files are needed for SL 7, in 
> which case here is the list of what I have downloaded:

no idea if your guess is right, and checking my binary solve 
environment is not something that is fast or free -- SRPMs are 
offered for what they are.  If the main distribution, or 
something EPEL should happen to 'overtake' and 
displace something in that pile while running a 'yum update 
...'  it would be fine with me, as I strive, but to not test 
that

> Are there other files that are needed other than those 
> provided in the "standard" EL7 public repos?  (I believe 
> that the Red Hat subscriber repos are not readily available 
> to the non-paying, only CentOS repos under the Red Hat 
> "umbrella".)

The Red Hat provided 'git' which CentOS is fed from may be 
used to build SRPMs seemingly without change by the CentOS 
folks
 
> By the way, as a university (not a business), are we allowed 
> to redistribute binary RPMS made from the above .src.rpm 
> files with the usual acknowledgement (thanking you and your 
> firm, but no guarantee that anything works and no guarantee 
> that the binaries will not "destroy" any system upon which 
> these are installed)?  If we do build from your .src.rpm s 
> and things work, why should others have re-invent the wheel 
> and/or redo the labor?

umm -- at the top of the archive:
ftp://ftp.owlriver.com/pub/mirror/ORC/README

(go read -- I'll wait)

I add no non-freely licensed content to the archive at: 
ftp.owlriver.com

all is redistributable save that something might be 
retro-actively found as containing non-free matter.  As I 
don't patrol for that, I would not remove such (There was an 
instance some years ago where an upstream CD respin was 
needed when non-free content was found in (as memory serves) a 
non-free font was found in RHL.  I would miss seeing that]

-- Russ herrold


Re: abiword

2016-04-14 Thread Yasha Karant

On 04/14/2016 12:49 PM, R P Herrold wrote:

On Thu, 14 Apr 2016, R P Herrold wrote:


I have a local solution in a 'scratch build' environment,
yielding: abiword-3.0.1-2.el7.centos.src.rpm.  It 'runs' at
soon, soon

and now done

The content is now at:
ftp://ftp.owlriver.com/pub/local/ORC/abiword/
and will move to:
ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/

Lamar -- could you please pull and build SRPMs out of the
'local' path, and confirm that no gremlins have crept in, via
a cross-check on your buildsystem?  I don't use 'mock' for
scratch solves

Thanks

-- Russ

Thank you very much for providing the above URLs.

From the above reference web site, I am guessing that only orc7 
(owlriver 7) extension
files are needed for SL 7, in which case here is the list of what I have 
downloaded:


abiword-3.0.1-2.orc7.src.rpm
abiword.spec
aiksaurus-1.2.1-33.orc7.src.rpm
aiksaurus.spec
asio-1.4.8-3.orc7.src.rpm
asio.spec
gtkmathview-0.8.0-19.orc7.src.rpm
gtkmathview.spec
librevenge-0.0.2-6.orc7.src.rpm
librevenge.spec
link-grammar-5.0.8-6.orc7.src.rpm
link-grammar.spec
loudmouth-1.4.3-17.orc7.src.rpm
loudmouth.spec
ots-0.5.0-11.orc7.src.rpm
ots.spec
wv-1.2.9-12.orc7.src.rpm
wv.spec

Are there other files that are needed other than those provided in the 
"standard" EL7 public repos?  (I believe that
the Red Hat subscriber repos are not readily available to the 
non-paying, only CentOS repos under the Red Hat "umbrella".)


By the way, as a university (not a business), are we allowed to 
redistribute binary RPMS made from the above .src.rpm files with the
usual acknowledgement (thanking you and your firm, but no guarantee that 
anything works and no guarantee that the binaries will not
"destroy" any system upon which these are installed)?  If we do build 
from your .src.rpm s and things work, why should others have re-invent 
the wheel

and/or redo the labor?

Yasha Karant


Re: abiword

2016-04-14 Thread R P Herrold
On Thu, 14 Apr 2016, R P Herrold wrote:

> I have a local solution in a 'scratch build' environment, 
> yielding: abiword-3.0.1-2.el7.centos.src.rpm.  It 'runs' at 

> soon, soon

and now done

The content is now at: 
ftp://ftp.owlriver.com/pub/local/ORC/abiword/ 
and will move to: 
ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/ 

Lamar -- could you please pull and build SRPMs out of the 
'local' path, and confirm that no gremlins have crept in, via 
a cross-check on your buildsystem?  I don't use 'mock' for 
scratch solves

Thanks

-- Russ


Re: abiword

2016-04-14 Thread R P Herrold
On Thu, 14 Apr 2016, Yasha Karant wrote:

> > so, thus, my earlier mention of poking EPEL

As the day has passed, I 'poked' the EPEL package database

https://admin.fedoraproject.org/pkgdb/package/rpms/abiword/

and as the link Pat noted earlier in the day says, this starts 
a countdown clock to slide the package into eligibility for 
EPEL 7

> Although EPEL "should", being like CentOS these days a 
> more-or-less "wholly owned subsidiary" of Red Hat, but the 
> time it is done we may be at RHEL 8.

only if one does not poke ;)
 
> You indicated that you are willing to release the SRPMs that 
> have already been ported (both for source code and 
> dependencies) to SL 7 and that upon using a command syntax 
> like:

... snip snip

package building has many paths for solution -- At this state 
of the art, the one EPEL uses with 'mock' and 'koji' and 
signing and bugzilla and more is mature and worth using, in 
deference to local solutions

I have a local solution in a 'scratch build' environment, 
yielding: abiword-3.0.1-2.el7.centos.src.rpm.  It 'runs' at 
least to the extent of showing the Help | About dialog [1].  I 
have it rebuilding 'for external record' and in about an hour 
MY version of the SRPM will be up at my FTP site.  I know it 
pulls out some Pythonic API and 'gir' parts.  As I don't use 
them, I don't care about ripping them out


According to 'RawHide', Fedora and so EPEL should be at:

$ srcfind abiword | grep -i rawhide
 ... 
/var/ftp/pub/nfs/mirror/redhat/rawhide2016/a/abiword-3.0.1-4.fc23.src.rpm

with some minor changes in the Changelog after the point I 
forked from: 

* Sat May 02 2015 Kalev Lember  - 
1:3.0.1-4
- Rebuilt for GCC 5 C++11 ABI change

* Thu Mar 26 2015 Richard Hughes  - 
1:3.0.1-3
- Add an AppData file for the software center

* Tue Jan 27 2015 Petr Machata  - 
1:3.0.1-2
- Rebuild for boost 1.57.0

* Wed Dec 24 2014 Peter Robinson 
 1:3.0.1-1
- Update to 3.0.1 stable

soon, soon

-- Russ herrold

1. http://gallery.herrold.com/stuff/abiword-3.0.1.png


Re: abiword

2016-04-14 Thread Yasha Karant

On 04/14/2016 11:22 AM, R P Herrold wrote:

On Thu, 14 Apr 2016, Yasha Karant wrote:


I don't and haven't 'publish' binaries for a long time now,

Although you evidently are not a "repo", are you willing to
allow others access to the built RPMs (not SRPMs) needed for
an executable install of abiword? The RPMs I have are all
2.x, nothing in 3.x .  Are there any "conflicts" between
what is needed by a more recent abiword and the standard
install (from SL/CentOS, EPEL, ElRepo repos)?  That is,
package M conflicts with whatever during the binary install?

Long ago and far away, with the pre-cursor product to CentOS
(cAos), I built and released binaries.  With the turn-down of
RHL, and the rise of the 'Enterprise' distributions, I spent
some time considering 'policy' as to releasing sources vs.
binaries, and concluded that there were obligations to 'stand
behind' binaries, which did not arise with a simple set of
related sources.  Unless one is a commercial customer of Owl
River, binaries are not available ( contrariwise, all binaries
installed at any customer are backed by availability of
sources at the site previously indicated, thus satisfying GPL
and related 'source availability' obligations )

so, thus, my earlier mention of poking EPEL


I could attempt to put personnel (grad students, undergrads)
on the build, but I really do have higher priority work for
these persons.  I myself do not have the spare time right
now to contribute much to the porting effort of a standard
"office enduser" package.

And wonderfully, in the FOSS ethic, EPEL should solve this for
all of us with any luck

-- Russ herrold
Although EPEL "should", being like CentOS these days a more-or-less 
"wholly owned

subsidiary" of Red Hat, but the time it is done we may be at RHEL 8.

You indicated that you are willing to release the SRPMs that have 
already been ported (both for source

code and dependencies) to SL 7 and that upon using a command syntax like:

rpmbuild --rebuild /tmp/mypackage-1.0.0-1.src.rpm

where  .src.rpm is the same as .srpm (as I recall).

will result in a (set) of binary RPM files that will install application 
"binaries" that will execute under SL7.  Any dependencies (e.g., other 
development
packages, not just header file RPMs, but ".so" file RPMs) will be 
revealed by the rpmbuild step and can be "fixed" through
yum install foobar (where foobar is the dependency) from either SL, 
EPEL, or ElRepo, not RPMs for which one has the
merry chase on the web (sometimes resulting in other incompatibilities 
or real vulnerabilities).  I am not trying to be overly specific here, 
but my
group (as I am certain have others on this list) has more than once had 
to chase down RPM dependencies (e.g., libraries) that only were made
at one laboratory somewhere -- and never made it into the "mainstream" 
EL repos (say ported from some other Linux family).


Thanks for any clarification.

Yasha Karant


Re: abiword

2016-04-14 Thread R P Herrold
On Thu, 14 Apr 2016, Yasha Karant wrote:

> > I don't and haven't 'publish' binaries for a long time now,

> Although you evidently are not a "repo", are you willing to 
> allow others access to the built RPMs (not SRPMs) needed for 
> an executable install of abiword? The RPMs I have are all 
> 2.x, nothing in 3.x .  Are there any "conflicts" between 
> what is needed by a more recent abiword and the standard 
> install (from SL/CentOS, EPEL, ElRepo repos)?  That is, 
> package M conflicts with whatever during the binary install?

Long ago and far away, with the pre-cursor product to CentOS 
(cAos), I built and released binaries.  With the turn-down of 
RHL, and the rise of the 'Enterprise' distributions, I spent 
some time considering 'policy' as to releasing sources vs. 
binaries, and concluded that there were obligations to 'stand 
behind' binaries, which did not arise with a simple set of 
related sources.  Unless one is a commercial customer of Owl 
River, binaries are not available ( contrariwise, all binaries 
installed at any customer are backed by availability of 
sources at the site previously indicated, thus satisfying GPL 
and related 'source availability' obligations )

so, thus, my earlier mention of poking EPEL

> I could attempt to put personnel (grad students, undergrads) 
> on the build, but I really do have higher priority work for 
> these persons.  I myself do not have the spare time right 
> now to contribute much to the porting effort of a standard 
> "office enduser" package.

And wonderfully, in the FOSS ethic, EPEL should solve this for 
all of us with any luck

-- Russ herrold


Re: abiword

2016-04-14 Thread Yasha Karant

On 04/14/2016 08:28 AM, R P Herrold wrote:

On Thu, 14 Apr 2016, R P Herrold wrote:


I'll poke at it today

and with an older abiword-3.0.1-1 spec I have been working
with, I get a complete build save for:

abiword-3.0.1/plugins/openxml/imp/xp/OXML_LangToScriptConverter.gperf

and
abiword-3.0.1-1.el7.centos.x86_64/usr/lib64/girepository-1.0/Abi-3.0.typelib

... the RPM build turn cycle is slow as there are so many
moving parts, but looking good

I don't and haven't 'publish' binaries for a long time now,
and have a day's delay between 'inside' local content, and
formal mirrored content ... looking, it appears I've been
doing this package for over a decade (it is also my preferred
'Word' format file editing tool, and I have large corpus of
content in such form).  Gnumeric is the other I rely on, to
avoid the LibreOffice trap

but SRPMs end up with a day's delay at:
ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/

-- Russ herrold
Although you evidently are not a "repo", are you willing to allow others 
access to the
built RPMs (not SRPMs) needed for an executable install of abiword? The 
RPMs I have are all 2.x,
nothing in 3.x .  Are there any "conflicts" between what is needed by a 
more recent abiword
and the standard install (from SL/CentOS, EPEL, ElRepo repos)?  That is, 
package M conflicts with whatever

during the binary install?

I could attempt to put personnel (grad students, undergrads) on the 
build, but I really do have higher priority work for
these persons.   I myself do not have the spare time right now to 
contribute much to the  porting effort of a standard

"office enduser" package.

Yasha Karant


Re: abiword

2016-04-14 Thread R P Herrold
On Thu, 14 Apr 2016, R P Herrold wrote:

> I'll poke at it today

and with an older abiword-3.0.1-1 spec I have been working 
with, I get a complete build save for:

abiword-3.0.1/plugins/openxml/imp/xp/OXML_LangToScriptConverter.gperf

and 
abiword-3.0.1-1.el7.centos.x86_64/usr/lib64/girepository-1.0/Abi-3.0.typelib

... the RPM build turn cycle is slow as there are so many 
moving parts, but looking good

I don't and haven't 'publish' binaries for a long time now, 
and have a day's delay between 'inside' local content, and 
formal mirrored content ... looking, it appears I've been 
doing this package for over a decade (it is also my preferred 
'Word' format file editing tool, and I have large corpus of 
content in such form).  Gnumeric is the other I rely on, to 
avoid the LibreOffice trap

but SRPMs end up with a day's delay at:
ftp://ftp.owlriver.com/pub/mirror/ORC/abiword/

-- Russ herrold


Re: [SCIENTIFIC-LINUX-USERS] abiword

2016-04-14 Thread Pat Riehecky

On 04/14/2016 09:26 AM, Lamar Owen wrote:

On 04/14/2016 10:08 AM, Pat Riehecky wrote:


On 04/14/2016 12:27 AM, Lamar Owen wrote:
Not sure how difficult that will be to get those packages (and the 
packages the -devel packages depend upon) built.  I have a client 
who is waiting on a CentOS 7-compatible Abiword to migrate to CentOS 
7 from CentOS 6, and Abiword is a blocker.


Has there been a request for an EPEL7 branch?




I don't know, but I would support such a thing.  It is currently 
supported in F23, so it appears to be actively maintained (but I am 
not an EPEL insider).




These links should probably get you started:

https://fedoraproject.org/wiki/EPEL/FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Pat


Re: abiword

2016-04-14 Thread R P Herrold
On Thu, 14 Apr 2016, R P Herrold wrote:

> looks like libasio -- sounds like a task for EPEL devel ML

actually I got a build there as well, with only a minimal 
rpmlint snark

/home/herrold/rpmbuild/SRPMS/asio-1.4.8-3.orc7.src.rpm
/home/herrold/rpmbuild/RPMS/x86_64/asio-devel-1.4.8-3.orc7.x86_64.rpm

made a local: asio-1.4.8-3.orc7.src.rpm
CWD: /home/herrold/build/7/abiword 

CWD: /tmp/rph-rpmbuild.rpmlint.lJ6q
BAS_NEWSR: asio-1.4.8-3.orc7.src.rpm 
asio.src: E: specfile-error warning: bogus date in %changelog: 
Tue Aug  3 2011 Peter Robinson  -  1.4.8-1
1 packages and 0 specfiles checked; 1 errors, 0 warnings.

I'll poke at it today

-- Russ herrold


Re: sci-l-u] Re: abiword

2016-04-14 Thread R P Herrold
On Thu, 14 Apr 2016, Lamar Owen wrote:

> Several of abiword's buildrequires are not in the various EL7 repos.  There
> aren't very many of them; in attempting to rebuild the FC22 Abiword and
> attempting to install the buildreqs I get:
> No package aiksaurus-devel available.
> No package aiksaurus-gtk-devel available.
> No package gtkmathview-devel available.
> No package link-grammar-devel available.
> No package loudmouth-devel available.
> No package ots-devel available.
> No package wv-devel available.
> 
> Not sure how difficult that will be to get those packages (and the packages
> the -devel packages depend upon) built.  I have a client who is waiting on a
> CentOS 7-compatible Abiword to migrate to CentOS 7 from CentOS 6, and Abiword
> is a blocker.

I made a run at it a while back -- most of that list build, 
but there was some blocker ... memory fades

[herrold@centos-7 abiword]$ date ; rpm -q wv ots loudmouth 
link-grammar libwpd librevenge libmspack libasyncns hspell 
gtkmathview aiksaurus asio cabextract fribidi enchant 
centos-release
Thu Apr 14 10:43:18 EDT 2016
wv-1.2.9-12.orc7.x86_64
ots-0.5.0-11.orc7.x86_64
loudmouth-1.4.3-17.orc7.x86_64
link-grammar-5.0.8-6.orc7.x86_64
libwpd-0.10.0-1.el7.x86_64
librevenge-0.0.2-6.orc7.x86_64
libmspack-0.5-0.4.alpha.el7.x86_64
libasyncns-0.8-7.el7.x86_64
hspell-1.2-6.el7.x86_64
gtkmathview-0.8.0-19.orc7.x86_64
aiksaurus-1.2.1-33.orc7.x86_64
package asio is not installed
cabextract-1.5-1.el7.x86_64
fribidi-0.19.4-6.el7.x86_64
enchant-1.6.0-8.el7.x86_64
centos-release-7-2.1511.el7.centos.2.10.x86_64
[herrold@centos-7 abiword]$ 

looks like libasio -- so8nds like a task for EPEL devel ML

-- Russ herrold


Re: [SCIENTIFIC-LINUX-USERS] abiword

2016-04-14 Thread Lamar Owen

On 04/14/2016 10:08 AM, Pat Riehecky wrote:


On 04/14/2016 12:27 AM, Lamar Owen wrote:
Not sure how difficult that will be to get those packages (and the 
packages the -devel packages depend upon) built.  I have a client who 
is waiting on a CentOS 7-compatible Abiword to migrate to CentOS 7 
from CentOS 6, and Abiword is a blocker.


Has there been a request for an EPEL7 branch?




I don't know, but I would support such a thing.  It is currently 
supported in F23, so it appears to be actively maintained (but I am not 
an EPEL insider).


Re: [SCIENTIFIC-LINUX-USERS] abiword

2016-04-14 Thread Pat Riehecky

On 04/14/2016 12:27 AM, Lamar Owen wrote:

On 04/11/2016 07:02 AM, Yasha Karant wrote:
Is there any EL7 rpm or other successful build of a recent stable 
release of abiword?  If so, what is URL to download the build 
including whatever other rpms are required (or a large
static image that does not require any .so components that are not 
part of the standard SL 7 repo)?


Yasha Karant

Several of abiword's buildrequires are not in the various EL7 repos.  
There aren't very many of them; in attempting to rebuild the FC22 
Abiword and attempting to install the buildreqs I get:

No package aiksaurus-devel available.
No package aiksaurus-gtk-devel available.
No package gtkmathview-devel available.
No package link-grammar-devel available.
No package loudmouth-devel available.
No package ots-devel available.
No package wv-devel available.

Not sure how difficult that will be to get those packages (and the 
packages the -devel packages depend upon) built.  I have a client who 
is waiting on a CentOS 7-compatible Abiword to migrate to CentOS 7 
from CentOS 6, and Abiword is a blocker.


Has there been a request for an EPEL7 branch?

Pat


Re: Samba update killed my servers

2016-04-14 Thread Shane Voss

Anyone else have horrific issues with this update??


For some years we have been relying on using DNS CNAMEs to find our servers.
It seems this is effectively the bug that has just been fixed.

In simple terms, it seems that you must have a service principal name (SPN) 
that matches the name of the file server the user requested.  Effectively the 
server needs to be registered under all the names it could be called.


(This is similar to the way  https  requests expect a certificate with the 
name you actually asked for.)


If my server is registered as  file.server.domain  but I request:
   //samba.server.domain/share
then that machine has to have a certificate for that name: an SPN

Previously it was good enough for the DNS to find the correct IP address.

   Shane
--
Shane Voss, Computing Officer, School of GeoSciences, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Re: Samba update killed my servers

2016-04-14 Thread Matthieu Guionnet
I had a big issue too with the last samba3 updates on SL6.

The windows PC has been updated too.

Windows users couldn't connect. The system reply that's it couldn't
connect to the domain.
On the server, I get some messages like this :

rpc_server/netlogon/srv_netlog_nt.c:976(_netr_ServerAuthenticate3)

_netr_ServerAuthenticate3: netlogon_creds_server_check failed.
Rejecting auth request from client PC001 machine account PC001$

I was able to exit a pc member and reintegrate it after but it doesn't
resolve the login issue.

Without other idea, I decide to downgrade the service and it works
again.

Matthieu.


Le mercredi 13 avril 2016 à 16:45 -0500, ~Stack~ a écrit :
> Greetings,
> 
> I am running SL6 on my Samba servers. I am in an environment where I
> am
> required to apply security patches daily. Yum auto updates nearly all
> security patches for me every morning (only a few things like the
> kernel
> are excluded).
> 
> This morning we went from 3.6.23-25 to 3.6.23-30. Every thing broke.
> Not
> a single server works.
> 
> Short recap that proves it is the update.
> $ # restore everything from backup server
> $ service nmb start; service smb start
> $ # everything works.
> $ service nmb stop; service smb stop
> $ yum update -y --security --exclude=kernel*
> # updates just 5 packages: samba, samba-client,
> # samba-common, samba-winbind, and samba-winbind-clients
> $ service nmb start; service smb start
> # Nothing works.
> $ service nmb stop; service smb stop
> $ yum history undo $lastversion
> $ service nmb start; service smb start
> # Everything works again.
> 
> There is really not much in the logs at all from smb/nmb as to what
> is
> going wrong. The client just gets a strange error about permissions
> denied. However, in the log file for the client, we see things like
> "Domain password server not available". There are occasional messages
> in
> nmb logs about "current master browser = UNKNOWN" and
> "find_domain_master_name_query_fail" but they are not easily
> reproducible.
> 
> 1) It is amazing how many questions on the samba list don't get
> responses...
> 
> 2) The vast majority of the responses I found on line didn't seem to
> work.
> 
> At one point, I scrapped my entire smb.conf file, wiped samba, and
> restarted with the smb.conf file the new RPM provided. I still
> couldn't
> get clients to connect.
> 
> Here is my smb.conf file that I restored from last night. It has been
> working since May of 2014.
> 
> [global]
> workgroup = MYWORKGROUP
> server string = hostname
> netbios name = hostname
> log file = /var/log/samba/log.%m
> max log size = 50
> security = domain
> password server = my.primary.domain.server
> preferred master = no
> wins support = no
> wins server = my.primary.domain.server
> wins proxy = yes
> dns proxy = yes
> load printers = yes
> cups option = raw
> restrict anonymous = 1
> smb ports = 139
> [homes]
> comment = Home Directories
> browsable = no
> writeable = yes
> valid users = %S
> 
> [ yes I know I am not supposed to use security=domain with password
> server, but it works. Modifying either seems to make it not work]
> 
> Anyone else have horrific issues with this update??
> 
> Thanks!
> ~Stack~
> 

smime.p7s
Description: S/MIME cryptographic signature


Re: Samba update killed my servers

2016-04-14 Thread Tom H
On Wed, Apr 13, 2016 at 11:45 PM, ~Stack~  wrote:
>
> I am running SL6 on my Samba servers. I am in an environment where I am
> required to apply security patches daily. Yum auto updates nearly all
> security patches for me every morning (only a few things like the kernel
> are excluded).
>
> This morning we went from 3.6.23-25 to 3.6.23-30. Every thing broke. Not
> a single server works.
>
> Short recap that proves it is the update.
> $ # restore everything from backup server
> $ service nmb start; service smb start
> $ # everything works.
> $ service nmb stop; service smb stop
> $ yum update -y --security --exclude=kernel*
> # updates just 5 packages: samba, samba-client,
> # samba-common, samba-winbind, and samba-winbind-clients
> $ service nmb start; service smb start
> # Nothing works.
> $ service nmb stop; service smb stop
> $ yum history undo $lastversion
> $ service nmb start; service smb start
> # Everything works again.
>
> There is really not much in the logs at all from smb/nmb as to what is
> going wrong. The client just gets a strange error about permissions
> denied. However, in the log file for the client, we see things like
> "Domain password server not available". There are occasional messages in
> nmb logs about "current master browser = UNKNOWN" and
> "find_domain_master_name_query_fail" but they are not easily reproducible.
>
> 1) It is amazing how many questions on the samba list don't get responses...
>
> 2) The vast majority of the responses I found on line didn't seem to work.
>
> At one point, I scrapped my entire smb.conf file, wiped samba, and
> restarted with the smb.conf file the new RPM provided. I still couldn't
> get clients to connect.
>
> Here is my smb.conf file that I restored from last night. It has been
> working since May of 2014.
>
> [global]
> workgroup = MYWORKGROUP
> server string = hostname
> netbios name = hostname
> log file = /var/log/samba/log.%m
> max log size = 50
> security = domain
> password server = my.primary.domain.server
> preferred master = no
> wins support = no
> wins server = my.primary.domain.server
> wins proxy = yes
> dns proxy = yes
> load printers = yes
> cups option = raw
> restrict anonymous = 1
> smb ports = 139
> [homes]
> comment = Home Directories
> browsable = no
> writeable = yes
> valid users = %S
>
> [ yes I know I am not supposed to use security=domain with password
> server, but it works. Modifying either seems to make it not work]
>
> Anyone else have horrific issues with this update??

I haven't updated samba on SL or any other distro but I wonder whether
this is reason:

o  CVE-2016-2111:

   It's basically the same as CVE-2015-0005 for Windows:

 The NETLOGON service in Microsoft Windows Server 2003 SP2,
 Windows Server 2008 SP2 and R2 SP1, and Windows Server 2012 Gold
 and R2, when a Domain Controller is configured, allows remote
 attackers to spoof the computer name of a secure channel's
 endpoint, and obtain sensitive session information, by running a
 crafted application and leveraging the ability to sniff network
 traffic, aka "NETLOGON Spoofing Vulnerability".

   The vulnerability in Samba is worse as it doesn't require
   credentials of a computer account in the domain.

   This only applies to Samba running as classic primary domain controller,
   classic backup domain controller or active directory domain controller.

   The security patches introduce a new option called "raw NTLMv2 auth"
   ("yes" or "no") for the [global] section in smb.conf.
   Samba (the smbd process) will reject client using raw NTLMv2
   without using NTLMSSP.

   Note that this option also applies to Samba running as
   standalone server and member server.

   You should also consider using "lanman auth = no" (which is already
the default)
   and "ntlm auth = no". Have a look at the smb.conf manpage for
further details,
   as they might impact compatibility with older clients. These also
   apply for all server roles.


Re: [SCIENTIFIC-LINUX-USERS] Samba update killed my servers

2016-04-14 Thread Jose Marques

> On 13 Apr 2016, at 22:45, ~Stack~  wrote:
> 
> Anyone else have horrific issues with this update??

I notice you've not updated the kernel. Sometimes I've seen selinux updates 
that depend on a kernel update and stuff won't work until the kernel is also 
updated. Probably nothing to do with your issue but I mention it just in case.

The University of St Andrews is a charity registered in Scotland, No. SC013532.



smime.p7s
Description: S/MIME cryptographic signature