January 2014 - erlang - Fedora mailing-lists

[Bug 1036780] New: rabbitmq-server wrapper script drops arguments
by Red Hat Bugzilla 29 Aug '16

29 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1036780 Bug ID: 1036780 Summary: rabbitmq-server wrapper script drops arguments Product: Fedora Version: rawhide Component: rabbitmq-server Assignee: hubert.plociniczak(a)gmail.com Reporter: rhbugs(a)rbu.sh QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, hubert.plociniczak(a)gmail.com, lemenkov(a)gmail.com Description of problem: the wrapper script /usr/sbin/rabbitmqctl drops all arguments to the command in certain cases, for example when the calling user is not root. I am running a rabbitmq node as a local user (for development) as a regular user, outside of /var. This works fine, however the Fedora-specific wrapper to "rabbitctl" will obscure access to the rabbitctl script. It took me quite a while to debug what was happening, until I found out the command is really a wrapper whose sole purpose is munging arguments -- and it does it wrong. Version-Release number of selected component (if applicable): I am on 3.1.5-1.fc19 but I see the same bug in rawhide. How reproducible: Always. Steps to Reproduce: 1. Be non-root / non-rabbitmq user 2. Run rabbitmqctl status Actual results: Error: could not recognise command Usage: rabbitmqctl [-n <node>] [-q] <command> [<command options>] ... Expected results: Status of node rabbit@localhost ... [{pid,1234},... Additional info: The warning "Only root or rabbitmq should run" should really be "Only root or rabbitmq must run", as currently it makes it impossible for anyone else. However, this is not true, as any user *can* run rabbitmq. Furthermore, users in the rabbitmq group should be able to run management commands, given the correct parameters. Lastly, the "rabbitmq-plugins" case looks fishy too, as it allows anyone to run the rabbitmq-plugins command, and makes the first line obsolete. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1027085] New: erlang-riaknostic-1.2.0 is available
by Red Hat Bugzilla 05 Mar '16

05 Mar '16

https://bugzilla.redhat.com/show_bug.cgi?id=1027085 Bug ID: 1027085 Summary: erlang-riaknostic-1.2.0 is available Product: Fedora Version: rawhide Component: erlang-riaknostic Keywords: FutureFeature, Triaged Assignee: lemenkov(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com Latest upstream release: 1.2.0 Current version/release in Fedora Rawhide: 1.1.0-1.fc20 URL: https://api.github.com/repos/basho/riaknostic/tags Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1028657] New: couchdb should also be usable under normal users
by Red Hat Bugzilla 03 Mar '16

03 Mar '16

https://bugzilla.redhat.com/show_bug.cgi?id=1028657 Bug ID: 1028657 Summary: couchdb should also be usable under normal users Product: Fedora Version: rawhide Component: couchdb Assignee: lemenkov(a)gmail.com Reporter: cickumqt(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com 1. Running under normal user: [rpmaker@fab fedpkg]$ couchdb Apache CouchDB 1.3.1 (LogLevel=info) is starting. Error opening log file /var/log/couchdb/couch.log: permission denied{"init terminating in do_boot",{{badmatch,{error,{bad_return,{{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,{shutdown,{failed_to_start_child,couch_primary_services,{shutdown,{failed_to_start_child,couch_log,{error,"permission denied","/var/log/couchdb/couch.log"}}}}}}},[{couch_server_sup,start_server,1,[{file,"couch_server_sup.erl"},{line,98}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,269}]}]}}}}}},[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}} 2. Running under root: [root@fab fedpkg]# couchdb Apache CouchDB 1.3.1 (LogLevel=info) is starting. Apache CouchDB has started. Time to relax. [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/ I don't know why this happened, but I think there might have some dirs/files are operated by incorrect permissions setting. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1027729] New: erlang-folsom-0.8.0 is available
by Red Hat Bugzilla 20 Feb '16

20 Feb '16

https://bugzilla.redhat.com/show_bug.cgi?id=1027729 Bug ID: 1027729 Summary: erlang-folsom-0.8.0 is available Product: Fedora Version: rawhide Component: erlang-folsom Keywords: FutureFeature, Triaged Assignee: lemenkov(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com Latest upstream release: 0.8.0 Current version/release in Fedora Rawhide: 0.7.4-2.fc20 URL: https://github.com/boundary/folsom/tags Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1027728] New: erlang-bear-0.8.0 is available
by Red Hat Bugzilla 12 Feb '16

