Re: Building Tor with libevent 2.x (from ports)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://trac.torproject.org/projects/tor/ticket/16651 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVski/AAoJEFv7XvVCELh0BkkQALoK6yMEqEAqF8VKpESTxDop joWwFTaylYakHGF3HqILE4/P7T6uqZIz+8xCnNwM0p1LRPMpL/AVvh4/tRa4L/z2 pmFTBRzdILrlSE0VngVbJhnsDGnNjCTUXCJhTHh2wKAPDCewOUhEXOey53Tc82ZF 2GJH+Uj+J/mmnIJo4mKERcMcHqAMNID25nFmv4Xid7eYhq3XRS/SMT6wuYJPm59N 7pGFk2kfNQeBb4YcIHvYsKB5We/VBSOrwF97/cd/bdD8I6345snsNyOaQZKs4tXp wUeSHtLrCp4twlmA1HZmUqbjxGvG26nXebwvxvOlANhzcwHH8WbIv63YCusiAy3f SZd4G8xU9pzp6aEIEMfiVtViLxMxkXesdjYiCI0lQIiLmx9GzPDJCnlrnat3Y2L8 1LhB/O1Gf8/B5wnkTAvATlC5jlp3gJfk9AnTZY7onrc1x4mHMJKXsKVnM8Fozaa7 kM21EcK37FDqNUgXu4tzAF9bVZVcojAdUE8zXtE3OqMXwsA1wHS4yOHy4CvR5q0W MC0ntzURPiOAXlmXBVjYpfHXOeJmDp5u0FjL3XAd1eOU580eF2gf6iZ2j7Ou/Top L3l0mb+TOjlE23hiqbLRY4+VuL/0uo++pO/KFdW+ochWjBFL6DZjyzy+jzwMDXOI MQ9Q+6ARHl6avxksDI1E =SBxX -END PGP SIGNATURE-
Building Tor with libevent 2.x (from ports)
Hi Pascal, as we have learned from Nicholas, OpenBSD will stay with libevent 1.4.x for the time being. Do you have any plans to make the Tor port use libevent 2.x from ports? Background: Tor on OpenBSD using libevent 1.4.15 is significantly slower (less throughput) compared to other OSes with libevent 2.x on the same machine. I don't know whether libevent is related to this issue in any way but I simply wanted to see whether Tor with libevent 2.x on OpenBSD is any different in this regard compared to Tor with libevent 1.4.x on OpenBSD. If you managed to build Tor on -stable with libevent 2.x from ports I'm also happy to try any custom patches you might have applied. thank you, nusenu [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: OpenBSD release with libevent 2.x?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 No we have pretty much settled on a (mildly forked) 1.4 now and there are no plans to update the base system. Thanks for your answer. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVsQq6AAoJEFv7XvVCELh0fNkP/17w6ZopeuWUvqLqPzNzoakd 9QiZemNTcWcFc/9Y4GdiNK46muYG+X64cB0vb+f7uKs4Ei5eGJIcBdoV3o++BDcj TCWD/KGR4KuIANiDE+48BQ4Z5qwFdg2CQDuvkPrVK/FNfJ7PolQo2tWJZ7+CFfND KNxwY/8gMZrK3qhSbgKht7HFmXQf1EyMqyjBBcWFyLoSexdbGZEpPa2qmjdXrPNS MpF8pQpcmT8MGVfPZvawCGSM7bTlW/X0hhpEtzuLtqskDsPbF6OcCGMweZniffZD zRl3MmEQhMWMrxisto7LdB80g1eewgtDFVnMr5e+MlhB35sqaRK84dIw8UjtF//v CGnqE0VhqrSO8iOpgr+9VxhI62PpWwIqBtW65Acv1ruG7kOPC/FHuijG/k1Gdobk L1Kjq8eToe5wiDzOj0CnqrHT8uHmonKMnsWWVf4nvz8N1pM7TcXnigy3hRAcvuD6 1Xw5Q2tzujAmak2jJcLRLAu6h6qF2QLuannyRdRu2ZDDMUtWSFvlvwdLlD15Il8D X2c8bnDVNbfNW49/yH4hm/hXMEPNqyz2zHk4HGP1spPnOVld91fcfRJa0hnretLB xwhDWVfnWUm5IybjzwHGLlfzmfBnWVd6+3LiQcgdS67f1wcJJN2oWDsYL6+Gaebl WIUCf6tWxWS5z8HfbSUG =Ny6Z -END PGP SIGNATURE-
OpenBSD release with libevent 2.x?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, there seem to be a few people that would like to run tor with libevent 2.x (currently available via ports) but failed to build tor with libevent from ports. So I'm wondering whether there are any plans to ship any of the next two upcoming releases with libevent 2.x (instead of 1.4.x)? thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVsAYiAAoJEFv7XvVCELh0SpUP/AjKfLVB3ooIzk9SiO879hqM 9kLWn7u8lS9Tkyjb3gnBfbLZNFepKv2gKyoulHttU3eX8TOuTZ+/c/73vtWEYFep Z4J4mzvC06h8bEYHBgpeceCcrxCwO3JmEV1xUR96ghK6csrVgqegTaJJkIkoQuZc YpKfe5vH5AiuWvU9mB9qHnBPmqIrXTneXFxwDBW7Xrkm5EaU5IAiK7IDL10HSIJx RCIoqrJU/GPhQfub8+ctVLG0p9YAtd2Tp6A3BgoM5MQIi1k9CAdR8Vp6Nuir3fXW rkUly4FNo79+BKKG6orteay1zxevnG+9knkvMJPZkPuyx8PgBFvOplL+ENxjyI9Z PD2w6S1fnKE2aybu1R4SqDIVDnFUXwpR324l/Ec0YQB70X7EhGyJO0PN7FuGqB9y TOzT3a9XZjszdvEuzPCO4JzmccSnY5MEOqh3+AzBSrYViZQ1ihhGoYfpfLhn0cVY cyEvsjCR9Z9oemAadK0zpbXksDvNSOvmo3VDEkTBn8W1swE7NKD1/49Vgr1/w5Bq X+B4fkEQRMtOXHx5TO1vibFGrj6eA3NTNKHtdNJ3dVLpjZv8AExzUwDMMW3xMKCt YJ6jpC5Dab18XlUGFKMxxfBkJzSZvS5Ntye3MlwdF2LzjJSlxVbIcKIqq9j/xd8r rqbOQT7kXQeAafmlt5E7 =CRKa -END PGP SIGNATURE-
Re: bug in rc.subr: kills more than it should (patch)
imagine you have N services named: service service1 service2 ... or a ab abc ... Now you want to stop 'service' and you run: 'rcctl stop service' all (not just one) of them are gone? rc.subr invokes pkill and does a startswith match but does not require a perfect/complete match. What do you think about this patch to require a perfect match when sending invoking pkill/pgrep? Won't work. Carefully read pgrep(1) again. I'm glad someone changed his opinion on this. :) http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr.diff?r1=1.98r2 =1.99 http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/tor/pkg/tor.rc?rev=1.4con tent-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/tor/pkg/tor.rc?rev=1.4con tent-type=text/x-cvsweb-markup By default, require an exact match of the process name and argument list. This allows running several instances of the same rc.d(8) script by just linking it to different name. e.g. ln -s ftpproxy ftpproxy6 echo 'ftpproxy6_flags=-6' /etc/rc.conf.local This is likely to break some rc.d scripts in ports. I will try and fix them all in the next few days but I'd appreciate reports if I missed some. ...and yes, that was exactly my use case ;) I'm also linking tor's rc script multiple times + custom flags. https://github.com/nusenu/ansible-relayor/blob/master/tasks/configure.yml#L13 8 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
out of memory and login.conf logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, would I see any log entries in /var/log/messages if the system runs out of memory and kills a process or if a limit in /etc/login.conf has been overstepped by a process? (OpenBSD 5.7) thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVjBj4AAoJEFv7XvVCELh0ESUP/3m41275y7E3vzQRRzJAO2mb +eqxMX0ReAv0h+gchJw2KnPD8XvseFT9MirNd+ucuwEyQltTOP+7sBQpDkMJz6Vj 8O63uMM1+ItALebUfDJoHJdsnL5r57t2uXcQ3bDUE7xgv+pjclGjnVl0ZXvqHkC0 qC6U4d09Hodxzb+yyFKFG5JzIOg8fRKHlYGMlbWBSgYLc9XytkqVpJaq2atfNLbl YNHQUwntst8zEV0dQwpTHeEqMutar8WQwUomj+U/VdZfGS1kVgdqUZOiYW/rdOLR GG6n9kvH0b3DL8PosKk8pucqkQ2lOLMt5t3XFuxbXtZjcK+8DF+sa1AfpHSNSEPR 8xdwVNRBKXCrflUOa7nBhbcV9c8ft/H8ZSuB4TAvJlGCV7Nn7iM8mTvhO0ApuGt3 vEPts6I8lUFe/DtyMWI/VO3UoAWVG/cnkndrcAafGusAs7rB+kPyEIMvzE1uhaf8 MbEm2GkyB0wX8BjxNzZil1QO5LaLijLbeeAxKuIBcVyjdvDwOw4wFCuEip+mz6ZJ /76ARfYOcAgVcGFtLTkB10PN3xAN4ZDbEDErR6fu8/2OamYyDVqV8DSjNBbn6RlK QRti03LIjtaqHIDEhkIY44EDJfm4GfyGuBg43PM6+TwXFPzYc6TL3L5ImQT3cd6n RK7dbYESSOo6Dohy7XtR =anyZ -END PGP SIGNATURE-
Re: out of memory and login.conf logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Michael, thanks for your reply. would I see any log entries in /var/log/messages if the system runs out of memory and kills a process or if a limit in /etc/login.conf has been overstepped by a process? It should be easy to test this yourself. See login.conf(5) and the ulimit section of ksh(1). Yes I consulted login.conf(5), but it does not mention logging (I searched for log in the man page with many sentences having that string in the context of 'login'). It does not say how one would enable such logging - if it can be enabled. Or did I overlook something? Currently I don't see any log entries as soon as a process hits for example 'openfiles-max' limits. The first part of my question (out of memory kills due to insufficient system memory) is unrelated to login.conf - I assume. thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVjDa7AAoJEFv7XvVCELh02a0QAICUJVerhY5kyxYoilRq1NQA GAc/vLuZuLEsHlVrFCrepSQg5wg47CyEThkEJSIvi0Zn5DlAt4OfmRQmbcd3Zi0C jZfu4zpIfblCzZSwg6RZpmdsurdT6H8fu1IEQkiUfQxId/H4WUpafA9wfHV211DB VoG1A6Q1oCizqGx69vJxFVjVgllNdEeLL+9rysogZ2AO42pV6TuiUgzYrB9H+jyO y4F/igUr4GB0t46GxHQySwjgD3HIfAHvER/Nva0A2bxUSeniJOzRPsAkt4mjAo+c Y+q2TeDtdtRXaFf9y+Zl7HfEnJz+r5EoL3mJRW1h8+0J5qIh1792quYtrYkmOHPU VRjgX6rtBGu0BDgdd3kDLE8Y0PKVMJAt4h10h4mGVC/pKy8c902g51lWeHd6Lbn4 HBxbc4F2yqy2vGorwOSqOOacRIIAIQcIRuCyiv6J4lxkGJsPj/3hece1gA8rbLDW lP3SkDxbdvWoxyK/QYAQXQXWyqNXQU3NEzQHozJL+j3bNVlK/HZwbQ7TARzkwG3v kc04sD6oMxNtecLmSXpiT98VJBn0A3pOVdSHsjGlOS467Z1FSh8s3cNCbvZCvkDY iSGmUyOPEDian0DrN7FlmTEuZUNMcwVZQfmVJadlbV/Pq613YegA4HJlGmRku3TI +ic1EC7Bzp0Sj75Cupz4 =ayEa -END PGP SIGNATURE-
Re: LibreSSL enable-ec_nistp_64_gcc_128 vs. compiler bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Miod, is your statement from http://article.gmane.org/gmane.os.openbsd.misc/218944 : Until someone spends enough time checking the various compiler versions around to check which are safe to use, and which are not, this code will remain disabled in LibreSSL. still valid, or was there any change related to this? thanks! nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJViCsfAAoJEFv7XvVCELh0hUgQAId4zCj9vKRwU4Cf+hHIYbdu jgBLkXJEdt744jOvFj5pQG9HSFEPJaF0maJt/3OMVWDmiI/CYIHCzkap4nQmWMWJ 6afaLp+Bi5LE7mNY9BrZqHP5oYv4LBxYvpu6tJldPXM4ikvroXLX8wamlZNyIVaX oX54TQgb6l+oLr5eIziwbH0WGdtCQmpzvuNVCqu8E+xi2n/gYuW2G8M/hBmcGFMZ JFifz4JFIv1MLzwCGxa1j9ld/Nmz1K8a2ncOoHyrROFfMm/MteQVhCJyBIXCtbAP CbuB4bPm6ac0ndgU8Ny+EXHwUndCgIBqd1TBlRHsTmXIS65MguyAuYjmBPATjE87 6m9OhKvOdNEl/z3BAuNo1kv86AnY8l7NK5G5iPFPWroIDlTUIfsO1DEe9wKccynv xuWSj3+mkhwTKqAit/J4BpXb/HOeFDTdI9C4yBGdc9ZtRM5beQIat/fn0C9PwtZy W0f9zigqXmqcjTR/dYJwOvTpd3WEFyS2zkn4nEqn7rDgft6E9+PzcmHI2gqLfkm8 WsmIbM9jgOElSfM8m5GO6QUPuy7pl2jm2eJZMLAMg01R/bKwUbUdNRmqmw882v64 qvXwKsot/LqNQi4uWb44ktckCijsx3sxdXcHFXNMsHPRUBB7hfSBnZ6qg55o/lVt JFaj93ttXOaIWsDORMRO =OcXC -END PGP SIGNATURE-
Re: enable-ec_nistp_64_gcc_128 available with LibreSSL or does it require OpenSSL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 when starting tor on OpenBSD, tor complains about missing accelerated support for P-224/P-256: [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. What is the preferred way to add support for that? I'm installing tor from ports via cd /usr/ports/net/tor make install on OpenBSD 5.7. I found this: http://article.gmane.org/gmane.os.openbsd.misc/218924 so it should be available but it is not enabled by default. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJViBDHAAoJEFv7XvVCELh0qLoQALJw19Y7iVmrKMdJBFn81QlN 9e3sO3ORIF8La2hahx6Acm94qVfYzyjo4qha4meG/uMLpKZ00IcXwHxtfyqpBH0S NvLqzCV/tnk31F10E/mJnZCgsAbjMkjY4QacMN3X8ouUh9TjgJu1ZVEQNdY6VwkT khNdppupIJZUkrIp6tIepgY2J0gMEj/XN/3Btswyhaj//3pTB8D+AwN6s8wMmDni 4mpmPCW/jeXJ4cmoCKPo+GHhAazvIYJ/luiE1F7Bdtalmiwpev4Ur8YHNBzQLMuV LXBRzy0lfNiyHhsWwKwALS2o1hEMQOVHjbnE6E+helRTTKbGyy9a5o+vDItgLJVv E9w3FsVOO+poxfsw7xyluL6q6wM8R/6IhIBpDmDsmR7BZKnbKHgT2JvBkpaqUioS cs7dh43GJHkT+mXEVmY+MyrB7yUbVIcZrIKu7qwGPzEKP4fF7QmhL+zKwmMnGQcu cclmSI6rQ3fBtYzHTnTjhQBGuPlVJMiJ78jsFl6UUwnCw2qBv1R+7aKhRCyIaZBj j9Uz5ORHw3q4+21/v8njCI+SFEFL2XGJpribPCSn+aTuqmnVjQWd+ds2CHuzJ1WE Gt4DBbt4k19jNp5eGQ+F6n8csbTdA0IfRB5twV/nsa5Uj4GuWex4sT7p84ON6a1/ bgqo5wYIu6suSFUrqf7B =yd74 -END PGP SIGNATURE-
Re: Puppet and OpenBSD. Any examples/experience for unattended provisioning?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Unless you are aiming for bare-metal (with foreman or something similar) and if you are open to suggestions I'd say try ansible. +1 although ansible is probably for servers that have already been deployed and ready to be configured with services. Both package managment and sysctl configuration is of high quality You are really using ansible's sysctl module on OpenBSD servers? It isn't supported yet: https://github.com/ansible/ansible-modules-core/issues/1233 I'm missing a ansible ports module for OpenBSD. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVh8JPAAoJEFv7XvVCELh0AHIP/37VDFu4+D+sIZV/suRX8xJY r93l43T/hJ/0g0N2HcgjGujg3QhCVe1272BAdlivMKaDcQNm6Taxs994mu+5VE31 VAwMIDtc9TNCH24iDTx+oucr9rsotEo3posLfRi1jNFexFReSmPVX5w/PNlbXk6G IuME4Vvzsfko9sJUEKFUg6D5m76UqBJcS50oEoSDFx0BRTPeNlVxr/fyH7ujIPwy pmK1H2uaTTn7YWStEQUl5W3WlZnUYoVfpx9tIrIl6PRrggUWPIKLZpUiYoOkf/qQ dJ08VIg7oFyNXW6I4p3x3QGoEg+L4ey87STp/h0dKrNISr5Dl23ZfGNQ8tIC1ZTz t757/ff55z5VRoXdIjKJT61uWSwomPfduT5Sq0RNd4wPE3eIF0GrWoTIZBj0TDJz 1xU1cFdJ+WdJF+YUSEMZ7rtQFU4doDLjVEgJ1+MnuYZQUfQs0aixI8ME4iKtX4f3 By7mw6OjvSHUkHLgFiUFbyoD6jT1Facan8uSdkWnb1XVovx3MVtUaapZyWuTPyLq iyTH0hltfJvNqIoEF7OeETYm8diqhpj5TAIl3H3lBW90w7TvNdc2Mv4TyDCWe3mH n/3rypgdS5W2Hd0e4pRhpf4NfJ/YmRhdcR1uq6V7uvgm9gDIb3O8jAXhV2FoDgV2 wBa/F9otd7FqXuxptpCF =myS3 -END PGP SIGNATURE-
enable-ec_nistp_64_gcc_128 available with LibreSSL or does it require OpenSSL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, when starting tor on OpenBSD, tor complains about missing accelerated support for P-224/P-256: [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. What is the preferred way to add support for that? I'm installing tor from ports via cd /usr/ports/net/tor make install on OpenBSD 5.7. thanks! nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJViAtdAAoJEFv7XvVCELh0OV0P/2LMJa5TV2WUhhxRyUEV0GFW 5LRet+DMV9zVrqj7i0wWyY+t1ZRYof9EKHiygn54CZkSw72LVPTrqdOD4ZgI2gjR Z3CvoOXfoBsRr4NvTjHOjmwbNuHJyzLRwiQRvUNVE+a2S+h367RoDBKaO3YOLvwe py/KS1CckInxxDOOTlL2hsfh/Cy83lBF3z/EX5AbM+atkJz7cZYiI+ZDRoIMjJI+ JZwrhavLVd3FG/hIY60iiSCgLSNqZ0+cPQB36+k4uJOmHGdmmEu94RXvviDQP0ZV cCeHVJuPmtNGwNErocMIlCGlcrAkiL0k/t51pVBgGsTI4GhKjxj44Y/txRSCWm3g 8n53pfyWiLD7xiiWstPgu9ncs1oaiGWACggBdXZsi5zqDDFwDnrz3Itj9ZzfZxif 7TkC+Ez8d299AEPgNb8gNBtqptbo8DARmr2G1IO0NYE1MszEl+biY0DhMdXFtfGI whpT0Qs1++oluhItZAAPY27Xnox2CrSkFWDpw/PLZd7nkp3Rk4RtM3FhTv/7zqul +JJvCLq4fsYSiExfT2m7qFaScKkTuOVjWZsOLAVafGDWCFys+aBdRA3HZAQ/WARv MxGeqOMAJ0mt9Zo3e8Dow0I6pNqeCv5aGdR5VNM7VryX9FjvWLWYM7EJRWefjBH5 9VWz5QKAh5/H1TZxlAju =E0Bh -END PGP SIGNATURE-
Re: rc.subr: $pexp does not always contain daemon flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Jun 16, 2015 at 01:32:11PM +, nusenu wrote: Rebooting (without changing the config) solves the issue but is not really an option. I cannot reproduce here. I can reproduce it every (first) time on multiple fresh OpenBSD 5.7 machines. I'm using ansible to automate the entire setup. I assume timing plays a role here (that is probably why automation matters). If you want to try to reproduce it (on a test machine) with ansible. You can find the ansible role here: Thanks. I will have a look then. But do note that I am using current -- so that may explain why I did not see this issue. Problem solved. My ansible role reloaded the service before setting the flags. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhY7/AAoJEFv7XvVCELh05gkQAJXcLrxnsVtLxTeyuv4MCNPL 8pUZ+L4I02aPtCruozvSTVTV1+8kV8+U+wd479KuZVh2G6gTufosQT9twNduRdIY BVxhCe9vD842FZ9AVNLs1ACdWmrAW3zwdoDqm6AXBinEoCo92JjElNefYGxJdHFg gi9HSJPz+q2OYjetHejCDmdqGi4MXQ2Un/J7hm0+Gey8/1UeWYKQ6I6Opob0bwzj DUX0J+aRKQ93nnRkY1LPI/KPi9E+XrtratGkaDAsxEKO57nzgPkRv97ROyHD5DN/ wk/EZNdsCKuYFcKsdN5BprXP5AWlmC+Ci9G4fs7/4irAY1BbVLxrzeQn+Hdy6JG8 hjNqz4/Xg/pIGuoOoMpf4IU52XlRjt5B9VWdFcwL+1URftk2Z7eXfTHmBs/KLGtN q/BWte6a0J1Bxsp0OpM5E66KI8MvoQyk2zZiFAPPfpqtiN5bAc907xzyFX9hwWd5 4RytEp8aLGsXNk5rVuMXcTrL/II9sYdkGXaZyVtrNd/i/vDzt2vDwkk8/F/w2eTs QjT3aUR/s/Fz20BYeOHKhLi5T+dP69iMYvI0y1aEKMST5nYUZs/ZkjhSrCr3RheD zV3hR8MPsmyt6f5/hvSYlnkS5yH4ntorFuIu2YSb9Hwfe7SFLY8X962pioD25grQ cSNqs88bMaaTOmsignyt =nLZJ -END PGP SIGNATURE-
Re: bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 imagine you have N services named: service service1 service2 ... Now you want to stop 'service' and you run: 'rcctl stop service' all (not just one) of them are gone? rc.subr invokes pkill and does a startswith match but does not require a perfect/complete match. What do you think about this patch to require a perfect match when sending invoking pkill/pgrep? Won't work. Carefully read pgrep(1) again. After reading the man page again I even found something more fitting: -x Require an exact match of the process name, or argument list if -f is given. The default is to match any substring. Since it seems to do what I'm aiming for, could you give me an example for what won't work? thanks! my tests: # ps ax|grep tor 24508 ?? S 0:03.85 tor -f torrc2 19493 ?? S 0:00.79 tor -f torrc # pgrep -fx tor # no result expected # pgrep -fx 'tor -f torrc' # expected result: 19493 but NOT 24508 19493 # pgrep -fx 'tor -f torrc2' # expected result: 24508 24508 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhWugAAoJEFv7XvVCELh0U6wP/0vOT73glYbmFllM2WlLLCqF 7PAovqHtwI+fqYeD7rovfHutOXkLvw4AYGEAeCpsP+og3WNY27Qh3BtVpWY/eNI2 N7FlBSmMBmD/QJPArYkQdmj8C5NTgkHwjUoFfOaGsf/hHIIiqunT4ohkYi9+XbPG LW8i/aqL2MCpMhQJn6isMsVpdjLp0Vf7A1n0BuR03cwwzO/Ij4xkZFubmdj8KOSv FZy5SjNDPteTTOFPxrvR47Nuz6ztPAo1BWmHdr9E2acLyvervN5dcKuSHNMitZrH fMwSgo6hkcu/Uj36fybguMPasvfCwS6Q5rD7D0M6MjuQDFfBw6mOckbcr//65iK1 n4/UDU9VyT041Rhjq0uXVIVNmbpHbKCSUFg1yBRpRwJSE7Lx7QDRF152y/v0Ble9 qa28bkOfhSbGwbDwasg7sP7CsZrqI7ebyQNVq8jxDrR5B0wM4Wkpt7VcGTRRgvhj clAl0hhUNxlCI+TGRslaWs1O839m+gDS6Lf3eaoEMSrWdKrBitUsISzZykPyoSu0 pNVQQtWFkII+CyP4E8Vh5HM8WQp01odEueOV8Vf8DUVMV14WTd9nAbILx2KEgNU5 aRvXolxtGQfTW94UN59e9LJWRm0l7ikRoS7XKJ/ZQQd0IV91AySVrl6OFHybrk09 gmimAMIHiQkuhFpu4TYW =MTr3 -END PGP SIGNATURE-
Re: bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 What do you think about this patch to require a perfect match when sending invoking pkill/pgrep? Won't work. Carefully read pgrep(1) again. After reading the man page again I even found something more fitting: -x Require an exact match of the process name, or argument list if -f is given. The default is to match any substring. Since it seems to do what I'm aiming for, could you give me an example for what won't work? thanks! my tests: # ps ax|grep tor 24508 ?? S 0:03.85 tor -f torrc2 19493 ?? S 0:00.79 tor -f torrc # pgrep -fx tor # no result expected # pgrep -fx 'tor -f torrc' # expected result: 19493 but NOT 24508 19493 # pgrep -fx 'tor -f torrc2' # expected result: 24508 24508 Some daemons will happend more stuffs to the command line than just $daemon $daemon_flags Then $pexp should include everything that a daemon can append via rc.conf.local settings? So this cannot be used as a generic solution. Wouldn't it make sense to use '-x' by defaut in rc.subr to be more strict and less likely to unintentionally kill other daemons in general? If you want to match the exact complete command line, adapt pexp accordingly and end it with '$'. Can $pexp be set via /etc/rc.conf.local? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhcKOAAoJEFv7XvVCELh0qVoP/jdy1m0vE9/k8qVQfmlPlpMz QiXwM0y7SoGThrDnALeCuPflVGvenTtitNj7RtaSDsJRTyFKRW+VOQYJO/mP/3u/ DdKjvuEe6MtrcJYBgZLrcQw3EeWZM0NBsfO3wscC3hoWkN6dDeoNGh2w2GlUqm0J 414QZT5YwAuL2QwSHOZjPa3ks83JK1egs+g33YdSml3/ur8NAHqUX9V2aAWDaNcv HPZoQEf5JIRcfET28RxGYFIswybSQW5suZ2hcXrImZcypuTXqGv+e4pXs9YI4Jc2 jaae+HGc5UDIZmu8yBEmhdSm4OG+em6CwiG4MTyFrPte9a+AoAjp8gC9LiiFqbWl cNv5vugMJZHsXlaBwE4Be/w69L8/+r/gSnepEnSjJhUzygDCyv0MzrwkEdvHnxzu 7YZv1opDFkuOjWMNhPKA73lIDW0qmlti2Xl3q4BHb2XlvPhvOtWn2t1JhoHDl+nd r24UdruJLfOv+oXHr2nObIr1KlBvZ1DaPxm3ybRsJvdFLzHmBdWGGGVerA8Jlcv4 izZuKjTqQMfA/J4ESdqoLbcHzY/DGm/sbB8Grmez0rCtAzuinKCauQ5zX9IPV8p4 IskuzIwxHoXSPNN74+ycN+3XSlc/at/y5KxJBT2Nuf5ZR1H/V4Vp0IkedkM5qhmL l4j33IkmBZAG7e7T1UWT =9Asr -END PGP SIGNATURE-
understanding rc.subr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Some daemons will happend more stuffs to the command line
than just
$daemon $daemon_flags
Then $pexp should include everything that a daemon can
append via rc.conf.local settings?
No.
Would you mind elaborating on that?
Actually, you need to elaborate how one is supposed to include
every possible options into pexp.
Ok, I'll try. My understanding was:
In cases - where the rc script is basically containing only
daemon=...
. /etc/rc.d/rc.subr
rc_cmd $i
a daemon is started by taking
1)
daemon=
from the rc script
and 2)
daemon_flags defined in rc.conf.local (if any).
from rc.subr:
rc_start() {
${rcexec} ${daemon} ${daemon_flags} ${_bg}
[...]
so there is nothing else included in such cases that would cause a
problem with pkill using '-fx'.
pexp incorporates these two parts:
pexp=${daemon}${daemon_flags:+ ${daemon_flags}}
In such default cases using
pkill with '-fx' would work out of the box and pkill would kill only
if daemons and parameters match completely, correct so far?
Using '-fx' would be problematic if the rc script itself defines
rc_start() that is different from the one in rc.subr.
Writing this email made it more clear :)
So they override rc_start() but still expect that rc.subr's
restart/stop works with them out of the box.
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVhdTnAAoJEFv7XvVCELh0EO8P/005u61VFjmCWs7BMq9uUDE2
H43/bsQPB0rC71GBP4pFru5B2387miQ64vkhubXO/xZ7AaDF+SW519cfybAT/oIQ
1CUd4sgn2VuliDiSTXEa9YA0XQOoWe9wBOpYN/WgMtlGy3d+g69wx+HVJrbdYtPw
fXFfRDgAiZ91GFk2oEJaQj3KoF3ZxKNCRmHfNYB8ZvdTLdP4LMR7QQAdBnZmLkR/
TvzrpNdjipSVW0Kq/zXHT7fOX0TiEg6KtpR2/zFpfKLqk8KjAUdgn/yJGDDQ5YTo
hmm9pGAfWq2nD2E2d9SkOgP2kL5KnX9p3Nod03IhbB40ILpVhvNEBlFdaEeu92Lt
7V3My3Wc1iz4cCAYkvlzKeJi4ayNZaW/T0MRXGqpB2ZCl3CNXHBBNURSKiHYgZQr
e1nuFE9+tVtiAgb8nicMLMPpEWQF6Oyv01+I17IfOGVdwn5xSLUwPVhDGxAEPJam
t2q3+9erZCrFA3o50xxZrG5JdmLU7j1F7k7m+bB+o+iKqR/HdbeqRFdAMfjD+oVg
2QAFWjHMQyObzbNW2BpvluP6y9QLZKXilP9rJuvdJMBFOpJZyrstqNExwtHKKBmL
i6BX9N9HwJ5qsG65SUBBVWxP8b4uayXhQ362ewnjowjFliQrfeiQELrZLNdXBlZO
Fc7XaazScxdYKMxXSbo2
=cUxX
-END PGP SIGNATURE-
Re: bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Some daemons will happend more stuffs to the command line than just $daemon $daemon_flags Then $pexp should include everything that a daemon can append via rc.conf.local settings? No. Would you mind elaborating on that? So this cannot be used as a generic solution. Wouldn't it make sense to use '-x' by defaut in rc.subr to be more strict and less likely to unintentionally kill other daemons in general? No, for the reason I mentioned. If you want to match the exact complete command line, adapt pexp accordingly and end it with '$'. Can $pexp be set via /etc/rc.conf.local? No, you need to edit the rc script for that. That is unfortunate since I aimed to use the rc file that comes with the package (or links pointing to it). -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhcbKAAoJEFv7XvVCELh0m4EQALXdPkbPwv6wbflfZUaOVWso gPB/HdWUvbu75bn2i+tqY/Ik8tIGYpRXcXRLMfFPRRAQashXZ0cAfEHaTP5eeD6r xmFOPuKVuvq1TI4Aw5CVViwb2Eif73jAJ8lxT+l8weR7nrbayZlk8658wHsZOsE5 2Dytch0lmwtmxdqY/Min6APa/7iuQN1X5DMssiMDbsDSD6gbSZRJikmuw05klRtr HGX6SJ42sgBMi/lTvDx9FN9BfldtPboYbKaSNpyG2cI9HbUA46qeIN63zp/G0zRV pQCpF4qCJlYO1oZmMFKl2p7jDHjB8wo0FBMz75aCep4aZPT0KJeSSopgvCGU21Fw 35Jjpf86qW/XUtsfFGkLR9PnqrHA+HZmGK8jCcC1Y6rHsZx8LBDjZl624TWOhDZz uDA1TuNG8IFStc9MvDDG8Z4NFUmXKufkhY+Voy6GLdMQ7rt4S5g3tFzry9O6LBQA lXTIZDasaDfa0MEQ49Jlm56XXw7NTcYY9N6v5siRLMY1mdTPhqe+b4vT1Y8Orj7Q YVM5GvnldUsR0I8PrzgZpQLRC8WdyaEJni0C21T3spP0maXLj2ESgSEaOMCnz1Rd FbxXD2uxOhF/ya2KecAGtnQxz40J+NL+wPIH+/uA2kfm3AEqKJ68Bxrsht+p/RqH UXzDnwH/dhAxKOSYjB9H =c4F0 -END PGP SIGNATURE-
Re: bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If you want to match the exact complete command line, adapt pexp accordingly and end it with '$'. Can $pexp be set via /etc/rc.conf.local? No, you need to edit the rc script for that. After thinking about creating a custom rc script to explicitly set $pexp I realized that it won't solve my problem since that safes other daemons from my rc script unintentionally killing them but not the other way around. The other rc script (that comes with a package) will still kill my daemons, no matter how I define pexp in my rc script. Is there a best practice - way to work around this? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhdwmAAoJEFv7XvVCELh09skQAJuwKnc5xPRf3PBdtmcDBIrV kY/tusrnfosWjXrT4XmbGJSIzSp49u16OZInZr7BZ/aw/fWuhJEJaYLRerF3IkGn zrjn6UBs0NpD1K6PnMlX7UuDu3zsUjnNpiVmIpbo3ZhVS9VE52lyrUYbgeDn9Gkd +fI5v13/eNoZjdvtiAncikWOZVnG/EwTg/OnB5vtiVXJj5Gjq7XcinO3ymvkSHlF 6EhVyRM7ASUhpYqtF5tRvn5kMsdyrv8CfVaeteGudyhXJLs8+hVKCrRD1BhiHUqV D2FwDtxH46rw3xggP+DCSn+qtxNyxCYxTqMowzNwJVnRz7UbxorWoT4MowPylZO7 D+r7XtoVIy0AQj7ekyJUaSRSyt2k/A6T48zIYc5IZg2j5p0zkk4m2+Bi/5TkZcoB cicGpkP96l/2Tj19L70SDkag5HX247xg5d3kcp6kWpeA4LnCWj9KH19Z/mHeTG5A HPG5yzWz/WtEaSZ/3m12VPAIjpePEQ1Z8wKvQYgFQhbhJ4ualaaRXivAZsrwaWN4 vG0PnSChbKc+Prf2I61b9nU/oVLKazEutqCSvwTwSzIZYXHQ6tB0iJdhCfkVOVau 2h/S+7GEgRfTMtFCWb6FRpegOpksrRYRNAnDhDGXJvNRrOUQCVm648m5mmOZigCg 2yu3feYu83pRfY+qXQ7P =hGUH -END PGP SIGNATURE-
custom login.conf settings for multiple daemons with _one_ config line?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'm running multiple instances of a daemon (tor). I'd like to adjust the openfiles-max limit for all of these tor instance s. 1) I changed the _tor user's login class to tordaemon # userinfo _tor login _tor passwd * uid 566 groups _tor change NEVER class tordaemon 2) added the following line to login.conf: tordaemon::openfiles-max=13500::tc=daemon: That does not do what I was aiming for. Having a login.conf line per tor instance matching the rc.d script name works, but is there also a way to achieve that with a single line as well? thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVgDERAAoJEFv7XvVCELh0YvsP/ifDSkiGTXPvYXrTYhqaZEvG wIN2NlVVDr3TrXonPHp+3QoxFRi0CYZniD4Lg1Guw7iyUiNAK0dh4TRH0k40m6+/ HAQ4EPVDLtPjNwu8kC7I+dpW2m2Q2nUA3Wl1fSPdRhFqYIELNAj0jzW2Imtrn3UN CQnGhzBfBe6XAJzA70Bd9RkcYWHrJ8FvO3zipO/FpN2p9ipr+LsmA5R2jktS9mC5 MJjc1dGwIXT7EcT/2V21QupvRjTEVM4G9zAQ9rN/mtfi5MkPQc4XklPrhj9mxubX y8A2v0mav67chTVhN1r7pWtJU4Pw4wDqYpq7M8VF9kYqQnKyZUh+IniFfK7UDMRB +0EUXEzjjRlNfkW0RSGD3mRnvjloN7VIwVi4Q+vQz4wJFep9ZC+sWdjdJsUDTYaK YmlM0/hYhckuqGRYsJhQrMdbIcnJCSSBEabGkrJ3nE3PEZvuwCNm3IcqH7EfdLib b8OhRswzwNDO5LzuJc7LpyTnEZAPQ/iEZ0L6OmvtO9pwiq3GPj6XKHXV3G5kr6zq UnIjOeS+YvHMFCTpCv4T9ZdwCueO9Lti+oE4nJEA9DSRILFkIi7lMDUG//5pUxKm AgNe5Fe/FIUYpQH+1/TT/F8koov2zNd1g2Gm3NU0Lt9xfH5eozLAm429+wTvxKnP PG3c3nWeugn0pETCbvxw =He7O -END PGP SIGNATURE-
Re: rc.subr: $pexp does not always contain daemon flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rebooting (without changing the config) solves the issue but is not really an option. I cannot reproduce here. I can reproduce it every (first) time on multiple fresh OpenBSD 5.7 machines. I'm using ansible to automate the entire setup. I assume timing plays a role here (that is probably why automation matters). If you want to try to reproduce it (on a test machine) with ansible. You can find the ansible role here: https://github.com/nusenu/ansible-relayor (dependency: /usr/ports has to be in place already) running the openbsd tag is enough: ansible-playbook tor.yml --tags openbsd but I'll also try to provide a reproducer without ansible. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVgCVbAAoJEFv7XvVCELh0jewP/Rfsallexgu4DaiC6tajSecp Of7f/XkcO9Ag9O2MO6bZrkZy/tr1SsMXUPly1Ewb2KdlyjUsYLy5/CLy+BcTLS11 gel7xMPkhO21i7udbXQFX9IS2tSlwJ/pHZLvgEgXZSQE6xnbprPJV9LzMPoSG2e3 +Z4hR/iNv78L0MwPnTe4AfNg0mNYmWclPJc7PDI29tm1dDQhgNQZculqFp9zdTvJ ofsxqvd5j+0mYnfeFGwCbnh58j0zST4oB5mcijuVLVICl9rjwcZOrDG1cGfjbnhX ke4gZCJxPxqOvR3lcG4xemGILi2AaIu7raxBBEyuXAZDx8Ty4j68haiEp4Oo1DoD s6adSKQJrSDBKst171al/CRmbd9HI+KVY5/PMp3tYTfxrgVn4RI3Ax0LPLKA/qa0 HZLoKC7FKrlOVVAvdvUx1uaVlYdoZB2vfYDYzLh+9J4DuUQuUyTbXa0TqtsLR3oR jWGOOwP2SvBGxztigbDBEBEg7QKAW9C7y3on/0TFYEvQ8FvycuvomRpq+/9zVW8H c2XIYMzMX/Tji5nkpHhR6hVjbL46rkSCgLvsLyTMES4OS1GozXAH2m+tAza8yBaq iSxSsJNDQKn+sJYWEh4Cgw1VnOKAf47JQ3tAKUpjKQrUSe+NCAM0yS475ZnCE+W1 yS62+HxyxC1YXqhMb1oL =lZr/ -END PGP SIGNATURE-
Re: custom login.conf settings for multiple daemons with _one_ config line?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 tordaemon::openfiles-max=13500::tc=daemon: That does not do what I was aiming for. Having a login.conf line per tor instance matching the rc.d script name works, but is there also a way to achieve that with a single line as well? Well... yes and no. The rc.d(8) system will use exact daemon script name and will apply the matching login class if it exists -- if not, daemon will be used. *But* that is only true in the sense that you cannot override the login class using rc.conf.local. If you already use homemade rc.d scripts, you can set the daemon class by adding: daemon_class=tordaemon in the rc.d scripts. Thanks for your fast answers. Actually I don't have homemade rc.d scripts, they are just symbolic links to the one from the package. So I'll go with the 'one login.conf line per daemon' solution then (not to bad either). -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVgDR2AAoJEFv7XvVCELh0otsQAIl9yTkUdLPV7csn+EHQ3xF7 tQQZUKQ8HRGxdRWfd6DQIDdEecNh4FI0WrFmdZNVBW5bOQVha8t18AGj4hXTnqgJ IXwGojSwR33SxWQoOz5ipAVre5v0NFwbYIfbIIdIbf9c4d5FX5WQuf6zOS7TDCc/ F8ae7NDKTQC7CYQyaf5lFTmMwCVwyiaqRzd8BVKG7xlS0qFGeaTvW277ti2RPvMj mG40CYqeXCvdQ5fQ8gBXN2Fb4NHm21vWAWD+qUMtw5TI5JqheVfzZeVD9M2GOsV9 1DfPaKvSdgWm0Mb50kuzgWvTIfnebtUkMbOlJtbALID4OSPzVvsI6CwCES7HaB9V v/VnFvZylU5k17O1Bi2ui13dgPdGZ5UcDySAVqvVsA5pW5j2fsv4UpViwaHs0vAI MjdEXwRN5JfLtbqLaXaDIUr4XPjmy1bIidn/Re3joct4V/N0Bq0lvJviVn6QwYCA y4Dvuq8f5D4p1eMEkBekkUOxWSiKxPMefyUcamdD9X3OtzTfCDvzPjKhj2G2NRsa clDsb8VP+lssQe8fayH9VWujvZiDuLTFfIZBlxNXPNzNntlQyOPaGfa6ZT04Go32 6AiFCU1gG4ajZfuVdMGsnVp92XX+GgzipaAwWsu5TGXjykGJ1xamTpL4h2C5RKVa S+A2kq7j4/cGOQpDeiHG =VUvh -END PGP SIGNATURE-
bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
imagine you have N services named:
service
service1
service2
...
or
a
ab
abc
...
Now you want to stop 'service' and you run:
'rcctl stop service'
all (not just one) of them are gone?
rc.subr invokes pkill and does a startswith match but does not require
a perfect/complete match.
What do you think about this patch to require a perfect match when
sending invoking pkill/pgrep?
@@ -150,15 +150,15 @@
}
rc_check() {
- - pgrep -q -f ^${pexp}
+ pgrep -q -f ^${pexp}$
}
rc_reload() {
- - pkill -HUP -f ^${pexp}
+ pkill -HUP -f ^${pexp}$
}
rc_stop() {
- - pkill -f ^${pexp}
+ pkill -f ^${pexp}$
}
rc_cmd() {
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVgHs0AAoJEFv7XvVCELh0APwQAIGVUfu+g4gh/WJkvZHbBRgg
u5qT1AlSDCDkDjBtfAuat+9M6mMHhDsvoQ0qaN3a7us4Ib/I3agIeJlXWZrci4BG
2i/AsKmdy/0pmUP4XgsodGP+GyaGLgEa3QsMSCnUZvyZeWrU59F+phVXTv8qyq0a
JkrI5PtdxdleSfVXzlZYo6prooKHMdq7Dkt1pO5oLCLLJZsGP1TffbTBlZhekrzt
u8TG+aWEMtdVllPIdyqNmPelhLuA24jShAPKI6ptowE5oKdD+iBof+4VZGI/2pU3
H/8gJqJqvUETaVo+8SUB2XMyWMfQf7LphaCm9u7PpbqBXsUKYrqxVY01E/FzPWZC
QPDo3P8mA+bJYHZ+PZq7o8akRYvIQYWSWZPJ/ik90E0hs05W/Zy2YVWM8EOBeOJM
/bz+Nl6GBsTnzOMbUmVlpHyE+7MXRorJXigOkz09Z/dIiI0oAiGqSkt87OABS7+T
ZtsKug55j3LV5RmGTqHyVlHJ0GwFi7O/UzHqUey4PMA4iVi7h3ybm4fxynFvpB7y
OQ31gFRPVloZyDodalnFdIp+Nhuv2PZz9P4hvvnyQU617gCLPpTNzJ0o5d1OyViS
iVSwFtyYrtmrmEhRKAmd9qY8R8NumPHEimNjgENDrZwsCnFJ3QSWLCGPTqqMlV76
WUPxt1Yg1NKH0gVEJih6
=kbJl
-END PGP SIGNATURE-
rc.subr: $pexp does not always contain daemon flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'm having a problem with rc.subr to start two instances of a tor daemon with distinct daemon flags. I'm simply linking to /etc/rc.d/tor: ls -l /etc/rc.d/tor* /etc/rc.d/tor /etc/rc.d/tor192168028443 - /etc/rc.d/tor /etc/rc.d/tor19216802880 - /etc/rc.d/tor /etc/rc.conf.local contains (managed via rcctl): pkg_scripts=tor19216802880 tor192168028443 tor192168028443_flags=-f /etc/tor/enabled/192.168.0.28_443.torrc tor19216802880_flags=-f /etc/tor/enabled/192.168.0.28_80.torrc the *443 instance works as expected ($pexp contains flags): # /etc/rc.d/tor192168028443 -d check doing _rc_parse_conf doing _rc_quirks tor192168028443_flags -f /etc/tor/enabled/192.168.0.28_443.torrc doing _rc_read_runfile tor192168028443 doing rc_check DEBUG: rc_check: pexp: /usr/local/bin/tor -f /etc/tor/enabled/192.168.0.28_443.torrc (ok) but why are the daemon flags not included in the second case? # /etc/rc.d/tor19216802880 -d check doing _rc_parse_conf doing _rc_quirks tor19216802880_flags -f /etc/tor/enabled/192.168.0.28_80.torrc doing _rc_read_runfile tor19216802880 doing rc_check DEBUG: rc_check: pexp: /usr/local/bin/tor (ok) I added that debug line via: diff rc.subr.orig rc.subr 152a153 echo DEBUG: rc_check: pexp: $pexp Rebooting (without changing the config) solves the issue but is not really an option. thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVfvZIAAoJEFv7XvVCELh0KrcP/jN78dXKYGY+Xf0BUBb6RaNp hE8hRdqO00CfrmzyA/DvwAWej2PJaO3QmjGxLam538K1hQvUILqW4EGQSASjEQn2 IiuBFMlQIxhBqwRrolOdMNdmfNhNqpdsFDLX/8TvEDDno+2FUIlidPrLRrhdTI6s Lbxw0BgvhR00Y8n1jk3wBKVXXCOQlNs6jd1x7aNWR4yNuXGLtkcIIZYOQ6fojhJc d/InkJUfx4F2EARfKOSs8e4727ROahWEKYbhEzxyTfw8POsAUC9eF2roiQRtzYJS 1LgspAcnbUUUF85hMtMFZK/sz3jgCl6BqrxtLWuj/lcXZ7EsLC+EN8zqZiBwX9oU vG4c+tvs8HkLeqq+7gCN382uZHjjY8LoYYQkzbSuLxjOdotQwnEpCMEv1xbyudq0 X+pPPFIADRtHRKVm6YjfltQv0C5pff5cNbXP5EXDnsFLqbipXdn9RIVuEQ/P9onQ hbwJrHfOlJWN2aGSljtbiVUV610cZWUc6kHu40LGnLwdiGzVFO89JntXzyfXPQuR NrVXbeG1tS9s1ApSCjkj8VNZojsDBTDt/Jt3eWNqC3q+b7d2OgXr+9HLBpg7J7v3 WCcwVu3DYjsyTdJTtefGDdA/La5ihjwvFMBq2BYTLgatpUyO6ffrjTac5dPZg8Er kzv+VNV0nVYxTGGabWMq =SiB1 -END PGP SIGNATURE-
rc scripts naming policy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I'm running multiple tor instances on a single host as part of an
ansible role [1] for tor relay operators.
Since OpenBSD's tor package does not come with multi-instance support
[2] I simply copy/link /etc/rc.d/tor for every additional instance.
I'd like to use IP_port as an instance identifier, but that is not
working:
# cd /etc/rc.d/
# cp tor tor1.2.3.4_22
# rcctl enable tor1.2.3.4_22
/usr/sbin/rcctl: ${tor1.2.3.4_22_flags}: bad substitution
Looking through some manuals I found rc.subr(8):
Apart from a few notable exceptions, rc scripts must follow this
naming policy:
1. Use the same name as the daemon it is referring to. 2.
Dashes (`-') have to be converted to underscores (`_').
Replacing the dots with underscores works fine:
# cp tor tor1_2_3_4_22
# rcctl enable tor1_2_3_4_22
Should the manpage also mention:
3. Dots have to be converted to underscores
or is this a bug?
thanks,
Nusenu
I'm using an OpenBSD snapshot from 2015-04-02.
[1] https://github.com/nusenu/ansible-relayor
[2]
https://lists.torproject.org/pipermail/tor-relays/2015-April/006742.html
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVIE4ZAAoJEFv7XvVCELh0u7UP/24U0E3IYED6lZK2EQ54oxZ6
KP/wkAFj0/TfwML37LlzQdPMNXnnbu04JdJO1+etLcbPyda3xXWnNY9NwQPXV1Lg
MaUlYD3E8nQM1poAhA26JE+VYtw6ySUMcJO1xh946wZGQSnzYIJ0CCpMsk4rwDnx
Onc80UsZ34IMiSEZx83Qk8vzLHSP9y1SdmwzmLNj/Q3MLAJ/00uWT6d39JQnMT0a
6dghGLGu2gmwll0NLv8J4utXiRlcPozCDNHMg7RN6vOEhj7AHCYMzjMdhU1LYSCR
E6ekBjAeDoTw6ojaJW/0UvDVCqdtBg6HByJQ3uuoEYJAjUAYNDR4A+5VdWuYPr/6
8oYXMeMtP3sIBoh5mHyVQz/YB1TIyJ1l2sT1250KwVRAsjxLLYZ/GYJySAHplc94
PFjoFoNZkNmxW9ecbpuNVzlS8IgOBwuxuYVZa6QbHnSiaKMAGmiXT7QhWO02NYNP
97I36I++Uqn8ZxMWRbfYJAid5uxVa3ZXtVYYNmKdAqpxRNzQS29XvgZHLcV8pTHH
KHYJdWKdlfq40HTD7+5KqtlqwREXub5i05VfMtLpyKSRF6s+VCe16GZnaLUEhEFP
QAopbCKSfyh+1ZUV/LPqNp+y77Xw3xaloBtVbx6jB/lg57GCip14b0bkWZ2QEeqI
QN9E6nNEl9gGOXG+qSx5
=z9A6
-END PGP SIGNATURE-
