[Bug 1148444] New: logrotation fails
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1148444
Bug ID: 1148444
Summary: logrotation fails
Product: Fedora EPEL
Version: epel7
Component: rabbitmq-server
Assignee: lemenkov(a)gmail.com
Reporter: Jan.van.Eldik(a)cern.ch
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org,
hubert.plociniczak(a)gmail.com, jeckersb(a)redhat.com,
josh(a)fornwall.com, lemenkov(a)gmail.com,
rjones(a)redhat.com, s(a)shk.io
Description of problem:
Logrotation fails 100% because of old-style post-rotate command
Version-Release number of selected component (if applicable):
rabbitmq-server-3.1.5-7.el7.noarch
How reproducible:
100%
Steps to Reproduce:
[root@jcentos7-01 tmp]# logrotate -f /etc/logrotate.conf
The service command supports only basic LSB actions (start, stop, restart,
try-restart, reload, force-reload, status). For other actions, please try to
use systemctl.
error: error running shared postrotate script for '/var/log/rabbitmq/*.log '
[root@jcentos7-01 tmp]# cat /etc/logrotate.d/rabbitmq-server
/var/log/rabbitmq/*.log {
weekly
missingok
rotate 20
compress
delaycompress
notifempty
sharedscripts
postrotate
/sbin/service rabbitmq-server rotate-logs > /dev/null
endscript
}
[root@jcentos7-01 tmp]# /sbin/service rabbitmq-server rotate-logs > /dev/null
The service command supports only basic LSB actions (start, stop, restart,
try-restart, reload, force-reload, status). For other actions, please try to
use systemctl.
[root@jcentos7-01 tmp]# echo $?
2
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 7 months
[Bug 1206714] New: CVE-2015-2774 erlang: Erlang/OTP is vulnerable to Poodle in its TLS-1.0 implementation [epel-all]
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1206714
Bug ID: 1206714
Summary: CVE-2015-2774 erlang: Erlang/OTP is vulnerable to
Poodle in its TLS-1.0 implementation [epel-all]
Product: Fedora EPEL
Version: el6
Component: erlang
Keywords: Security, SecurityTracking
Severity: high
Priority: high
Assignee: rjones(a)redhat.com
Reporter: fleite(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org, gemi(a)bluewin.ch,
rjones(a)redhat.com, s(a)shk.io
Blocks: 1206712 (CVE-2015-2774)
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of Fedora EPEL.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple supported versions of Fedora EPEL. While
only one tracking bug has been filed, please correct all affected versions
at the same time. If you need to fix the versions independent of each
other, you may clone this bug as appropriate.
[bug automatically created by: add-tracking-bugs]
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1206712
[Bug 1206712] CVE-2015-2774 Erlang/OTP is vulnerable to Poodle in its
TLS-1.0 implementation
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 7 months
[Bug 1206713] New: CVE-2015-2774 erlang: Erlang/OTP is vulnerable to Poodle in its TLS-1.0 implementation [fedora-all]
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1206713
Bug ID: 1206713
Summary: CVE-2015-2774 erlang: Erlang/OTP is vulnerable to
Poodle in its TLS-1.0 implementation [fedora-all]
Product: Fedora
Version: 21
Component: erlang
Keywords: Security, SecurityTracking
Severity: high
Priority: high
Assignee: lemenkov(a)gmail.com
Reporter: fleite(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com,
rhbugs(a)n-dimensional.de, s(a)shk.io
Blocks: 1206712 (CVE-2015-2774)
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of Fedora.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time. If you need to fix the versions independent of each other,
you may clone this bug as appropriate.
[bug automatically created by: add-tracking-bugs]
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1206712
[Bug 1206712] CVE-2015-2774 Erlang/OTP is vulnerable to Poodle in its
TLS-1.0 implementation
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 8 months
[Bug 1144100] New: rabbitmq restarts fail randomly
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1144100
Bug ID: 1144100
Summary: rabbitmq restarts fail randomly
Product: Fedora EPEL
Version: epel7
Component: rabbitmq-server
Assignee: lemenkov(a)gmail.com
Reporter: bnemec(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: bnemec(a)redhat.com, erlang(a)lists.fedoraproject.org,
extras-qa(a)fedoraproject.org,
hubert.plociniczak(a)gmail.com, imcleod(a)redhat.com,
jeckersb(a)redhat.com, josh(a)fornwall.com,
lemenkov(a)gmail.com, lnie(a)redhat.com,
ohadlevy(a)redhat.com, rjones(a)redhat.com, s(a)shk.io
Depends On: 1059028
+++ This bug was initially created as a clone of Bug #1059028 +++
This still appears to be a problem in the EPEL version of rabbitmq-server.
Description of problem:
I originally encountered this issue when installing OpenStack via devstack but
have since been able to reproduce it by simply executing commands inside of a
fresh F20 install.
Version-Release number of selected component (if applicable):
rabbitmq-server-3.1.5-1.fc20.noarch
How reproducible:
Occurs regularly but not 100% of the time
Steps to Reproduce:
/sbin/service rabbitmq-server stop
/sbin/service rabbitmq-server start
rabbitmqctl change_password guest newpassword
Actual results:
About half the time, on a freshly installed F20, this will fail, claiming the
node cannot be contacted. A typical error message:
[root@cob-dell5 ~]# rabbitmqctl change_password guest ozrootpw
Changing password for user "guest" ...
Error: unable to connect to node 'rabbit@cob-dell5': nodedown
DIAGNOSTICS
===========
nodes in question: ['rabbit@cob-dell5']
hosts, their running nodes and ports:
- cob-dell5: [{rabbitmqctl2648,48609}]
current node details:
- node name: 'rabbitmqctl2648@cob-dell5'
- home dir: /var/lib/rabbitmq
- cookie hash: 8DNoVu56TqDYWypW7YXDJw==
Expected results:
Changing password for user "guest" ...
...done.
--- Additional comment from Ian McLeod on 2014-01-28 21:36:45 EST ---
See the following thread on rdo-list for another example of this issue:
https://www.redhat.com/archives/rdo-list/2013-December/msg00058.html
As well as this more recent one, indicating tha the problem persists:
https://www.redhat.com/archives/rdo-list/2014-January/msg00164.html
--- Additional comment from Ian McLeod on 2014-02-27 17:51:21 EST ---
Note to anyone following. The devstack installer has a commit that attempts to
workaround this issue by retrying the rabbitmq restart:
https://github.com/openstack-dev/devstack/commit/f6c001faf6ac5728e07c6bbd...
Still, it would be nice to sort this out on the rabbitmq side eventually.
--- Additional comment from Fedora Admin XMLRPC Client on 2014-07-01 13:58:36
EDT ---
This package has changed ownership in the Fedora Package Database. Reassigning
to the new owner of this component.
--- Additional comment from Fedora Update System on 2014-08-10 04:14:16 EDT ---
rabbitmq-server-3.1.5-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/rabbitmq-server-3.1.5-9.fc20
--- Additional comment from lnie on 2014-08-11 03:00:36 EDT ---
rabbitmq-server-3.1.5-9.fc20 works
--- Additional comment from Fedora Update System on 2014-08-14 22:35:38 EDT ---
Package rabbitmq-server-3.1.5-9.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rabbitmq-server-3.1.5-9.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-9337/rabbitmq-server-...
then log in and leave karma (feedback).
--- Additional comment from Fedora Update System on 2014-08-15 20:28:02 EDT ---
rabbitmq-server-3.1.5-9.fc20 has been pushed to the Fedora 20 stable
repository. If problems still persist, please make note of it in this bug
report.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1059028
[Bug 1059028] rabbitmq restarts fail randomly
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 9 months
[Bug 1164006] New: wrong default EJABBERD_DOC_PATH
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1164006
Bug ID: 1164006
Summary: wrong default EJABBERD_DOC_PATH
Product: Fedora
Version: 20
Component: ejabberd
Severity: low
Assignee: lemenkov(a)gmail.com
Reporter: honza(a)slunceweb.cz
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org, jkaluza(a)redhat.com,
lemenkov(a)gmail.com, martin(a)laptop.org
Description of problem:
Default EJABBERD_DOC_PATH in /usr/bin/ejabberdctl is /usr/share/doc/ejabberd,
but the documentation is in /usr/share/doc/ejabberd-doc.
Version-Release number of selected component (if applicable):
ejabberd-2.1.13-7.fc20.x86_64
How reproducible:
Always
Actual results:
Broken links in ejabberd Web Admin.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1138213] New: Rabbitmq cluster remains partitioned after short network partition incident
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1138213
Bug ID: 1138213
Summary: Rabbitmq cluster remains partitioned after short
network partition incident
Product: Fedora
Version: 20
Component: rabbitmq-server
Assignee: lemenkov(a)gmail.com
Reporter: jprovazn(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org,
hubert.plociniczak(a)gmail.com, jeckersb(a)redhat.com,
lemenkov(a)gmail.com, rjones(a)redhat.com, s(a)shk.io
Description of problem:
In 3-node rabbitmq cluster after network partition happens and then when 3
nodes can communicate again, then cluster remains partitioned if
"pause_minority" policy is used.
This happens if network outage is short enough (~60secs), for longer outages
(>3 minutes) cluster was reconstructed properly. Very similar issue was
reported here:
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2014-March/034639.html
This issue seems to be fixed in upstream already (not sure in which version
exactly, but 3.3.5 works fine).
Version-Release number of selected component (if applicable):
rabbitmq-server-3.1.5-9.fc20.noarch
Steps to Reproduce:
1. create 3-node cluster, use "pause_minority" no-quorum policy
2. stop networking on one of nodes and wait until the node is seen as shutdown
on other nodes
3. start networking on the node again
Actual results:
Cluster remains partitioned:
[root@overcloud-controller1-csugetg5pjql ~]# rabbitmqctl cluster_status
Cluster status of node 'rabbit@overcloud-controller1-csugetg5pjql' ...
[{nodes,
[{disc,
['rabbit@overcloud-controller0-o6yt2gtaxk6g',
'rabbit@overcloud-controller1-csugetg5pjql',
'rabbit@overcloud-controller2-z3tswnamdzhq']}]},
{running_nodes,
['rabbit@overcloud-controller0-o6yt2gtaxk6g',
'rabbit@overcloud-controller1-csugetg5pjql']},
{partitions,
[{'rabbit@overcloud-controller0-o6yt2gtaxk6g',
['rabbit@overcloud-controller2-z3tswnamdzhq']},
{'rabbit@overcloud-controller1-csugetg5pjql',
['rabbit@overcloud-controller2-z3tswnamdzhq']}]}]
...done.
Expected results:
no partitiones after the node is up again
Additional info:
only related message in log:
Mnesia('rabbit@overcloud-controller0-o6yt2gtaxk6g'): ** ERROR ** mnesia_event
got {inconsistent_database, running_partitioned_network,
'rabbit@overcloud-controller2-z3tswnamdzhq'}
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1098806] New: [abrt] couchdb: __pthread_mutex_lock(): couchjs killed by SIGSEGV
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1098806
Bug ID: 1098806
Summary: [abrt] couchdb: __pthread_mutex_lock(): couchjs killed
by SIGSEGV
Product: Fedora
Version: 20
Component: couchdb
Assignee: lemenkov(a)gmail.com
Reporter: fedorabugs(a)aylett.co.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com
Description of problem:
Running the built-in installation verification, after adding an SELinux rule to
work around #1098802.
After the crash, one of the Erlang processes seemed to get stuck in a restart
loop.
Version-Release number of selected component:
couchdb-1.5.0-1.fc20
Additional info:
reporter: libreport-2.2.2
backtrace_rating: 4
cmdline: /usr/bin/couchjs /usr/share/couchdb/server/main.js
crash_function: __pthread_mutex_lock
executable: /usr/lib64/erlang/lib/couch-1.5.0/priv/couchjs
kernel: 3.14.3-200.fc20.x86_64
runlevel: N 5
type: CCpp
uid: 984
Truncated backtrace:
Thread no. 1 (8 frames)
#0 __pthread_mutex_lock at ../nptl/pthread_mutex_lock.c:66
#1 PR_Lock at ../../../nspr/pr/src/pthreads/ptsynch.c:177
#2 AutoLockGC at jscntxt.h:2601
#3 finish at jsgc.cpp:2048
#4 js_FinishGC at jsgc.cpp:869
#5 JSRuntime::~JSRuntime at jsapi.cpp:696
#6 JS_Finish at jsapi.cpp:763
#7 JS_Init at jsapi.cpp:753
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1098802] New: SELinux alerts starting and running couchdb
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1098802
Bug ID: 1098802
Summary: SELinux alerts starting and running couchdb
Product: Fedora
Version: 20
Component: couchdb
Assignee: lemenkov(a)gmail.com
Reporter: fedorabugs(a)aylett.co.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com
Created attachment 896832
--> https://bugzilla.redhat.com/attachment.cgi?id=896832&action=edit
Output of `sudo grep type=AVC /var/log/audit/audit.log`
Description of problem:
After installing couchdb in F20, when starting the service you get SELinux
alerts. The web UI runs, but the internal self-test fails.
Version-Release number of selected component (if applicable):
Installed:
couchdb.x86_64 0:1.5.0-1.fc20
Dependency Installed:
erlang-asn1.x86_64 0:R16B-03.5.fc20
erlang-compiler.x86_64 0:R16B-03.5.fc20
erlang-crypto.x86_64 0:R16B-03.5.fc20
erlang-erts.x86_64 0:R16B-03.5.fc20
erlang-et.x86_64 0:R16B-03.5.fc20
erlang-gs.x86_64 0:R16B-03.5.fc20
erlang-hipe.x86_64 0:R16B-03.5.fc20
erlang-ibrowse.x86_64 0:2.2.0-8.fc20
erlang-inets.x86_64 0:R16B-03.5.fc20
erlang-kernel.x86_64 0:R16B-03.5.fc20
erlang-mnesia.x86_64 0:R16B-03.5.fc20
erlang-mochiweb.x86_64 0:2.4.2-3.fc20
erlang-oauth.x86_64 0:1.4.0-1.fc20
erlang-observer.x86_64 0:R16B-03.5.fc20
erlang-os_mon.x86_64 0:R16B-03.5.fc20
erlang-otp_mibs.x86_64 0:R16B-03.5.fc20
erlang-public_key.x86_64 0:R16B-03.5.fc20
erlang-runtime_tools.x86_64 0:R16B-03.5.fc20
erlang-sasl.x86_64 0:R16B-03.5.fc20
erlang-snappy.x86_64 0:1.0.3-0.5.git80db168.fc20
erlang-snmp.x86_64 0:R16B-03.5.fc20
erlang-ssl.x86_64 0:R16B-03.5.fc20
erlang-stdlib.x86_64 0:R16B-03.5.fc20
erlang-syntax_tools.x86_64 0:R16B-03.5.fc20
erlang-tools.x86_64 0:R16B-03.5.fc20
erlang-webtool.x86_64 0:R16B-03.5.fc20
erlang-wx.x86_64 0:R16B-03.5.fc20
erlang-xmerl.x86_64 0:R16B-03.5.fc20
lksctp-tools.x86_64 0:1.0.15-2.fc20
How reproducible:
sudo systemctl start couchdb
Browse to http://127.0.0.1:5984/_utils/verify_install.html and choose to verify
your installation.
Actual results:
Three alerts in the SELinux Alert Browser
Expected results:
All operations succeed.
Additional info:
Output of `sudo grep type=AVC /var/log/audit/audit.log` attached. That output
suggests there may be a conflict with my install of docker-io?
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months