12 Feb '16

https://bugzilla.redhat.com/show_bug.cgi?id=1027728 Bug ID: 1027728 Summary: erlang-bear-0.8.0 is available Product: Fedora Version: rawhide Component: erlang-bear Keywords: FutureFeature, Triaged Assignee: lemenkov(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com Latest upstream release: 0.8.0 Current version/release in Fedora Rawhide: 0.1.3-2.fc20 URL: https://github.com/boundary/bear/tags Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1059335] New: CVE-2014-1693 erlang: erlang-inets: command injection flaw in FTP module [epel-all]
by Red Hat Bugzilla 23 Dec '14

23 Dec '14

https://bugzilla.redhat.com/show_bug.cgi?id=1059335 Bug ID: 1059335 Summary: CVE-2014-1693 erlang: erlang-inets: command injection flaw in FTP module [epel-all] Product: Fedora EPEL Version: el6 Component: erlang Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: rjones(a)redhat.com Reporter: mprpic(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, gemi(a)bluewin.ch, rjones(a)redhat.com, skottler(a)redhat.com Blocks: 1059331 (CVE-2014-1693) 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 creating a Bodhi update request, please use the bodhi submission link noted 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 Bodhi notes field when available. Please note: this issue affects multiple supported versions of Fedora EPEL. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1059331 [Bug 1059331] CVE-2014-1693 erlang-inets: command injection flaw in FTP module -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1059333] New: CVE-2014-1693 erlang: erlang-inets: command injection flaw in FTP module [fedora-all]
by Red Hat Bugzilla 01 Dec '14

01 Dec '14

https://bugzilla.redhat.com/show_bug.cgi?id=1059333 Bug ID: 1059333 Summary: CVE-2014-1693 erlang: erlang-inets: command injection flaw in FTP module [fedora-all] Product: Fedora Version: 20 Component: erlang Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: lemenkov(a)gmail.com Reporter: mprpic(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, skottler(a)redhat.com Blocks: 1059331 (CVE-2014-1693) 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 creating a Bodhi update request, please use the bodhi submission link noted 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 Bodhi notes field when available. Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1059331 [Bug 1059331] CVE-2014-1693 erlang-inets: command injection flaw in FTP module -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1036280] New: selinux alerts about rabbitmq server ("access on the tcp_socket")
by Red Hat Bugzilla 05 Nov '14

05 Nov '14

https://bugzilla.redhat.com/show_bug.cgi?id=1036280 Bug ID: 1036280 Summary: selinux alerts about rabbitmq server ("access on the tcp_socket") Product: Fedora Version: 20 Component: rabbitmq-server Assignee: hubert.plociniczak(a)gmail.com Reporter: pavel.nedr(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, hubert.plociniczak(a)gmail.com, lemenkov(a)gmail.com Description of problem: I've seen flood in journalctl from SEalert about that error. It begins from startup of the system (rabbitmq is enabled in systemctl) There is a lot of error messages. They causes "audispd[643]: queue is full - dropping event" error :) rabbitmq-server noarch 3.1.5 1.fc20 $ sudo sealert -l 82db9030-74db-4e60-97ab-6aef447e582d SELinux is preventing /usr/lib64/erlang/erts-5.10.3/bin/beam.smp from name_bind access on the tcp_socket . ***** Plugin bind_ports (92.2 confidence) suggests ************************ If you want to allow /usr/lib64/erlang/erts-5.10.3/bin/beam.smp to bind to network port 10097 Then you need to modify the port type. Do # semanage port -a -t PORT_TYPE -p tcp 10097 где PORT_TYPE может принимать значения: amqp_port_t, couchdb_port_t, jabber_client_port_t, jabber_interserver_port_t. ***** Plugin catchall_boolean (7.83 confidence) suggests ****************** If вы хотите выполнить следующее: разрешить NIS Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Дополнительная документация на 'None' ман странице. Do setsebool -P nis_enabled 1 ***** Plugin catchall (1.41 confidence) suggests ************************** If вы считаете, что beam.smp следует разрешить доступ name_bind к tcp_socket по умолчанию. Then рекомендуется создать отчет об ошибке. Чтобы разрешить доступ, можно создать локальный модуль политики. Do чтобы разрешить доступ, выполните: # grep beam.smp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:rabbitmq_beam_t:s0 Target Context system_u:object_r:unreserved_port_t:s0 Target Objects [ tcp_socket ] Source beam.smp Source Path /usr/lib64/erlang/erts-5.10.3/bin/beam.smp Port 10097 Host bb.lan Source RPM Packages erlang-erts-R16B-02.7.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-105.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name bb.lan Platform Linux bb.lan 3.11.9-300.fc20.x86_64 #1 SMP Wed Nov 20 22:23:25 UTC 2013 x86_64 x86_64 Alert Count 85 First Seen 2013-11-29 23:40:14 MSK Last Seen 2013-11-30 15:01:23 MSK Local ID 82db9030-74db-4e60-97ab-6aef447e582d Raw Audit Messages type=AVC msg=audit(1385809283.320:612): avc: denied { name_bind } for pid=1897 comm="beam.smp" src=10097 scontext=system_u:system_r:rabbitmq_beam_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1385809283.320:612): arch=x86_64 syscall=bind success=no exit=EACCES a0=12 a1=7fac88cfb900 a2=1c a3=a items=0 ppid=1 pid=1897 auid=4294967295 uid=989 gid=984 euid=989 suid=989 fsuid=989 egid=984 sgid=984 fsgid=984 ses=4294967295 tty=(none) comm=beam.smp exe=/usr/lib64/erlang/erts-5.10.3/bin/beam.smp subj=system_u:system_r:rabbitmq_beam_t:s0 key=(null) Hash: beam.smp,rabbitmq_beam_t,unreserved_port_t,tcp_socket,name_bind -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1033305] New: rabbitmq-plugins is not in the default $PATH
by Red Hat Bugzilla 15 Oct '14

