On Thu, Sep 1, 2016 at 5:30 PM, <centos-request@xxxxxxxxxx> wrote:
> Send CentOS mailing list submissions to
> centos@xxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.centos.org/mailman/listinfo/centos
> or, via email, send a message with subject or body 'help' to
> centos-request@xxxxxxxxxx
>
> You can reach the person managing the list at
> centos-owner@xxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CentOS digest..."
>
>
> Today's Topics:
>
> 1. Re: CentOS 6 - logwatch report not in HTML format (Arun Khan)
> 2. Re: NODEJS010-NPM is not getting installed due to dependency
> errors on Custom Centos ISO installation (Jim Perrin)
> 3. Re: CentOS 6 - logwatch report not in HTML format
> (Alexander Farber)
> 4. Re: CentOS 6 - logwatch report not in HTML format (Arun Khan)
> 5. Re: CentOS 6 - logwatch report not in HTML format
> (Alexander Farber)
> 6. Re: group write permissions not being respected (Gordon Messmer)
> 7. Re: CentOS 6 - logwatch report not in HTML format (Arun Khan)
> 8. Re: group write permissions not being respected (Pat Haley)
> 9. Re: group write permissions not being respected (m.roth@xxxxxxxxx)
> 10. Re: group write permissions not being respected (Pat Haley)
> 11. Re: group write permissions not being respected (Chris Murphy)
> 12. Perl Unsafe Module Path Handling Directory Traversal
> Vulnerability ( CVE-2016-1238) (Sidharth Sharma)
> 13. Bind Vulnerability CVE-2016-2775 (Sidharth Sharma)
> 14. Re: "Windows" share issue; access via smb:// fails, "mount -t
> cifs" works (Toralf Lund)
> 15. Re: Bind Vulnerability CVE-2016-2775 (James Pearson)
> 16. Re: Bind Vulnerability CVE-2016-2775 (Mike Burger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 31 Aug 2016 07:11:11 -0700
> From: Arun Khan <knura9@xxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: CentOS 6 - logwatch report not in HTML format
> Message-ID:
> <CAHhM8gCz6SDqu8i5aHkUU58Sb91cHdNKUy=J_rYP25X48gk22Q@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Aug 29, 2016 at 10:24 PM, Alexander Farber
> <alexander.farber@xxxxxxxxx> wrote:
>> No, I mean there is sometimes a variable for mail format too:
>
> The HTML formatting is a logwatch option, invoked through the
> logwatch.conf file.
>
> -- Arun Khan
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 31 Aug 2016 09:20:26 -0500
> From: Jim Perrin <jperrin@xxxxxxxxxx>
> To: centos@xxxxxxxxxx
> Subject: Re: NODEJS010-NPM is not getting installed due to
> dependency errors on Custom Centos ISO installation
> Message-ID: <a607d751-c5e7-91eb-9e81-b6cdb379ecfa@xxxxxxxxxx>
> Content-Type: text/plain; charset=windows-1252
>
>
>
> On 08/31/2016 03:48 AM, SUDHANSHU BHUTANI wrote:
>> Hi,
>>
>> I have built successfully all the dependent packages of nodejs010 and npm.
>>
>> I have used following command:-
>> *rpmbuild --define 'scl nodejs010' --bb SPEC/name_of_spec.spec*
>
> You should really use mock, so that you don't have unintended libraries
> from your build host included/linked/required in the resulting rpm.
Thanks Jim for responding.
I tried with mock configuration, but, not sure, i am still getting the
same errors via repoclosre tool:-
This directory has got all the RPMs formed by mock.
[root@localhost YUM_CISCO_RPMS]# repoclosure -r Cisco-yum-dep-check
Reading in repository metadata - please wait....
Checking Dependencies
Repos looked at: 1
Cisco-yum-dep-check
Num Packages in Repos: 1515
package: nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch
from Cisco-yum-dep-check
unresolved deps:
nodejs010-npm(readable-stream) < 0:2
package: nodejs010-nodejs-cmd-shim-2.0.0-2.el7.centos.noarch from
Cisco-yum-dep-check
unresolved deps:
nodejs010-npm(graceful-fs) < 0:4
package: nodejs010-nodejs-columnify-1.3.2-3.el7.centos.noarch from
Cisco-yum-dep-check
unresolved deps:
nodejs010-npm(strip-ansi) >= 0:2.0.0
package: nodejs010-nodejs-fstream-ignore-1.0.2-1.el7.centos.noarch
from Cisco-yum-dep-check
unresolved deps:
nodejs010-npm(minimatch) < 0:3
package: nodejs010-nodejs-gauge-1.2.2-3.el7.centos.noarch from
Cisco-yum-dep-check
unresolved deps:
nodejs010-npm(has-unicode) < 0:2
package: nodejs010-nodejs-init-package-json-1.9.1-1.el7.centos.noarch
from Cisco-yum-dep-check
unresolved deps:
nodejs010-npm(promzard) >= 0:0.3.0
package: nodejs010-nodejs-npm-registry-client-7.0.8-1.el7.centos.noarch
from Cisco-yum-dep-check
unresolved deps:
nodejs010-npm(retry) >= 0:0.8.0
nodejs010-npm(request) >= 0:2.47.0
nodejs010-npm(concat-stream) >= 0:1.4.6
package: nodejs010-nodejs-which-1.2.0-1.el7.centos.noarch from
Cisco-yum-dep-check
unresolved deps:
nodejs010-npm(is-absolute) < 0:0.2
The only difference from my (for build of
nodejs010-nodejs-which-1.2.0-1.el7.centos.noarch.rpm) build-log and
http://cbs.centos.org/kojifiles/packages/nodejs010-nodejs-are-we-there-yet/1.0.4/1.el7/data/logs/noarch/build.log
is following line:-
*Requires: nodejs010-nodejs(engine) nodejs010-npm(delegates)
nodejs010-npm(readable-stream)* - >> THIS IS FROM CBS mock log
and following is my build log:-
*Requires: nodejs010-nodejs(engine) nodejs010-npm(delegates) >= 0.1.0
nodejs010-npm(delegates) < 0.2 nodejs010-npm(readable-stream) >=
1.1.13 nodejs010-npm(readable-stream) < 2*
I am not sure, why parsing of these version is defining a range, maybe
its coming from package.json file.
I feel, its related to nodejs010-build package which has
root/usr/lib/rpm/nodejs010.req, i defined mock configuration like
this:-
config_opts['root'] = 'epel-7-x86_64'
config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['chroot_setup_cmd'] = 'install @buildsys-build
scl-utils-build nodejs010-build'
Do they look good?
Following is my build.log
[sbhutani@localhost ~]$ cat nodejs-build/nodejs010-
Display all 316 possibilities? (y or n)
[sbhutani@localhost ~]$ cat
nodejs-build/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.src.rpm/build.log
Mock Version: 1.2.18
ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target
x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'],
chrootPath='/var/lib/mock/epel-7-x86_64/root'shell=FalseprintOutput=Falseenv={'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"',
'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1':
'<mock-chroot> \\s-\\v\\$
'}gid=135user='mockbuild'timeout=0logger=<mockbuild.trace_decorator.getLog
object at 0x22e3390>uid=1000)
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs
--target x86_64 --nodeps
/builddir/build/SPECS/nodejs-are-we-there-yet.spec'] with env {'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"',
'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1':
'<mock-chroot> \\s-\\v\\$ '} and shell False
Building target platforms: x86_64
Building for target x86_64
Wrote: /builddir/build/SRPMS/nodejs-are-we-there-yet-1.0.4-1.el7.centos.src.rpm
Child return code was: 0
Mock Version: 1.2.18
ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target
x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'],
chrootPath='/var/lib/mock/epel-7-x86_64/root'shell=FalseprintOutput=Trueenv={'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"',
'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1':
'<mock-chroot> \\s-\\v\\$
'}gid=135user='mockbuild'timeout=0logger=<mockbuild.trace_decorator.getLog
object at 0x1772390>uid=1000)
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs
--target x86_64 --nodeps
/builddir/build/SPECS/nodejs-are-we-there-yet.spec'] with env {'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"',
'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1':
'<mock-chroot> \\s-\\v\\$ '} and shell False
Building target platforms: x86_64
Building for target x86_64
Wrote: /builddir/build/SRPMS/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.src.rpm
Child return code was: 0
Mock Version: 1.2.18
ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target
x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'],
chrootPath='/var/lib/mock/epel-7-x86_64/root'shell=FalseprintOutput=Falseenv={'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"',
'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1':
'<mock-chroot> \\s-\\v\\$
'}gid=135user='mockbuild'timeout=0logger=<mockbuild.trace_decorator.getLog
object at 0x142d390>uid=1000)
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs
--target x86_64 --nodeps
/builddir/build/SPECS/nodejs-are-we-there-yet.spec'] with env {'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"',
'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1':
'<mock-chroot> \\s-\\v\\$ '} and shell False
Building target platforms: x86_64
Building for target x86_64
Wrote: /builddir/build/SRPMS/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.src.rpm
Child return code was: 0
ENTER ['do'](['bash', '--login', '-c', u'/usr/bin/rpmbuild -bb
--target x86_64 --nodeps
/builddir/build/SPECS/nodejs-are-we-there-yet.spec'],
chrootPath='/var/lib/mock/epel-7-x86_64/root'shell=Falseuid=1000env={'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"',
'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1':
'<mock-chroot> \\s-\\v\\$
'}gid=135user='mockbuild'timeout=0private_network=Truelogger=<mockbuild.trace_decorator.getLog
object at 0x142d390>printOutput=False)
Executing command: ['bash', '--login', '-c', u'/usr/bin/rpmbuild -bb
--target x86_64 --nodeps
/builddir/build/SPECS/nodejs-are-we-there-yet.spec'] with env {'LANG':
'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"',
'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1':
'<mock-chroot> \\s-\\v\\$ '} and shell False
Building target platforms: x86_64
Building for target x86_64
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.cNqdgI
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf package
+ /usr/bin/gzip -dc /builddir/build/SOURCES/are-we-there-yet-1.0.4.tgz
+ /usr/bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd package
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ rm -rf node_modules
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.iiP8RP
+ umask 022
+ cd /builddir/build/BUILD
+ cd package
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.IFmFuX
+ umask 022
+ cd /builddir/build/BUILD
+ '[' /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64
'!=' / ']'
+ rm -rf /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64
++ dirname /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64
+ mkdir -p /builddir/build/BUILDROOT
+ mkdir /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64
+ cd package
+ mkdir -p /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/lib/node_modules/are-we-there-yet
+ cp -pr package.json index.js
/builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/lib/node_modules/are-we-there-yet
+ /usr/lib/rpm/nodejs010-symlink-deps
/opt/rh/nodejs010/root/usr/lib/node_modules
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz
--dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000
/builddir/build/BUILD/package
/usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32s, 0 CRC32s did match.
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/brp-scl-compress /opt/rh/nodejs010/root
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-scl-python-bytecompile /usr/bin/python 1
/opt/rh/nodejs010/root
+ /usr/lib/rpm/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.7DYIy5
+ umask 022
+ cd /builddir/build/BUILD
+ cd package
+ DOCDIR=/builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/share/doc/nodejs010-nodejs-are-we-there-yet-1.0.4
+ export DOCDIR
+ /usr/bin/mkdir -p
/builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/share/doc/nodejs010-nodejs-are-we-there-yet-1.0.4
+ cp -pr README.md
/builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/share/doc/nodejs010-nodejs-are-we-there-yet-1.0.4
+ exit 0
Finding Provides: /usr/lib/rpm/nodejs010.prov
Finding Requires(interp):
Finding Requires(rpmlib):
Finding Requires(verify):
Finding Requires(pre):
Finding Requires(post):
Finding Requires(preun):
Finding Requires(postun):
Finding Requires(pretrans):
Finding Requires(posttrans):
Finding Requires: /usr/lib/rpm/nodejs010.req
Provides: nodejs010-nodejs-are-we-there-yet = 1.0.4-1.el7.centos
nodejs010-npm(are-we-there-yet) = 1.0.4
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <=
3.0.4-1
Requires: nodejs010-nodejs(engine) nodejs010-npm(delegates) >= 0.1.0
nodejs010-npm(delegates) < 0.2 nodejs010-npm(readable-stream) >=
1.1.13 nodejs010-npm(readable-stream) < 2
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64
Wrote: /builddir/build/RPMS/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.yi6hbn
+ umask 022
+ cd /builddir/build/BUILD
+ cd package
+ /usr/bin/rm -rf
/builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64
+ exit 0
Child return code was: 0
[sbhutani@localhost ~]$
Can any one catch difference between my build.log and CBS build.log.
If hhorak is on this mailing list who actually built this package on
CBS, can help?
Appreciate your inputs.
>>
>> Following is the list of RPMs cloned and built from GIT:-
>>
>
> <snip>
>
>
>>
>> *However, when we copy these RPMS to our ISO, anaconda installer fails
>> to install due to dependency errors:-*
>
>
> You should use the 'repoclosure' utility to make sure that you have met
> all the dependencies of packages in the repo on your iso.
>
>
>
>> How is it possible, to get these errors, how come packages are not
>> satisfying minimum dependency for working of NPM?
>
>
> repoclosure should tell you. You may be missing something scl related.
>
>
>>
>> If i do yumdownloader for all these above RPMs from repo: [centos-sclo-rh]
>> : http://mirror.centos.org/centos/7/sclo/x86_64/rh/nodejs010/), then i
>> get following RPMs without "centos" name:-
>
>
> Correct. This is an rpm macro change. by default the 'centos' is added
> in there.
>
>
>>
>> *If i copy paste above RPMS to my custom ISO, then anaconda
>> successfully installs these packages, without any errors*
>
>
> This would suggest something is wrong with your build. See previous
> statement about using mock vs rpmbuild.
>
>
>> *What is there is these already built RPMs (taken from repo: [centos-sclo-rh]
>> : http://mirror.centos.org/centos/7/sclo/x86_64/rh/nodejs010/) which
>> is not there in my built RPMS?*
>
> That's kind of up to you to figure out, since we can't see your custom
> built ones.
>
>
>> Any pointers for this, as we feel, there is some inconsistency in the
>> version available on git.centos.org/git/rpms/<name_of_pkg>.git ?
>
> More likely it's in your build method.
>
>
> --
> Jim Perrin
> The CentOS Project | http://www.centos.org
> twitter: @BitIntegrity | GPG Key: FA09AD77
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 31 Aug 2016 16:58:17 +0200
> From: Alexander Farber <alexander.farber@xxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: CentOS 6 - logwatch report not in HTML format
> Message-ID:
> <CAADeyWiMVpHh=CDZ6zi_OEq+5HwysoqTAOABDnM4mkYeFDhxYA@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> logwatch is run as cronjob.
>
> On Wed, Aug 31, 2016 at 4:11 PM, Arun Khan <knura9@xxxxxxxxx> wrote:
>
>> On Mon, Aug 29, 2016 at 10:24 PM, Alexander Farber
>> <alexander.farber@xxxxxxxxx> wrote:
>> > No, I mean there is sometimes a variable for mail format too:
>>
>> The HTML formatting is a logwatch option, invoked through the
>> logwatch.conf file.
>>
>> -- Arun Khan
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 31 Aug 2016 08:31:28 -0700
> From: Arun Khan <knura9@xxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: CentOS 6 - logwatch report not in HTML format
> Message-ID:
> <CAHhM8gDhhgRNb1C2rKRdE+v8w_fEhBmCvarf3MxO=njxL7w3-g@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Aug 31, 2016 at 7:58 AM, Alexander Farber
> <alexander.farber@xxxxxxxxx> wrote:
>> logwatch is run as cronjob.
>
> Let's take cron out of the picture. Invoking logwatch from an
> interactive shell -- no joy. The report still goes out in text
> format.
>
> -- Arun Khan
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 31 Aug 2016 17:59:44 +0200
> From: Alexander Farber <alexander.farber@xxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: CentOS 6 - logwatch report not in HTML format
> Message-ID:
> <CAADeyWiYQ_TNjZHZ9af2x3TM_Lq+U9LE+y4aheb6BXV_TBwGaQ@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> You should have provided more info initially.
>
> "goes out in text format" might mean several things.
>
> On Wed, Aug 31, 2016 at 5:31 PM, Arun Khan <knura9@xxxxxxxxx> wrote:
>
>> On Wed, Aug 31, 2016 at 7:58 AM, Alexander Farber
>> <alexander.farber@xxxxxxxxx> wrote:
>> > logwatch is run as cronjob.
>>
>> Let's take cron out of the picture. Invoking logwatch from an
>> interactive shell -- no joy. The report still goes out in text
>> format.
>>
>> -- Arun Khan
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 31 Aug 2016 09:50:45 -0700
> From: Gordon Messmer <gordon.messmer@xxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: group write permissions not being respected
> Message-ID: <8d10f9b1-0ed9-0217-ae0e-726acd1d9a87@xxxxxxxxx>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 08/30/2016 03:01 PM, Pat Haley wrote:
>> the owner of a directory can still write to that directory but any
>> other member of the associated group cannot, even though the directory
>> clearly has group write permissions set
>
>
> Use "getfacl" on both the client and server side to view the complete
> permission set. What do those look like?
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 31 Aug 2016 10:00:42 -0700
> From: Arun Khan <knura9@xxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: CentOS 6 - logwatch report not in HTML format
> Message-ID:
> <CAHhM8gBBc+i9VH=eiGM+K7ePerQbv4Nraa5ck7YMEixrhbzaoQ@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Aug 31, 2016 at 8:59 AM, Alexander Farber
> <alexander.farber@xxxxxxxxx> wrote:
>> You should have provided more info initially.
>>
>> "goes out in text format" might mean several things.
>>
>
> I don't know what you mean by "several things"
>
> In the context of logwatch the only options are HTML or TEXT. Please see my OP.
>
> Thanks for your assistance.
>
> -- Arun Khan
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 31 Aug 2016 13:11:09 -0400
> From: Pat Haley <phaley@xxxxxxx>
> To: centos@xxxxxxxxxx
> Cc: Steve Postma <SPostma@xxxxxxxxxxxx>
> Subject: Re: group write permissions not being respected
> Message-ID: <8d59038f-3dbe-5bff-9673-fbada1d3f31c@xxxxxxx>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
> So far, those look the same
>
> client:
>
> [root@mseas FixOwn]# getfacl /gdata/bibliography/Work/GroupBib/trunk/
> getfacl: Removing leading '/' from absolute path names
> # file: gdata/bibliography/Work/GroupBib/trunk/
> # owner: phaley
> # group: mseasweb
> # flags: -s-
> user::rwx
> group::rwx
> other::r-x
>
> server:
>
> [root@mseas-data2 ~]# getfacl /gdata/bibliography/Work/GroupBib/trunk/
> getfacl: Removing leading '/' from absolute path names
> # file: gdata/bibliography/Work/GroupBib/trunk/
> # owner: phaley
> # group: mseasweb
> # flags: -s-
> user::rwx
> group::rwx
> other::r-x
>
>
> On 08/31/2016 12:50 PM, Gordon Messmer wrote:
>> On 08/30/2016 03:01 PM, Pat Haley wrote:
>>> the owner of a directory can still write to that directory but any
>>> other member of the associated group cannot, even though the
>>> directory clearly has group write permissions set
>>
>>
>> Use "getfacl" on both the client and server side to view the complete
>> permission set. What do those look like?
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> https://lists.centos.org/mailman/listinfo/centos
>
> --
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Pat Haley Email: phaley@xxxxxxx
> Center for Ocean Engineering Phone: (617) 253-6824
> Dept. of Mechanical Engineering Fax: (617) 253-8125
> MIT, Room 5-213 http://web.mit.edu/phaley/www/
> 77 Massachusetts Avenue
> Cambridge, MA 02139-4301
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 31 Aug 2016 14:04:28 -0400
> From: m.roth@xxxxxxxxx
> To: "CentOS mailing list" <centos@xxxxxxxxxx>
> Subject: Re: group write permissions not being respected
> Message-ID:
> <b9abfd5a5a37f29bff085aae6174877f.squirrel@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain;charset=utf-8
>
> Stupid question, and note I missed most of the earlier posts in this
> thread: what are the permissions on the directory that this directory are
> in?
>
> mark
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 31 Aug 2016 15:06:25 -0400
> From: Pat Haley <phaley@xxxxxxx>
> To: centos@xxxxxxxxxx
> Subject: Re: group write permissions not being respected
> Message-ID: <d9ac7e12-3283-ea9e-a5b0-5dcd8d27d87d@xxxxxxx>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
> For example the directory /gdata/bibliography/Work/GroupBib/trunk/ can
> be written in by user phaley but not by other users who are member of
> the group mseasweb. The directory has permissions
>
> [root@mseas ~]# ls -lh /gdata/bibliography/Work/GroupBib
> total 12K
> drwxrwsr-x 4 phaley mseasweb 4.0K Aug 30 12:31 trunk
>
> The parent directory (/gdata/bibliography/Work/GroupBib) has permissions
>
> [root@mseas ~]# ls -lh /gdata/bibliography/Work/
> total 8.0K
> drwxrwsr-x 6 phaley mseasweb 4.0K Aug 30 14:01 GroupBib
>
>
>
> On 08/31/2016 02:04 PM, m.roth@xxxxxxxxx wrote:
>> Stupid question, and note I missed most of the earlier posts in this
>> thread: what are the permissions on the directory that this directory are
>> in?
>>
>> mark
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> https://lists.centos.org/mailman/listinfo/centos
>
> --
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Pat Haley Email: phaley@xxxxxxx
> Center for Ocean Engineering Phone: (617) 253-6824
> Dept. of Mechanical Engineering Fax: (617) 253-8125
> MIT, Room 5-213 http://web.mit.edu/phaley/www/
> 77 Massachusetts Avenue
> Cambridge, MA 02139-4301
>
>
>
> ------------------------------
>
> Message: 11
> Date: Thu, 01 Sep 2016 03:38:11 +0000
> From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: group write permissions not being respected
> Message-ID:
> <CAJCQCtTfr6rvPGH7uMNzYE9-Q+BfZ784a5n=4S5NekA7O8VxAA@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> Try booting with enforcing=0 and if that fixes it, you need to find out
> what security label is needed for gluster.
>
> Chances are it's easiest to use -o context= mount option on the brick, but
> if the brick is not exclusive to gluster you'll need chcon -R.
>
> If that's not it, maybe try the gluster client instead of using NFS. See if
> you get a different result that narrows down what's going on.
>
> My vague recollection is for Samba, without the correct SELinux label, I
> could neither read nor write.
>
>
> Chris Murphy
>
>
> ------------------------------
>
> Message: 12
> Date: Thu, 1 Sep 2016 11:03:30 +0530
> From: Sidharth Sharma <sharma.sidharth86@xxxxxxxxx>
> To: centos@xxxxxxxxxx
> Subject: Perl Unsafe Module Path Handling Directory Traversal
> Vulnerability ( CVE-2016-1238)
> Message-ID:
> <CAAQ4EFk7qgWvq=ZtSOugxsgQ1S54y8cFbiG33POQme8+cDrcSw@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> Hello Experts,
>
> When we can expect Security Update for Perl Vulnerability CVE-2016-1238 on
> CentOS 6.8 and 7.2?
>
> --
> With Thanks & Regards:
> Sidharth Sharma
>
>
> ------------------------------
>
> Message: 13
> Date: Thu, 1 Sep 2016 11:05:36 +0530
> From: Sidharth Sharma <sharma.sidharth86@xxxxxxxxx>
> To: centos@xxxxxxxxxx
> Subject: Bind Vulnerability CVE-2016-2775
> Message-ID:
> <CAAQ4EF=2AeThtVjJitR3JHGhuunRJ4AZHiYDcrp4vcKFxUV=UQ@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
>
> Hello Experts,
>
> When we can expect Security Update for Bind Vulnerability on Centos 6.8/7.2?
> ISC BIND Lightweight Resolver Protocol Req Processing Dos Vulnerability:
> CVE-2016-2775
>
> --
> With Thanks & Regards:
> Sidharth Sharma
>
>
> ------------------------------
>
> Message: 14
> Date: Thu, 1 Sep 2016 10:26:34 +0200
> From: Toralf Lund <toralf.lund@xxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: "Windows" share issue; access via smb:// fails,
> "mount -t cifs" works
> Message-ID: <2265d62b-32b6-6d51-5848-df84f5800723@xxxxxxx>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> On 30/08/16 10:00, Toralf Lund wrote:
>> Hi,
>>
>> Is anyone here using smb:// URLs to access "Windows" shares? I've been
>> doing this for a while with common file systems at work, and it used
>> to work just fine. Then I while back, I started getting issues; I will
>> now just keep getting asked for a password when I try to access
>> something through smb://. I thought at first that this meant there had
>> been some kind of change related to permissions on the shares, but now
>> I find that I can mount them just fine using "mount -t cifs".
> I found out a bit more about this - I believe that I have the issue
> described here:
>
> http://community.netapp.com/t5/Network-Storage-Protocols-Discussions/samba-3-6-23-30-on-CentOS-gt-error-in-smbclient/td-p/118268
>
> In other words, the problem is that "SPNEGO" fails. If I add "client use
> spnego = no" to /etc/samba/smb.conf, smbclient access works (I found
> that I also got a problem there), but unfortunately, gvfs-mount still
> doesn't. The debug output that I get if I run gvfsd on the command line
> with "GVFS_DEBUG=1" and "GVFS_SMB_DEBUG=99" actually still report SPNEGO
> errors, so it would appear that the smp.conf option is for some reason
> ignored. In other words the question may be:
>
> How do I disabled SPNEGO for gvfs-mount?
>
> Also, the above suggest that whether this problem occurs depends on
> whether "you have SMB signing turned on or not under the 'cifs' options
> section", but it not clear to me what options exactly this refers to.
> Anyone?
>
> Oh, and some other posts I found seem to indicate that mount.cifs
> doesn't support SPNEGO yet, so I guess that's why a "normal" mount works.
>
> - Toralf
>
>
>>
>> In other words, I get:
>>
>> gvfs-mount smb://mydomain\;toralf.lund@theserver/myshare
>> Password required for share myshare on theserver
>> Password:
>> Password required for share myshare on theserver
>> Password:
>> Password required for share myshare on theserver
>> Password:
>>
>> [ I enter the correct password, but gvs-mount keeps asking...
>> Behaviour is the same if I try to open the URL in the file manager
>> instead. ]
>>
>> mount -t cifs -o user=toralf.lund,workgroup=mydomain
>> //theserver/myshare /tmp_mnt/
>> Password:
>>
>> [ At this stage the filesystem is mounted, as long as I enter the
>> correct password. ]
>>
>> Does anyone have any idea what is going on here? Why does the VFS
>> mount fail when mount.cifs works on the same share? Is there a
>> difference in the way authentication works, or something? Has there
>> been a change to the smb support that might explain this?
>>
>> This is on a CentOS 6 x86_64 installation with all updates applied.
>>
>> - Toralf
>>
>
>
>
> ------------------------------
>
> Message: 15
> Date: Thu, 1 Sep 2016 08:34:08 +0000
> From: James Pearson <james-p@xxxxxxxxxxxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: Bind Vulnerability CVE-2016-2775
> Message-ID:
> <85C0B54E4752CA4F873E7C78CF0B26F5010FB3748D@xxxxxxxxxxxxxxxxx.local>
> Content-Type: text/plain; charset="us-ascii"
>
> Sidharth Sharma:
>>
>> When we can expect Security Update for Bind Vulnerability on Centos 6.8/7.2?
>> ISC BIND Lightweight Resolver Protocol Req Processing Dos Vulnerability:
> >CVE-2016-2775
>
> See:
>
> https://access.redhat.com/security/cve/cve-2016-2775
>
> James Pearson
>
> ------------------------------
>
> Message: 16
> Date: Thu, 01 Sep 2016 07:45:04 -0400
> From: Mike Burger <mburger@xxxxxxxxxxxxxxxxx>
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Subject: Re: Bind Vulnerability CVE-2016-2775
> Message-ID: <400e82588e4172b96a928e1e3aeef9e3@xxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On 2016-09-01 4:34 am, James Pearson wrote:
>> Sidharth Sharma:
>>>
>>> When we can expect Security Update for Bind Vulnerability on Centos
>>> 6.8/7.2?
>>> ISC BIND Lightweight Resolver Protocol Req Processing Dos
>>> Vulnerability:
>> >CVE-2016-2775
>>
>> See:
>>
>> https://access.redhat.com/security/cve/cve-2016-2775
>
> Ouch!
>
> Affected Packages State
> Platform Package State
> Red Hat Enterprise Linux 5 bind97 Will not fix
> Red Hat Enterprise Linux 6 bind Will not fix
> Red Hat Enterprise Linux 5 bind Will not fix
> Red Hat Enterprise Linux 7 bind Will not fix
>
> --
> Mike Burger
> http://www.bubbanfriends.org
>
> "It's always suicide-mission this, save-the-planet that. No one ever
> just stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1
>
>
> ------------------------------
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
>
> End of CentOS Digest, Vol 140, Issue 1
> **************************************
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
