193081 2007-09-19 16:15 0000 mail-filter/dspam: Database setup should not be fixed to 'localhost' as the database server 2007-09-30 17:09:06 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified All Linux RESOLVED FIXED P2 normal --- 1 bugs.gentoo.org@meisel.cc mrness@gentoo.org bugs.gentoo.org@meisel.cc 2007-09-19 16:15:42 0000 The current installation mechanism of dspam with SQL database backends depends on the assumption that every database engine runs locally on the mail server. While this assumption is true for small installations using berkeley db, sqlite (and so on) large scale installations have a separate database server 'somewhere' in the network. The current dspam package installation process should be separated into two stages: Stage 1: Install of the package as it is (which means every necessary file including the (by use flag) preselected database connectors. Stage 2: Using the command "emerge --config =dspam-3.x.x" which triggers the execution of the pkg_config() section in the ebuild. This should do the finishing touches depending on the database backend setting the admin/installer did in the dspam.conf configuration file (selecting database backends, setting connection credentials and passwords) This method has the following advantages: 1. The admin can use more than one database backend 2. Remote database backend installations are possible 3. The installation part of dspam is separate from the initialization part (which can be done more than once for different DB set-ups) Reproducible: Always Steps to Reproduce: jer@gentoo.org 2007-09-19 16:39:41 0000 *** This bug has been marked as a duplicate of bug 193073 *** mrness@gentoo.org 2007-09-19 18:52:35 0000 You're right, this isn't a duplicate, but it is very close to being marked as invalid. The emerge --config phase is meant to configure a fresh installed instance of the package, therefore it shouldn't rely on data found in dspam.conf. That being said, I admit the current pkg_config is less than perfect because it relies on those pesky *.data files created on installation. > This method has the following advantages: > 1. The admin can use more than one database backend Don't see the point, but the current form supports multiple backends also, only you have to run emerge --config twice if you wanna configure mysql and postgres backends on the same box. > 2. Remote database backend installations are possible As opposed to what we have now? Just modify the *.data file and dspam.conf before running emerge --config and you will be able to configure the database on another server. > 3. The installation part of dspam is separate from the initialization part > (which can be done more than once for different DB set-ups) Still don't see the advantage. AFAIK dspam cannot use multiple backends at the same time and having multiple dspam configurations on the same machine is totally pointless. If you want an improved pkg_config (one who wouldn't rely on current content of the dspam.conf and remove the need of having *.data files) just propose a patch. I would like a pkg_config who read database parameters from dspam.conf as defaults and asks user to either confirm or alter them. mrness@gentoo.org 2007-09-23 09:37:48 0000 You don't have anything to say about my comments so I close this bug as INVALID (the subject is obviously so anyway). bugs.gentoo.org@meisel.cc 2007-09-23 10:30:12 0000 Not so fast ;-) I'm working in my own business, which is a full time job, I don't have as much time as a maintainer of a Gentoo package to respond. Anyhow. I don't want to argue about technical insignificances. My point is that the Postgresql set-up of dspam is broken. It is not automatic and probably never should be, the only thing it really must do is set-up dspam correctly and NOT the Postgresql part. BTW: In a real live environment there might even be a different administrator which set-up the database, and (s)he probably would not like to see a script doing stuff with the database. Especially with commands like "createlang" in Postgresql which touch very security sensitive areas of a database system. Long argument cut short: 1. The dspam routine 'must' only set-up it self. 2. I should only 'advise' the Admin on how to set-up up secondary systems ... Customized commands for the Databases are a nice add-on ;-) 3. It definitely should NOT touch other productive systems (like the database) because they could be set-up in special way, which results not only a faulty set-up of dspam, but also a broken database system with broader consequences. So leave the bug closed if you like ... I don't really care about it very much, I use an overlay with the correct set-up routine for me. But keep in mind that with this bug dspam will set many systems in danger of being broken (auto-magically) by your set-up .... as well as the Security of the whole system is in danger by an additional software package not being actively used (an full blown installed Postgresql server with every 'security hole' (in the future)) which needs to be patched by upgrading ... every Admin will thank you for that and every security aware person won't like using the dspam package ... mrness@gentoo.org 2007-09-23 13:56:32 0000 I have one full time job as a programmer and also I'm involved in 2 part time jobs. Somehow I find time to respond on bugs like this, even though I don't have a personal interest. (In reply to comment #4) > My point is that the Postgresql set-up of dspam is broken. It is not automatic > and probably never should be, the only thing it really must do is set-up dspam > correctly and NOT the Postgresql part. Do you honestly think I would ever consider maintaining a pkg_config function if it weren't the database setup? > BTW: In a real live environment there might even be a different administrator > which set-up the database, and (s)he probably would not like to see a script > doing stuff with the database. Especially with commands like "createlang" in > Postgresql which touch very security sensitive areas of a database system. No one force you to run pkg_config. Just do it manually if you must. > Long argument cut short: > 1. The dspam routine 'must' only set-up it self. Selecting a few parameters in dspam.conf such as StorageDriver or PgSQLServer isn't a reason to create pkg_config(), isn't it? > 2. I should only 'advise' the Admin on how to set-up up secondary systems ... > Customized commands for the Databases are a nice add-on ;-) Forward to him a sql script on how you would like to make your own database then. > 3. It definitely should NOT touch other productive systems (like the database) > because they could be set-up in special way, which results not only a faulty > set-up of dspam, but also a broken database system with broader consequences. > > So leave the bug closed if you like ... I don't really care about it very much, > I use an overlay with the correct set-up routine for me. You use an overlay just because you don't like pkg_config?!? Ah... I forgot. You also don't like having an unused Postgres server on your box... Time to ask for minimal USE flag on dev-d/postgres perhaps? > But keep in mind that with this bug dspam will set many systems in danger of > being broken (auto-magically) by your set-up Interesting... How will my setup bork your server again? You give the address of the Postgres server, root user and root password and expect the emerge to check if database server is reachable?!? Geez... > .... as well as the Security of > the whole system is in danger by an additional software package not being > actively used (an full blown installed Postgresql server with every 'security > hole' (in the future)) which needs to be patched by upgrading Some security freaks wouldn't install gcc on their boxes because they see it as a security hazard. We on the other hand prefer to fix real security holes, not the perceived ones. robim42@googlemail.com 2007-09-24 05:51:32 0000 > Interesting... How will my setup bork your server again? You give the address > of the Postgres server, root user and root password and expect the emerge to > check if database server is reachable?!? Geez... Well psql lets you do nasty things like execute shell commands. I personally don't like those database shells, if they have an buffer overflow somewhere (I'm sure they all do) you're doomed :-/ Anyway why not use a python script to call the set-up scripts as a wrapper. All you need is a thin python sql binding (psycopg or something like that would do). No servers required (even the install could be faster because the fat ass database would not have been compiled) and everybody is happy! ;-)) Just my 50 cent mrness@gentoo.org 2007-09-24 07:40:48 0000 (In reply to comment #6) > Anyway why not use a python script to call the set-up scripts as a wrapper. All > you need is a thin python sql binding (psycopg or something like that would > do). No servers required (even the install could be faster because the fat ass > database would not have been compiled) and everybody is happy! ;-)) I'm not familiar with psycopg, but if it can execute sql scripts just like psql, this is a good alternative. However this has nothing to do with this bug. Just attach a patch to bug 193073 that would allow pkg_config() and dspam.cron to use this alternative. The RDEPEND in this case will contain "postgres? ( || ( dev-python/psycopg dev-db/postgresql ) )". robim42@googlemail.com 2007-09-25 13:21:41 0000 Well I don't know python and PostgreSQL very well. I would take me weeks to write such a script. :-/ bugs.gentoo.org@meisel.cc 2007-09-25 13:57:38 0000 Created an attachment (id=131862) python, psycopg wrapper for pkg_config routines bugs.gentoo.org@meisel.cc 2007-09-25 13:58:31 0000 Hi there! Here a quick script which takes either 5 or 6 arguments, depending if a virtual user set-up is wanted or not. Usage: prepare-dspam-postgresql.py [database host] [dspam user] [dspam passwd] [dspam dbname] [set-up DB script] [OPTIONAL: set-up virutal-user script] Example: prepare-dspam-postgresql.py 192.168.5.5 dspam secr3t mydspam /path/to/pgsql_objects.sql /path/to/pgsql_virtual_users.sql It does take the pkg_config routines and embeds them into python using a psycopg ( dev-python/psycopg ) connector. Alin, if you like a write another, smarter wrapper (reading the configuration from dspam.conf) for the cron qurge.sql script!? bugs.gentoo.org@meisel.cc 2007-09-25 14:00:34 0000 Typo in last sentence: Alin, I write another 'smarter' wrapper (reading the configuration from dspam.conf) for the cron qurge.sql script, if you like?! mrness@gentoo.org 2007-09-25 15:09:01 0000 (In reply to comment #11) > Typo in last sentence: > Alin, I write another 'smarter' wrapper (reading the configuration > from dspam.conf) for the cron qurge.sql script, if you like?! This piece of code must be executed by sh because it should run from pkg_config and dspam.cron (don't wanna install a wrapper for such a simple task). If your code satisfy this condition, post it here. If not, I will probably write some awk code for it. mrness@gentoo.org 2007-09-25 15:29:29 0000 Ah, and another thing... I also need to execute the sql purge script found in /etc/mail/dspam directory. For that reason, I want a database terminal like psql, that would be capable to do database creation and purge the old data when called from dspam.cron. I also need some special env vars through I could pass authentication data to the script (dspam.cron isn't interactive). bugs.gentoo.org@meisel.cc 2007-09-26 11:48:26 0000 Sure no problem ... env vars or command args or both for the purge script? bugs.gentoo.org@meisel.cc 2007-09-26 12:13:50 0000 Ok, the attached script purge-postgresql.py you can either be called with arguments: purge-postgresql.py [database host] [dspam user] [dspam passwd] [dspam dbname] [purge DB script] or without arguments, but the following environment vars set: DSPAM_PgSQL_HOST, DSPAM_PgSQL_USER, DSPAM_PgSQL_PWD, DSPAM_PgSQL_DB and DSPAM_PgSQL_PURGE_SQL bugs.gentoo.org@meisel.cc 2007-09-26 12:15:25 0000 Created an attachment (id=131931) python, psycopg wrapper for daily (cron based) postgresql database clean-up bugs.gentoo.org@meisel.cc 2007-09-26 16:17:06 0000 There is already a small problem embedded in the pgsql_objects.sql file. The command: create language plpgsql; only work for PostgreSQL < 8.0 for PostgreSQL 8.0 and later you need to run: createlang -Upostgres plpgsql <DBNAME> Otherwise you will get an syntax error for the current (and also my python wrapper, which I can fix) dspam database set-up. mrness@gentoo.org 2007-09-29 12:52:59 0000 Well, createlang is installed by postgresql. Please come up with an alternative or I will be forced dev-lib/postgresql dependency. I will force >=libpq-8 dependency anyway, so you don't need to take previous postgres versions into account. Aside from that I almost finished the r7 revision, which is far better polished version than the one before. You were right about pkg_config not being able to configure any other sql server than localhost. Sorry about that. mrness@gentoo.org 2007-09-30 12:08:59 0000 Fixed in -r7, just the way you wanted. Changes occured in pkg_config: - edit database parameters of the dspam.conf - create database with whatever settings user specified in his dspam.conf - make database creation optionally - pgsql: use psycopg script when psql is missing (postgresql can be missing, see the new RDEPEND) - pgsql: fix language creation Changes occured in dspam.cron: - sql purge scripts no longer required - read database parameters directly from dspam.conf - pgsql: use psycopg script when psql is missing I've just lost almost an entire weekend over this. The next person who will have anything to add to dspam ebuild, better have patches and be prepared to fix whatever I tell him to. bugs.gentoo.org@meisel.cc 2007-09-30 17:09:06 0000 Cheers Alin ... you are a * .... :-) 131862 2007-09-25 13:57 0000 python, psycopg wrapper for pkg_config routines prepare-dspam-postgresql.py text/plain IyEvYmluL2VudiBweXRob24KCmltcG9ydCBzeXMKaW1wb3J0IHBzeWNvcGcyCmZyb20gcHN5Y29w ZzIuZXh0ZW5zaW9ucyBpbXBvcnQgSVNPTEFUSU9OX0xFVkVMX0FVVE9DT01NSVQKCmRlZiBpbnB1 dFN0dWZmKHRpdGxlLCBkZWZhdWx0ID0gTm9uZSwgZW1wdHkgPSBUcnVlKToKICAgIGlmIGRlZmF1 bHQgaXMgbm90IE5vbmU6CiAgICAgICAgdWlucHV0ID0gcmF3X2lucHV0KCIlcyBbREVGQVVMVCAl c106ICIgJSh0aXRsZSwgZGVmYXVsdCkpCiAgICBlbHNlOgogICAgICAgIHVpbnB1dCA9IHJhd19p bnB1dCgiJXM6ICIgJSh0aXRsZSkpCiAgICBpZiBkZWZhdWx0OgogICAgICAgIGlmIHVpbnB1dCA9 PSAnJzoKICAgICAgICAgICAgcmV0dXJuIGRlZmF1bHQKICAgIGlmIHVpbnB1dCA9PSAnJyBhbmQg bm90IGVtcHR5OgogICAgICAgIHByaW50ICJFcnJvcjogWmVybyBsZW5ndGggaW5wdXQgbm90IGFs bG93ZWQhIgogICAgICAgIHJldHVybiBpbnB1dFN0dWZmKHRpdGxlLCBkZWZhdWx0LCBlbXB0eSkK ICAgIHJldHVybiB1aW5wdXQKCmRlZiBtYWluKCk6CiAgICBpZiBsZW4oc3lzLmFyZ3YpID09IDY6 CiAgICAgICAgdGhpc2NyaXB0LCBob3N0bmFtZWlwLCBkc3BhbXVzZXIsIGRzcGFtcGFzcywgZHNw YW1kYiwgY3JlYXRlc2NyaXB0ID0gc3lzLmFyZ3YKICAgIGVsaWYgbGVuKHN5cy5hcmd2KSA9PSA3 OgogICAgICAgIHRoaXNjcmlwdCwgaG9zdG5hbWVpcCwgZHNwYW11c2VyLCBkc3BhbXBhc3MsIGRz cGFtZGIsIGNyZWF0ZXNjcmlwdCwgdnVzZXJzY3JpcHQgPSBzeXMuYXJndgogICAgZWxzZToKICAg ICAgICBwcmludCAiVXNhZ2U6ICVzIFtkYXRhYmFzZSBob3N0XSBbZHNwYW0gdXNlcl0gW2RzcGFt IHBhc3N3ZF0gW2RzcGFtIGRibmFtZV0gW3NldC11cCBEQiBzY3JpcHRdIFtPUFRJT05BTDogc2V0 LXVwIHZpcnV0YWwtdXNlciBzY3JpcHRdIiAlKHN5cy5hcmd2WzBdKQogICAgICAgIHN5cy5leGl0 KDEpCiAgICBjb24gPSBjb25uZWN0KGhvc3RuYW1laXApCiAgICBjb24uc2V0X2lzb2xhdGlvbl9s ZXZlbChJU09MQVRJT05fTEVWRUxfQVVUT0NPTU1JVCkgIyBDUkVBVEUgREFUQUJBU0UgbmVlZHMg dGhpcwogICAgY3VyID0gY29uLmN1cnNvcigpCiAgICBjcmVhdGVEYkFuZFVzZXIoY3VyLCBkc3Bh bXVzZXIsIGRzcGFtcGFzcywgZHNwYW1kYikKICAgIGNvbi5jbG9zZSgpCiAgICBleGVjdXRlU2Ny aXB0KGRzcGFtdXNlciwgZHNwYW1wYXNzLCBkc3BhbWRiLCBob3N0bmFtZWlwLCBjcmVhdGVzY3Jp cHQpCiAgICBpZiBsZW4oc3lzLmFyZ3YpID09IDc6CiAgICAgICAgZXhlY3V0ZVNjcmlwdChkc3Bh bXVzZXIsIGRzcGFtcGFzcywgZHNwYW1kYiwgaG9zdG5hbWVpcCwgdnVzZXJzY3JpcHQpCgpkZWYg Y3JlYXRlRGJBbmRVc2VyKGN1ciwgZHNwYW11c2VyLCBkc3BhbXBhc3MsIGRzcGFtZGIpOgogICAg cHJpbnQgIkNyZWF0aW5nIERTUEFNIFBvc3RncmVTUUwgZGF0YWJhc2UgJXMgYW5kIHVzZXIgJXMi ICUoZHNwYW1kYiwgZHNwYW11c2VyKQogICAgdHJ5OiAgICAKICAgICAgICBjdXIuZXhlY3V0ZSgi IiJDUkVBVEUgVVNFUiAlcyBXSVRIIFBBU1NXT1JEICclcycgTk9DUkVBVEVEQiBOT0NSRUFURVVT RVI7IENSRUFURSBEQVRBQkFTRSAlczsgR1JBTlQgQUxMIFBSSVZJTEVHRVMgT04gREFUQUJBU0Ug JXMgVE8gJXM7IEdSQU5UIEFMTCBQUklWSUxFR0VTIE9OIFNDSEVNQSBwdWJsaWMgVE8gJXM7IFVQ REFURSBwZ19kYXRhYmFzZSBTRVQgZGF0ZGJhPShTRUxFQ1QgdXNlc3lzaWQgRlJPTSBwZ19zaGFk b3cgV0hFUkUgdXNlbmFtZT0nJXMnKSBXSEVSRSBkYXRuYW1lPSclcyc7IiIiICUoZHNwYW11c2Vy LCBkc3BhbXBhc3MsIGRzcGFtZGIsIGRzcGFtZGIsIGRzcGFtdXNlciwgZHNwYW11c2VyLCBkc3Bh bXVzZXIsIGRzcGFtZGIpKQogICAgZXhjZXB0IEV4Y2VwdGlvbiwgZToKICAgICAgICBwcmludCAi RVJST1I6IiwgZQogICAgICAgIHN5cy5leGl0KDIpCgpkZWYgZXhlY3V0ZVNjcmlwdChkc3BhbXVz ZXIsIGRzcGFtcGFzcywgZHNwYW1kYiwgaG9zdG5hbWVpcCwgc2NyaXB0KToKICAgIHByaW50ICJF eGVjdXRpbmcgc2NyaXB0ICVzIGZvciAlcyAodTogJXMgcDogJXMpIiAlKHNjcmlwdCwgZHNwYW1k YiwgZHNwYW11c2VyLCBkc3BhbXBhc3MpCiAgICB0cnk6CiAgICAgICAgY29uID0gcHN5Y29wZzIu Y29ubmVjdChkYXRhYmFzZT1kc3BhbWRiLCB1c2VyPWRzcGFtdXNlciwgcGFzc3dvcmQ9ZHNwYW1w YXNzLCBob3N0PWhvc3RuYW1laXApCiAgICAgICAgY29uLnNldF9pc29sYXRpb25fbGV2ZWwoSVNP TEFUSU9OX0xFVkVMX0FVVE9DT01NSVQpICMgTmVlZGVkIGZvciBwbHBnc3FsCiAgICAgICAgY3Vy ID0gY29uLmN1cnNvcigpCiAgICBleGNlcHQgRXhjZXB0aW9uLCBlOgogICAgICAgIHByaW50ICJF UlJPUjogIixlCiAgICAgICAgc3lzLmV4aXQoMykKICAgIHRyeToKICAgICAgICBmID0gb3Blbihz Y3JpcHQsICdyJykKICAgICAgICBzY3JpcHQgPSBmLnJlYWQoKQogICAgICAgIGYuY2xvc2UoKQog ICAgZXhjZXB0IEV4Y2VwdGlvbiwgZToKICAgICAgICBwcmludCAiRVJST1I6ICIsZQogICAgICAg IHN5cy5leGl0KDQpCiAgICB0cnk6CiAgICAgICAgY3VyLmV4ZWN1dGUoc2NyaXB0KQogICAgZXhj ZXB0IEV4Y2VwdGlvbiwgZToKICAgICAgICBwcmludCAiRVJST1I6ICIsZQogICAgICAgIHN5cy5l eGl0KDUpCiAgICBjb24uY2xvc2UoKQogICAgCmRlZiBjb25uZWN0KGhvc3RuYW1laXApOgogICAg Y29ubmVjdHVzZXIgPSAncG9zdGdyZXMnCiAgICBjb25uZWN0cGFzcyA9ICcnCiAgICBub3Rjb25u ZWN0ZWQgPSAxCiAgICB3aGlsZShub3Rjb25uZWN0ZWQpOgogICAgICAgIHRyeTogICAgCiAgICAg ICAgICAgIGNvbiA9IHBzeWNvcGcyLmNvbm5lY3QoZGF0YWJhc2U9J3RlbXBsYXRlMScsIHVzZXI9 Y29ubmVjdHVzZXIsIHBhc3N3b3JkPWNvbm5lY3RwYXNzLCBob3N0PWhvc3RuYW1laXApCiAgICAg ICAgICAgIG5vdGNvbm5lY3RlZCA9IDAKICAgICAgICBleGNlcHQgcHN5Y29wZzIuT3BlcmF0aW9u YWxFcnJvciwgZToKICAgICAgICAgICAgaWYgJ25vIHBhc3N3b3JkJyBpbiBlWzBdOgogICAgICAg ICAgICAgICAgcHJpbnQgIkVSUk9SOiBDb3VsZCBub3QgY29ubmVjdCB0byBkYXRhYmFzZSB3aXRo IGRlZmF1bHQgdXNlciAncG9zdGdyZXMnIGFuIG5vIHBhc3N3b3JkIgogICAgICAgICAgICBlbHNl OgogICAgICAgICAgICAgICAgcHJpbnQgZQogICAgICAgICAgICBjb25uZWN0dXNlciA9IGlucHV0 U3R1ZmYoJ0Nvbm5lY3RpbmcgREItVXNlciAoZGVmYXVsdDogcG9zdGdyZXMpJywgJ3Bvc3RncmVz JywgZW1wdHkgPSBGYWxzZSkKICAgICAgICAgICAgY29ubmVjdHBhc3MgPSBpbnB1dFN0dWZmKCdE Qi1Vc2VyIFBhc3N3b3JkJykKICAgICAgICBleGNlcHQgRXhjZXB0aW9uLCBlOgogICAgICAgICAg ICBwcmludCBlCiAgICAgICAgICAgIHN5cy5leGl0KDIpCiAgICByZXR1cm4gY29uCgppZiBfX25h bWVfXyA9PSAnX19tYWluX18nOgogICAgbWFpbigpCg== 131931 2007-09-26 12:15 0000 python, psycopg wrapper for daily (cron based) postgresql database clean-up purge-postgresql.py text/plain IyEvYmluL2VudiBweXRob24KCmltcG9ydCBzeXMsIG9zCmltcG9ydCBwc3ljb3BnMgpmcm9tIHBz eWNvcGcyLmV4dGVuc2lvbnMgaW1wb3J0IElTT0xBVElPTl9MRVZFTF9BVVRPQ09NTUlUCgpkZWYg bWFpbigpOgogICAgaWYgbGVuKHN5cy5hcmd2KSA9PSA2OgogICAgICAgIHRoaXNjcmlwdCwgaG9z dG5hbWVpcCwgZHNwYW11c2VyLCBkc3BhbXBhc3MsIGRzcGFtZGIsIHB1cmdlc2NyaXB0ID0gc3lz LmFyZ3YKICAgIGVsc2U6CiAgICAgICAgZW52ID0gb3MuZW52aXJvbgogICAgICAgIGlmIHNldCgo J0RTUEFNX1BnU1FMX0hPU1QnLCAnRFNQQU1fUGdTUUxfVVNFUicsICdEU1BBTV9QZ1NRTF9QV0Qn LCAnRFNQQU1fUGdTUUxfREInLCAnRFNQQU1fUGdTUUxfUFVSR0VfU1FMJykpIDw9IHNldChlbnYp OgogICAgICAgICAgICBob3N0bmFtZWlwID0gZW52WydEU1BBTV9QZ1NRTF9IT1NUJ10KICAgICAg ICAgICAgZHNwYW11c2VyID0gZW52WydEU1BBTV9QZ1NRTF9VU0VSJ10KICAgICAgICAgICAgZHNw YW1wYXNzID0gZW52WydEU1BBTV9QZ1NRTF9QV0QnXQogICAgICAgICAgICBkc3BhbWRiID0gZW52 WydEU1BBTV9QZ1NRTF9EQiddCiAgICAgICAgICAgIHB1cmdlc2NyaXB0ID0gZW52WydEU1BBTV9Q Z1NRTF9QVVJHRV9TUUwnXQogICAgICAgIGVsc2U6CiAgICAgICAgICAgIHByaW50ICJVc2FnZTog JXMgW2RhdGFiYXNlIGhvc3RdIFtkc3BhbSB1c2VyXSBbZHNwYW0gcGFzc3dkXSBbZHNwYW0gZGJu YW1lXSBbcHVyZ2UgREIgc2NyaXB0XSIgJShzeXMuYXJndlswXSkKICAgICAgICAgICAgcHJpbnQg Im9yIHNldCB0aGUgZW5pcm9ubWVudCB2YXJpYWJsZXM6IgogICAgICAgICAgICBwcmludCAiRFNQ QU1fUGdTUUxfSE9TVCwgRFNQQU1fUGdTUUxfVVNFUiwgRFNQQU1fUGdTUUxfUFdELCBEU1BBTV9Q Z1NRTF9EQiBhbmQgRFNQQU1fUGdTUUxfUFVSR0VfU1FMIgogICAgICAgICAgICBzeXMuZXhpdCgx KQogICAgdHJ5OgogICAgICAgIGNvbiA9IHBzeWNvcGcyLmNvbm5lY3QoZGF0YWJhc2U9ZHNwYW1k YiwgdXNlcj1kc3BhbXVzZXIsIHBhc3N3b3JkPWRzcGFtcGFzcywgaG9zdD1ob3N0bmFtZWlwKQog ICAgICAgIGNvbi5zZXRfaXNvbGF0aW9uX2xldmVsKElTT0xBVElPTl9MRVZFTF9BVVRPQ09NTUlU KSAjIE5lZWRlZCBmb3IgcGxwZ3NxbAogICAgICAgIGN1ciA9IGNvbi5jdXJzb3IoKQogICAgZXhj ZXB0IEV4Y2VwdGlvbiwgZToKICAgICAgICBwcmludCAiRVJST1I6ICIsZQogICAgICAgIHN5cy5l eGl0KDMpCiAgICB0cnk6CiAgICAgICAgZiA9IG9wZW4ocHVyZ2VzY3JpcHQsICdyJykKICAgICAg ICBzY3JpcHQgPSBmLnJlYWQoKQogICAgICAgIGYuY2xvc2UoKQogICAgZXhjZXB0IEV4Y2VwdGlv biwgZToKICAgICAgICBwcmludCAiRVJST1I6ICIsZQogICAgICAgIHN5cy5leGl0KDQpCiAgICB0 cnk6CiAgICAgICAgY3VyLmV4ZWN1dGUoc2NyaXB0KQogICAgZXhjZXB0IEV4Y2VwdGlvbiwgZToK ICAgICAgICBwcmludCAiRVJST1I6ICIsZQogICAgICAgIHN5cy5leGl0KDUpCiAgICBjb24uY2xv c2UoKQogICAgCmlmIF9fbmFtZV9fID09ICdfX21haW5fXyc6CiAgICBtYWluKCkK