15 Oct '14

https://bugzilla.redhat.com/show_bug.cgi?id=1033305 Bug ID: 1033305 Summary: rabbitmq-plugins is not in the default $PATH Product: Fedora Version: 19 Component: rabbitmq-server Severity: low Assignee: hubert.plociniczak(a)gmail.com Reporter: johnhford(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, hubert.plociniczak(a)gmail.com, lemenkov(a)gmail.com Description of problem: This program is used to, for instance, enable the http management console. In the homebrew distribution, it's available in the default path. In fedora it's: $ rpm -ql rabbitmq-server | grep bin/rabbitmq-plugins /usr/lib/rabbitmq/bin/rabbitmq-plugins /usr/lib/rabbitmq/lib/rabbitmq_server-3.1.5/sbin/rabbitmq-plugins In the official distribution, it's in the default path: $ curl -LO http://www.rabbitmq.com/releases/rabbitmq-server/v3.2.1/rabbitmq-server-3.2… $ rpm -qpl rabbitmq-server-3.2.1-1.noarch.rpm | grep bin/rabbitmq-plugin warning: rabbitmq-server-3.2.1-1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID 056e8e56: NOKEY /usr/lib/rabbitmq/bin/rabbitmq-plugins /usr/lib/rabbitmq/lib/rabbitmq_server-3.2.1/sbin/rabbitmq-plugins /usr/sbin/rabbitmq-plugins How reproducible: 100% Steps to Reproduce: 1. install rabbitmq-server 2. try to run "sudo rabbitmq-plugins enable rabbitmq_management" Actual results: Program not found in $PATH. Expected results: Program found in $PATH and can be run -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1059028] New: rabbitmq restarts fail randomly
by Red Hat Bugzilla 18 Sep '14

18 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1059028 Bug ID: 1059028 Summary: rabbitmq restarts fail randomly Product: Fedora Version: 20 Component: rabbitmq-server Assignee: hubert.plociniczak(a)gmail.com Reporter: imcleod(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, hubert.plociniczak(a)gmail.com, lemenkov(a)gmail.com, skottler(a)redhat.com 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. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1036359] New: ejabberd logs not reopened after rotation
by Red Hat Bugzilla 01 Sep '14

01 Sep '14

