Re: abiword
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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