https://bugzilla.redhat.com/show_bug.cgi?id=1036359 Bug ID: 1036359 Summary: ejabberd logs not reopened after rotation Product: Fedora Version: 20 Component: ejabberd Assignee: lemenkov(a)gmail.com Reporter: redhat(a)subs.maneos.org 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: Version-Release number of selected component (if applicable): ejabberd-2.1.13-7.fc20.x86_64 How reproducible: Steps to Reproduce: 1. Make sure ejabberd is running and logrotate is enabled. 2. Wait until logrotate runs. 3. Check contents of /var/log/ejabberd/ejabberd.log. Actual results: 0 size file that never gets updated. Expected results: File containing log entries for events as they occur. Additional info: /etc/logrotate.d/ejabberd is trying to run /usr/sbin/ejabberdctl, but ejabberdctl is installed in /usr/bin now. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1023017] New: Restore ECC support in Erlang's crypto library
by Red Hat Bugzilla 27 Aug '14

27 Aug '14

https://bugzilla.redhat.com/show_bug.cgi?id=1023017 Bug ID: 1023017 Summary: Restore ECC support in Erlang's crypto library Product: Fedora Version: rawhide Component: erlang Severity: high Assignee: lemenkov(a)gmail.com Reporter: lemenkov(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, rhbugs(a)n-dimensional.de Right now ECC is disabled explicitly since it looks like Erlang's crypto library assumes that it's either available fully or not. We've just enabled few ECC curves so this confuses erlang-crypto and leads to a startup issue like this: =ERROR REPORT==== 24-Oct-2013::16:30:48 === Unable to load crypto library. Failed with error: "load_failed, Failed to load NIF library: '/usr/lib64/erlang/lib/crypto-3.1/priv/lib/crypto.so: undefined symbol: EC_GROUP_new_curve_GF2m'" OpenSSL might not be installed on this system. We should patch crypto module to provide available ECC bits instead of disabling it completely. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=COwcnn7Cu3&a=cc_unsubscribe

1 7

[Bug 1038314] New: Cyclic dependencies: erlang and erlang-examples
by Red Hat Bugzilla 27 Aug '14

27 Aug '14

https://bugzilla.redhat.com/show_bug.cgi?id=1038314 Bug ID: 1038314 Summary: Cyclic dependencies: erlang and erlang-examples Product: Fedora Version: 19 Component: erlang Assignee: lemenkov(a)gmail.com Reporter: jakub.jedelsky(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, rhbugs(a)n-dimensional.de Description of problem: It is impossible to remove erlang package with /usr/bin/rpm command with erlang-examples and vice versa. There are cyclic dependencies among these two packages. Version-Release number of selected component (if applicable): erlang-R16B-02.3.fc19.x86_64 How reproducible: always Steps to Reproduce: 1. try to remove erlang $ /usr/bin/rpm -e erlang returns: error: Failed dependencies: erlang(x86-64) = R16B-02.3.fc19 is needed by (installed) erlang-examples-R16B-02.3.fc19.x86_64 2. try to remove erlang-examples $ /usr/bin/rpm -e erlang-examples returns: error: Failed dependencies: erlang-examples(x86-64) = R16B-02.3.fc19 is needed by (installed) erlang-R16B-02.3.fc19.x86_64 3. try to remove erlang ... Actual results: can't remove erlang without erlang-examples and vice versa Expected results: One of packages is possible to remove without any dependencies. Additional info: It's because of puppet, which removes packages through rpm command. There is no problem with removing through yum. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1056027] New: tsung-recorder script on x86_64 uses wrong path to Erlang
by Red Hat Bugzilla 07 Aug '14

07 Aug '14

https://bugzilla.redhat.com/show_bug.cgi?id=1056027 Bug ID: 1056027 Summary: tsung-recorder script on x86_64 uses wrong path to Erlang Product: Fedora EPEL Version: el6 Component: tsung Severity: medium Assignee: cickumqt(a)gmail.com Reporter: ts(a)bee.kz QA Contact: extras-qa(a)fedoraproject.org CC: cickumqt(a)gmail.com, erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com Description of problem: tsung-recorder script on x86_64 uses wrong path to Erlang Version-Release number of selected component (if applicable): 1.5.0-3.el6 How reproducible: Steps to Reproduce: $ yum install tsung $ cat /usr/bin/tsung-recorder | grep ^INSTALL_DIR Actual results: INSTALL_DIR=/usr/lib/erlang/ Expected results: INSTALL_DIR=/usr/lib64/erlang/ Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1059913] New: Race condition creating .erlang.cookie
by Red Hat Bugzilla 01 Jun '14

01 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1059913 Bug ID: 1059913 Summary: Race condition creating .erlang.cookie Product: Fedora Version: 20 Component: rabbitmq-server Assignee: hubert.plociniczak(a)gmail.com Reporter: jeckersb(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, hubert.plociniczak(a)gmail.com, lemenkov(a)gmail.com, skottler(a)redhat.com Description of problem: There is a race condition when starting rabbitmq-server for the first time. When the erlang runtime starts, it tries to read its cookie file (for rabbitmq, /var/lib/rabbitmq/.erlang.cookie) and if it doesn't already exist, it generates a new random cookie and creates the file. The following two lines from the rabbitmq-service.service unit file are involved: ExecStart=/usr/lib/rabbitmq/bin/rabbitmq-server ExecStartPost=/usr/lib/rabbitmq/bin/rabbitmqctl wait /var/run/rabbitmq/pid The rabbitmq-server command returns before the service is up. Therefor it is required to exec the additional rabbitmqctl wait in order to make sure the service starts all the way. However both of these are erlang programs, and they share the cookie startup code described previously. There is variance on the order of events and the eventual error. But generally what happens is: - ExecStart (rabbitmq-server) is run and exits. The erlang runtime is now booting in the background. - ExecStartPost (rabbitmqctl) is run. - rabbitmq-server determines the cookie file is not present, and generates a new cookie. - rabbitmqctl determines the cookie file is not present, and generates a new cookie. - rabbitmq-server writes the new cookie to disk and sets the file to read-only - rabbitmqctl tries to open the cookie file read/write in order to write its cookie, but errors with EACCESS because the file already exists and is read only. - The erlang runtime for rabbitmqctl crashes and the command returns with a non-successful exit code. - The entire service unit is marked as failed, and all of the processes are killed by systemd. Version-Release number of selected component (if applicable): rabbitmq-server-3.1.5-1.fc20.noarch erlang-R16B-03.1.fc20.x86_64 How reproducible: There is some variability since it's a race. I've provided my reproducer below that works 100% of the time for me, inside a F20 VM. In theory this behavior should still exist if starting the service from the cli instead of rebooting, but I can't reproduce it that way. Steps to Reproduce: 1. install rabbitmq-server 2. systemctl enable rabbitmq-server.service 3. reboot Actual results: Service fails to start, see attachment of journalctl output for error Expected results: Service starts cleanly Additional info: This is really an erlang bug, but the workaround for rabbit is simple (I'll post a patch in a followup). I'll run down the erlang bit separately but it will take longer, so it makes sense to apply the workaround here until erlang is fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1059563] New: erlang-R16B03-1 is available
by Red Hat Bugzilla 18 Apr '14

18 Apr '14

https://bugzilla.redhat.com/show_bug.cgi?id=1059563 Bug ID: 1059563 Summary: erlang-R16B03-1 is available Product: Fedora Version: rawhide Component: erlang Keywords: FutureFeature, Triaged Assignee: lemenkov(a)gmail.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, rhbugs(a)n-dimensional.de, skottler(a)redhat.com Latest upstream release: R16B03-1 Current version/release in Fedora Rawhide: R16B-03.1.fc21 URL: http://www.erlang.org/download.html Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1048760] New: elixir-0.12.1 is available
by Red Hat Bugzilla 04 Feb '14

04 Feb '14

https://bugzilla.redhat.com/show_bug.cgi?id=1048760 Bug ID: 1048760 Summary: elixir-0.12.1 is available Product: Fedora Version: rawhide Component: elixir Keywords: FutureFeature, Triaged Assignee: relrod(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, puiterwijk(a)redhat.com, relrod(a)redhat.com Latest upstream release: 0.12.1 Current version/release in Fedora Rawhide: 0.12.0-1.fc21 URL: https://api.github.com/repos/elixir-lang/elixir/tags Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1054074] New: elixir-0.12.2 is available
by Red Hat Bugzilla 04 Feb '14

04 Feb '14

https://bugzilla.redhat.com/show_bug.cgi?id=1054074 Bug ID: 1054074 Summary: elixir-0.12.2 is available Product: Fedora Version: rawhide Component: elixir Keywords: FutureFeature, Triaged Assignee: relrod(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com, puiterwijk(a)redhat.com, relrod(a)redhat.com Latest upstream release: 0.12.2 Current version/release in Fedora Rawhide: 0.12.1-1.fc21 URL: https://api.github.com/repos/elixir-lang/elixir/tags Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug.

1 6

Broken dependencies: erlang-rpm-macros
by Fedora Koji Build System 31 Jan '14

31 Jan '14

erlang-rpm-macros has broken dependencies in the epel-7 tree: On x86_64: erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript On ppc64: erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript Please resolve this as soon as possible.

1 0

Broken dependencies: erlang-rpm-macros
by Fedora Koji Build System 30 Jan '14

30 Jan '14

erlang-rpm-macros has broken dependencies in the epel-7 tree: On x86_64: erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript On ppc64: erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript Please resolve this as soon as possible.

1 0

[Bug 1059331] CVE-2014-1693 erlang-inets: command injection flaw in FTP module
by Red Hat Bugzilla 29 Jan '14

29 Jan '14

https://bugzilla.redhat.com/show_bug.cgi?id=1059331 Martin Prpic <mprpic(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends On| |1059333 Depends On| |1059335 --- Comment #1 from Martin Prpic <mprpic(a)redhat.com> --- Created erlang tracking bugs for this issue: Affects: fedora-all [bug 1059333] Affects: epel-all [bug 1059335] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1059333 [Bug 1059333] CVE-2014-1693 erlang: erlang-inets: command injection flaw in FTP module [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1059335 [Bug 1059335] CVE-2014-1693 erlang: erlang-inets: command injection flaw in FTP module [epel-all] -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1059331] CVE-2014-1693 erlang-inets: command injection flaw in FTP module
by Red Hat Bugzilla 29 Jan '14

29 Jan '14

https://bugzilla.redhat.com/show_bug.cgi?id=1059331 Martin Prpic <mprpic(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erlang(a)lists.fedoraproject. | |org, gemi(a)bluewin.ch, | |lemenkov(a)gmail.com, | |rhbugs(a)n-dimensional.de, | |rjones(a)redhat.com, | |skottler(a)redhat.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

Broken dependencies: erlang-rpm-macros
by Fedora Koji Build System 29 Jan '14

29 Jan '14

erlang-rpm-macros has broken dependencies in the epel-7 tree: On x86_64: erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript On ppc64: erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript Please resolve this as soon as possible.

1 0

Using git for patch management in Fedora
by Richard W.M. Jones 28 Jan '14

28 Jan '14

Several packages are using git for patch management. eg: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f2… http://pkgs.fedoraproject.org/cgit/qemu.git/tree/ http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16 Some of these packages have invented home-brewed methods to generate the Patch lines in the spec file, eg: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20 More importantly, all are using random git repositories to store the exploded tree. This makes it difficult for co-maintainers and proven packagers to fit in with the patch management chosen by the maintainer. Usually they won't have access to the git repository for these patches, making it difficult to add patches and near impossible to upgrade to a new version. I think that git is an excellent way to manage patches, but we ought to think about formalizing this process. I think the goals should be: (1) A git repository is used that co-maintainers and proven packagers automatically have access to. (2) A single method & script is used to update the patches in the spec file. Although there is already a git repository satisfying (1) above, namely dist-git, it isn't suitable for storing the exploded tree since commits to the spec file would conflict with commits (patches) to the tree. So either a separate side repository which packages could opt-in to, or perhaps a separate branch of the same git repo could be used. I think using a branch would require no additional infrastructure. For (2) I would suggest a lightweight technique where git-managed patches are marked in the spec file using: ### GIT-MANAGED-PATCHES ### ### END-GIT-MANGED-PATCHES ### and a simple script that replaces everything between those marks with PatchXXXX lines. The script could be adapted from copy-patches.sh (see above). To apply the patches, a standard RPM macro could be created: %prep %setup -q %{git_apply_patches} which would expand to something like: git init git config user.email "%{name}-owner(a)fedoraproject.org" git config user.name "%{name}" git add . git commit -a -q -m "%{version} baseline" git am %{patches} Thoughts on this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

11 28

Broken dependencies: erlang-rpm-macros
by Fedora Koji Build System 28 Jan '14

28 Jan '14

erlang-rpm-macros has broken dependencies in the epel-7 tree: On x86_64: erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript On ppc64: erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript Please resolve this as soon as possible.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

erlang January 2014