roundup-users Mailing List for Roundup Issue Tracker (Page 5)

On Tue, Feb 06, 2024 at 11:17:28AM -0600, Tonu Mikk via Roundup-users wrote:
>    <VirtualHost *:80>
>            ServerName music.drc.umn.edu
>            <Directory /opt/trackers/classic>
>                    Require all granted
>            </Directory>
>            WSGIScriptAlias /test_wsgi /opt/trackers/classic/test_wsgi.py
>            WSGIScriptAlias /piano /opt/trackers/classic_wsgi.py
>            WSGIDaemonProcess classic.apache user=tmikk group=mytrackergrp
>    threads=25
>            WSGIProcessGroup classic.apache
>    </VirtualHost>

I have the WSGIProcessGroup group mentioned in the WSGIScriptAlias
e.g.
process-group=classic.apache

And I'm not sure a group name may include a dot..

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

On Tue, Feb 06, 2024 at 11:17:28AM -0600, Tonu Mikk via Roundup-users wrote:
>            <Directory /opt/trackers/classic>
>                    Require all granted
>            </Directory>

Looks good to me, but I have the wsgi file mentioned explicitly

    <Directory /path/to/tracker>
        Require all granted
        <Files wsgiscript.wsgi>
        </Files>
    </Directory>

Also all the permissions seem far too open, rwxrwxrwx is never a good
idea for a web server. The files should not be writeable *and*
executable by the web server user.

And I have application groups defined in the wsgi config, but it looks
like you're not getting that far currently.

Ah and you may want to consider switching to uwsgi, this is the more
modern version of a wsgi daemon.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Hello,

I am trying to configure a web interface for a Roundup tracker using Apache
2.4, Python 3.9, mod_wsgi on the RedHat 9 server. I am getting an error in
the Apache error log
authz core:error client denied by server configuration:
/opt/trackers/classic_wsgi.py . Seeking help in resolving this error. Here
are my configuration details.

   - I installed Roundup using the manual method -
   https://www.roundup-tracker.org/docs/installation.html#installing-from-downloaded-source
   . Roundup is installed into the system's Python tree and Roundup commands
   are available in /usr/bin .  I used this installation method as it seems to
   allow me to use the Apache web server with mod_wsgi.  I was not able to use
   the mod_wsgi express command as it doesn't seem to be available in my
   system.
   - I created a tracker home in /opt/trackers/classic
   - I modified the config.ini file to make the tracker web to be
   https://music.drc.umn.edu/piano/
   - I created an Apache virtual config file with the following directives:
   <VirtualHost *:80>
           ServerName music.drc.umn.edu
           <Directory /opt/trackers/classic>
                   Require all granted
           </Directory>
           WSGIScriptAlias /test_wsgi /opt/trackers/classic/test_wsgi.py
           WSGIScriptAlias /piano /opt/trackers/classic_wsgi.py
           WSGIDaemonProcess classic.apache user=tmikk group=mytrackergrp
   threads=25
           WSGIProcessGroup classic.apache
   </VirtualHost>
   - I created a file (classic_wsgi.py) in the tracker's home directory
   with the following directives:
   from roundup.cgi.wsgi_handler import RequestDispatcher
   tracker_home = '/opt/trackers/classic'
   application = RequestDispatcher(tracker_home)
   - I created a group called mytrackergrp:
   mytrackergrp:*:1002:tmikk,apache,daemon,mail
   - The permissions on the tracker directory
   drwxrwxrwx. 7 tmikk mytrackergrp 4096 Feb  6 08:21 classic
   - Permissions for the files in the tracker directory:
   drwxrwxrwx. 7 tmikk mytrackergrp  4096 Feb  6 08:21 .
   drwxrwxrwx. 3 root  root            21 Jan 23 08:48 ..
   -rwxrwxrwx. 1 tmikk mytrackergrp   140 Jan 23 08:50 classic_wsgi.py
   -rwxrwxrwx. 1 tmikk mytrackergrp 39654 Feb  6 10:34 config.ini
   drwxrwsrwx. 2 tmikk mytrackergrp    16 Jan 23 08:48 db
   drwxrwxrwx. 3 tmikk mytrackergrp   137 Jan 23 08:48 detectors
   drwxrwxrwx. 2 tmikk mytrackergrp    24 Jan 23 08:48 extensions
   drwxrwxrwx. 2 tmikk mytrackergrp  4096 Jan 23 08:48 html
   -rwxrwxrwx. 1 tmikk mytrackergrp  1070 Jan 23 08:48 initial_data.py
   drwxrwxrwx. 2 tmikk mytrackergrp    70 Jan 23 08:48 __pycache__
   -rwxrwxrwx. 1 tmikk mytrackergrp  7598 Jan 23 08:48 schema.py
   -rwxrwxrwx. 1 tmikk mytrackergrp   351 Jan 23 08:48 TEMPLATE-INFO.txt
   -rw-r-----. 1 tmikk mytrackergrp   295 Jan 25 08:30 test_wsgi.py

I also created a test mod_wsgi file in the /opt/trackers/classic directory
called test_wsgi with the following content:

def application(environ, start_response):
    status = '200 OK'
    output = b'Hooray, mod_wsgi is working'

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

When I access http://music.drc.umn.edu/test_wsgi/ using a browser I am able
to see that the wsgi is working. It presents a message "Hooray, mod_wsgi is
working".
When I try to access http://music.drc.umn.edu/piano in the browser, I get a
message "Forbidden You don't have permission to access this resource." And
I see the following entry in the /var/log/httpd/error_log:
[Tue Feb 06 11:04:21.164299 2024] [authz_core:error] [pid 3091514:tid
3091575] [client 10.20.27.232:57914] AH01630: client denied by server
configuration: /opt/trackers/classic_wsgi.py .

Searching for this error led me to results that talk about Apache
permissions. I don't know if that is it as the virtual conf file includes
the "Require all granted" for /opt/trackers/classic directory.

The RedHat server comes with SELinux enabled. I have set the SELinux to
"permissive" and that makes no difference.

When I try to run the roundup server from the command line, I get an error
message that the port 80 is already in use.
roundup-server -p 80 -n 134.84.72.17 piano=/opt/trackers/classic

When I change the port to 8080, I am not able to reach the page with the
browser, probably because 8080 is blocked by firewall configuration.

I am successfully able to run the tracker on localhost using the
roundup-server command.

Thanks for any help!






Hooray, mod_wsgi is working, mod_wsgi is working

-- 
Tonu Mikk
Developer | Disability Resource Center | disability.umn.edu
University of Minnesota | umn.edu
tm...@um...
Pronouns: He/Him

Hello All:

I am currently working on developing some projects for the capstone
class of graduate software engineering sequence.

I am looking at something that can be delivered by a team of three
people in about 400 hours (cumulatively) of effort.

I have a short list of items:

  Replace/enhance the classhelper (the 'list' link in item updates).
    Replacing the frames implementation with vanilla JavaScript.

  With the current openid login code: cleanup, add config.ini support,
    document and package it into a form that can be dropped into a
    Roundup tracker.

  Create an HTML web component that can wrap any multilink text input
    and provide an expression editor. This is a more modern
    (frameless) implementation of the '(expr)' link you see on the
    keyword input on the search page.

  Allow templating of emails. This would replace the somewhat
    inflexible current email routines. It would retain the existing
    interface, reimplementing it using more capable code and also
    provide a new more flexible interface.

I am planning on only pitching two of these. If you think a couple of
these stand out as needed, or if you have other projects you think
should be included reply away. If this goes well I hope to be
submitting projects (and having them completed) on a yearly basis.

I am on a short deadline here so ideas submitted before Friday that I
can finish specification on before my initial meeting with the
Professor on Tuesday would be great.

Have a great week all.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Hi Gabor:

In message <20231227155734.7ed006b9@Dell>,
Nagy Gabor writes:
>Ignore my previous mail, I am lightheaded, I did patch form_parser.py,
>and I have explicitly disabled this feature. I just do not remember
>why... :)

Ok, that's a better alternative than some odd bug 8-). 

>[Then I did not use git, and I do not document things well...
>I have to test things if I re-enable this. :]

Personaly I prefer the fossil SCM to git. Saner interface plus you can
put searchable detailed notes in fossil's wiki. Fossil does have a bug
tracker built in, but I mean why would you use it 8-).

>So I just wish you Happy New Year, and say thank you for developing
>such a gem software like Roundup.

Thank you even though I primarily just maintain it, but you're
welcome.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Hi Gabor:

In message <20231227153507.1b87c45e@Dell>,
Nagy Gabor writes:
>I wanted to use the "@file" form variable (which is kept for backward
>compatibility), because its support for multiple files would be handy
>for my use case.
>
>The documentation says that
>"@file
>    This is equivalent to::
>
>        @link@files=file-1
>        file-1@content=value"
>
>On my system, it does not do @link@files=file-1...

What does your HTML input look like? I have a current development
classic tacker deployed and using the file input defined with:

  <input type="file" name="@file" size="40">

works as expected.

>I've also tried with the default classic theme (issue.item.html uses
>@file), with the same result: The uploaded file is not added to the
>files list of the issue; I've tried with both empty and non-empty
>messages.

I can't reproduce this.

>Well, I am using a slightly patched roundup version v2.1.0, but I did
>not touch cgi/form_parser.py (and as I see that file did not change
>between 2.1.0 and 2.2.0). Could you please give a look on your system
>to this? And I would be also grateful for a supposed fix / patch :)

A few questions:

  1) is the file created and is it viewable at the /fileNN endpoint?

  2) what does your schema for issues looks like?

  3) what does the files property for the issue look like in
     roundup-admin when you use 'display issue#'

>From a quick glance at the code I don't see anything out of place. The
code is a bit different from handling @note, and all the special
variable handling is split into multiple parts making tracing it
tough, but it looks like:

                      all_links.append((cn, nodeid, 'files',
                                      [('file', fnodeid)]))

does get set properly and that should result in appending the new file
to the files property.

>[I've already implemented some new features assuming that this works as
>expected... I even copied an other FileClass() to the class file to use
>this feature. I should have been tested it first. :]

Note that @file will link only for the files property of an
IssueClass. It won't work for anything else. It looks like it should
throw an error when used in another context, but I can't be sure about
that.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Dear Developers,

Ignore my previous mail, I am lightheaded, I did patch form_parser.py,
and I have explicitly disabled this feature. I just do not remember
why... :) [Then I did not use git, and I do not document things well...
I have to test things if I re-enable this. :]

So I just wish you Happy New Year, and say thank you for developing
such a gem software like Roundup.

Dear Developers,

I wanted to use the "@file" form variable (which is kept for backward
compatibility), because its support for multiple files would be handy
for my use case.

The documentation says that
"@file
    This is equivalent to::

        @link@files=file-1
        file-1@content=value"

On my system, it does not do @link@files=file-1...
I've also tried with the default classic theme (issue.item.html uses
@file), with the same result: The uploaded file is not added to the
files list of the issue; I've tried with both empty and non-empty
messages.

Well, I am using a slightly patched roundup version v2.1.0, but I did
not touch cgi/form_parser.py (and as I see that file did not change
between 2.1.0 and 2.2.0). Could you please give a look on your system
to this? And I would be also grateful for a supposed fix / patch :)
[I've already implemented some new features assuming that this works as
expected... I even copied an other FileClass() to the class file to use
this feature. I should have been tested it first. :]

Regards,
Gábor Nagy

Hello folks! I think this might also be of interest to you.

I recently implemented LDAP support for Roundup as an extension that uses ldap3 module. The extension supports connections using unencrypted LDAP, LDAP over TLS and LDAPS, connection logging, updating user properties based on directory entry attributes and authorization based on LDAP group membership. It also supports configuration of connection settings, logging levels and authorization settings.

It is intended for use with an internal tracker and therefore does not support fallback database authentication. Also, it was written to work with Python3, and if you want to use it with Python2, you need to fix some imports.

It is also licensed under the MIT License. You can find more information in the project repository: https://github.com/savchuk1985/roundup-ldap3

Of course, suggestions and pull requests are welcome. Feel free to open an issue on GitHub.

I hope this may be useful to you.

Hello folks! I have updated jinja2 based templates for Roundup to use a modern version of Bootstrap and make them more mobile friendly.
Almost all pages have been redesigned and are now fully responsive. I also added support for the Bootstrap dark theme and theme switching.

You can see some screenshots:

https://issues.roundup-tracker.org/file1794/bootstrap5-dark-theme-read-only-issue-mobile.png
https://issues.roundup-tracker.org/file1795/bootstrap5-light-theme-read-only-issue-mobile.png
https://issues.roundup-tracker.org/file1796/bootstrap5-dark-theme-issue-index-and-login-form-desktop.png
https://issues.roundup-tracker.org/file1797/bootstrap5-light-theme-issue-index-after-login-desktop.png
https://issues.roundup-tracker.org/file1798/bootstrap5-dark-theme-issue-editing-mobile.png
https://issues.roundup-tracker.org/file1799/bootstrap5-dark-theme-issue-index-mobile.png
https://issues.roundup-tracker.org/file1800/bootstrap5-light-theme-navigation-mobile.png
https://issues.roundup-tracker.org/file1801/bootstrap5-dark-theme-issue-searching-desktop.png
https://issues.roundup-tracker.org/file1802/bootstrap5-dark-theme-user-list-desktop.png

The templates are based on the classic schema and are available under the MIT License.
If you are interested, you can download them from the Github repository: https://github.com/savchuk1985/roundup-jinja2-templates

The templates are already usable and much improved over the jinja2 based templates distributed with Roundup. But they are not perfect, so suggestions and patches are welcome.

I would like to suggest these as replacements for the current templates, so if you like them please leave a review here: https://issues.roundup-tracker.org/issue2551308

Dear Ralf,

This is great. Thanks.

Regards,
Gábor

> On Fri, Dec 22, 2023 at 11:28:15PM +0100, Nagy Gabor wrote:
> > Dear Roundup developers,
> > 
> > My schema.py has for example a Class definition like this:
> > issue = IssueClass(db, "issue", files = Multilink("file"), ...)
> > 
> > And my issues already contains many multilinks to some files.
> > 
> > Can I change the defintion in schema.py to
> > issue = IssueClass(db, "issue", files = Multilink("file",
> > rev_multilink="owner"), ...) without corrupting the database?  
> 
> Yes. The rev_multilink feature doesn't change the db, it just tells
> the database that we want to use the multilink also for navigating in
> the reverse direction.
> 
> Still for every schema-change you want to have a backup.
> 
> > Regards and merry Christmas,  
> Also merry Christmas to you!
> 
> Ralf

On Fri, Dec 22, 2023 at 11:28:15PM +0100, Nagy Gabor wrote:
> Dear Roundup developers,
> 
> My schema.py has for example a Class definition like this:
> issue = IssueClass(db, "issue", files = Multilink("file"), ...)
> 
> And my issues already contains many multilinks to some files.
> 
> Can I change the defintion in schema.py to
> issue = IssueClass(db, "issue", files = Multilink("file", rev_multilink="owner"), ...)
> without corrupting the database?

Yes. The rev_multilink feature doesn't change the db, it just tells the
database that we want to use the multilink also for navigating in the
reverse direction.

Still for every schema-change you want to have a backup.

> Regards and merry Christmas,
Also merry Christmas to you!

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Dear Roundup developers,

My schema.py has for example a Class definition like this:
issue = IssueClass(db, "issue", files = Multilink("file"), ...)

And my issues already contains many multilinks to some files.

Can I change the defintion in schema.py to
issue = IssueClass(db, "issue", files = Multilink("file", rev_multilink="owner"), ...)
without corrupting the database?

(Or I should add a new 'filez = Multilink("file", rev_multilink="owner")' property,
and copy the old files multilinks?)

Regards and merry Christmas,
Gábor Nagy

Hi Ivanov:

We should probably take this to the issue:

   https://issues.roundup-tracker.org/issue2551299

Can you sign up for an account and add yourself to the issue above.

In message <725...@ri...>,
iva...@ri... writes:
>I have tested this and found the following two problems.
>
>First, the 'roundup-admin initialise' command doesn't work properly in
>this case. I got the same results using first the PGSERVICE environment
>variable and then the rdbms_service configuration parameter. 

Good it's consistent.

>$ roundup-admin initialise
>Enter tracker home: core
>Admin Password: 
>       Confirm: 
>WARNING: The database is already initialised!
>If you re-initialise it, you will lose all the data!
>Erase it? Y/N: Y
>2023-12-18 03:15:58,166 INFO DROP DATABASE ""
>Traceback (most recent call last):
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
>line 106, in pg_command
>    cursor.execute(command)
>psycopg2.errors.SyntaxError: zero-length delimited identifier at or near
>""""
>LINE 1: DROP DATABASE ""

Ick.

If I have psycopg > 2.8 I can use
psycopg2.extensions.ConnectionInfo(connection) to get the dbname. I think.

>But what's even stranger is that I can't initialize the database when I
>specify the database name, host, port, username and password in the
>configuration file.

That is wierd. Do you have all the settings plus the service
defined?

>$ roundup-admin initialise
>Enter tracker home: core
>Admin Password:
>       Confirm:
>WARNING: The database is already initialised!
>If you re-initialise it, you will lose all the data!
>Erase it? Y/N: Y
>2023-12-18 19:31:01,239 INFO DROP DATABASE "roundup_dev"
>Traceback (most recent call last):
>  File "/home/user/Projects/www/roundup_dev/env/bin/roundup-admin", line
>8, in <module>
>    sys.exit(run())
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/scripts/roundup_admin.py",
>line 50, in run
>    sys.exit(tool.main())
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
>line 2230, in main
>    ret = self.run_command(args)
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
>line 2079, in run_command
>    return self.do_initialise(self.tracker_home, args)
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
>line 1168, in do_initialise
>    tracker.nuke()
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/instance.py",
>line 213, in nuke
>    self.backend.db_nuke(self.config)
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
>line 64, in db_nuke
>    db_command(config, command)
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
>line 96, in db_command
>    raise RuntimeError('10 attempts to create database failed')
>RuntimeError: 10 attempts to create database failed

Hmm, db_command should say what command it's having an issue with ans
what the error is.

Can you change:

-    raise RuntimeError('10 attempts to create database failed')

to

+    raise RuntimeError('10 attempts to create database failed when running: %s' % command)

around line 96 of roundup/backends/back_postgresql.py. That will get
some of the info hopefully.

Also can you connect to the db with psql and run \du so I can see what
permissions the user has. I assume none are listed since you don't
have CREATEDB.

>My postgresql user is the owner of the selected database, but does not
>have permission to create databases. 
>
>I think the problem is here, but I don't want to give them additional
>permissions just to initially populate the database.
>
>Maybe some kind of non-destructive initialization might be possible,
>without recreating the entire database?

It's supposed IIRC. It checks to see if the db exists. If the db
exists it tries to load the roundup schema. If that fails it
initializes the db. But it doesn't look like you are getting that far.

>By the way, why a database and not a schema?

Because thats how it was originally designed and nobody has tried to
integrate https://issues.roundup-tracker.org/issue2550852 and finish
up tests/docs etc. I have a vague recollection of testing the patch a
few years ago and it worked.

>At the same time, when I directly create Roundup users, it works for me.

Is the sequence here:

  set all db params in config.ini (host, database ...)

  roundup-admin init

  get the error: RuntimeError: 10 attempts to create database failed

  roundup-admin create user ....

  works.

>Second, there is a problem with using a schema other than 'public'. I
>can't perform database migration when I create scheme named by my
>postgresql username and use it in search_path. I see that Roundup
>expected me to use the 'public' schema.

That is either fixed in issue2550852, or a 'to be fixed' if support
for schemas comes on board.

>$ roundup-admin migrate
>Enter tracker home: core
>2023-12-18 03:13:02,011 INFO open database via service 'roundup_dev'
>2023-12-18 03:13:02,033 INFO rollback
>2023-12-18 03:13:02,033 DEBUG SQL 'CREATE TABLE schema (schema TEXT)'
>None
>2023-12-18 03:13:02,044 DEBUG SQL 'CREATE TABLE dual (dummy integer)'
>None
>2023-12-18 03:13:02,046 DEBUG SQL 'insert into dual values (1)' None
>2023-12-18 03:13:02,047 DEBUG SQL 'CREATE TABLE otks (otk_key
>VARCHAR(255),\n            otk_value TEXT, otk_time float)' None
>2023-12-18 03:13:02,055 DEBUG SQL 'CREATE INDEX otks_key_idx ON
>otks(otk_key)' None
>2023-12-18 03:13:02,060 DEBUG SQL 'CREATE TABLE sessions (\n           
>session_key VARCHAR(255), session_time float,\n            session_value
>TEXT)' None
>2023-12-18 03:13:02,065 DEBUG SQL 'CREATE INDEX sessions_key_idx ON\n   
>        sessions(session_key)' None
>2023-12-18 03:13:02,069 DEBUG SQL 'CREATE SEQUENCE ___textids_ids' None
>2023-12-18 03:13:02,070 DEBUG SQL 'CREATE TABLE __textids (\n           
>_textid integer primary key, _class VARCHAR(255),\n            _itemid
>VARCHAR(255), _prop VARCHAR(255))' None
>2023-12-18 03:13:02,079 DEBUG SQL 'CREATE TABLE __words (_word
>VARCHAR(55),\n            _textid integer)' None
>2023-12-18 03:13:02,080 DEBUG SQL 'CREATE INDEX words_word_idx ON
>__words(_word)' None
>2023-12-18 03:13:02,087 DEBUG SQL 'CREATE INDEX words_by_id ON __words
>(_textid)' None
>2023-12-18 03:13:02,092 DEBUG SQL 'CREATE UNIQUE INDEX
>__textids_by_props ON __textids (_class, _itemid, _prop)' None
>2023-12-18 03:13:02,097 DEBUG SQL 'DELETE FROM otks' None
>2023-12-18 03:13:02,097 DEBUG SQL 'ALTER TABLE otks DROP otk_value' None
>2023-12-18 03:13:02,098 DEBUG SQL 'ALTER TABLE otks ADD otk_value TEXT'
>None
>2023-12-18 03:13:02,099 DEBUG SQL 'DELETE FROM sessions' None
>2023-12-18 03:13:02,099 DEBUG SQL 'ALTER TABLE sessions DROP
>session_value' None
>2023-12-18 03:13:02,099 DEBUG SQL 'ALTER TABLE sessions ADD
>session_value TEXT' None
>2023-12-18 03:13:02,100 DEBUG SQL 'CREATE INDEX words_both_idx ON
>public.__words\n            USING btree (_word, _textid)' None
>Traceback (most recent call last):
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
>line 217, in open_connection
>    self.load_dbschema()
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/rdbms_common.py",
>line 305, in load_dbschema
>    self.cursor.execute('select schema from schema')
>psycopg2.errors.UndefinedTable: relation "schema" does not exist
>LINE 1: select schema from schema
>                           ^

Now this is wierd because:

  2023-12-18 03:13:02,033 DEBUG SQL 'CREATE TABLE schema (schema TEXT)'

the schema table and column were created, but probably in your
alternate schema. ("schema" is a confusing term for Roundup to use
there....)

How are you creating/directing roundup to use an alternate schema?  Is
there a schema= in pg_service.conf? Is the path associated with the
logged in user?

My guess is that the database layout is being put into your alternate
(non-public) schema and 'select schema from schema' uses the public
schema by default and fails.

The schema support patch does an explicit set search path to include
the schema.

>line 227, in __init__
>    self.open_connection()
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
>line 227, in open_connection

This is the code that runs to initialize the db if it already exists.
fix_version_3_tables runs after initializing the tables.

>    self.fix_version_3_tables()
>  File
>"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
>line 335, in fix_version_3_tables
>    self.sql('''CREATE INDEX words_both_idx ON public.__words
>[...]
>psycopg2.errors.UndefinedTable: relation "public.__words" does not exist
>
>If I only use the 'public' schema for my database, the migration command
>works well.

I wonder why this has an explicit schema on it? Can you check to see
if your alternate schema (assuming it got committed to the db) has a
__words table in it?

Can you change the reference to public.__words to just __words around
line 335 in back_postgresql.py. Then see if the migrate works. I don't
see any other explicit schema references in that file.

> Thank you for your help.

No, thank you for helping to make Roundup better.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

On 2023-11-21 03:43, John P. Rouillard wrote:
> 
> Have you had a chance to test this?
> 

Hello. Sorry for the long silence. 

I have tested this and found the following two problems.

First, the 'roundup-admin initialise' command doesn't work properly in
this case. I got the same results using first the PGSERVICE environment
variable and then the rdbms_service configuration parameter. 


$ roundup-admin initialise
Enter tracker home: core
Admin Password: 
       Confirm: 
WARNING: The database is already initialised!
If you re-initialise it, you will lose all the data!
Erase it? Y/N: Y
2023-12-18 03:15:58,166 INFO DROP DATABASE ""
Traceback (most recent call last):
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 106, in pg_command
    cursor.execute(command)
psycopg2.errors.SyntaxError: zero-length delimited identifier at or near
""""
LINE 1: DROP DATABASE ""
                      ^


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/user/Projects/www/roundup_dev/env/bin/roundup-admin", line
8, in <module>
    sys.exit(run())
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/scripts/roundup_admin.py",
line 50, in run
    sys.exit(tool.main())
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
line 2230, in main
    ret = self.run_command(args)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
line 2079, in run_command
    return self.do_initialise(self.tracker_home, args)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
line 1168, in do_initialise
    tracker.nuke()
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/instance.py",
line 213, in nuke
    self.backend.db_nuke(self.config)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 64, in db_nuke
    db_command(config, command)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 92, in db_command
    if pg_command(cursor, command):
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 118, in pg_command
    raise RuntimeError(response)
RuntimeError: zero-length delimited identifier at or near """"


But what's even stranger is that I can't initialize the database when I
specify the database name, host, port, username and password in the
configuration file.


$ roundup-admin initialise
Enter tracker home: core
Admin Password:
       Confirm:
WARNING: The database is already initialised!
If you re-initialise it, you will lose all the data!
Erase it? Y/N: Y
2023-12-18 19:31:01,239 INFO DROP DATABASE "roundup_dev"
Traceback (most recent call last):
  File "/home/user/Projects/www/roundup_dev/env/bin/roundup-admin", line
8, in <module>
    sys.exit(run())
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/scripts/roundup_admin.py",
line 50, in run
    sys.exit(tool.main())
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
line 2230, in main
    ret = self.run_command(args)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
line 2079, in run_command
    return self.do_initialise(self.tracker_home, args)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
line 1168, in do_initialise
    tracker.nuke()
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/instance.py",
line 213, in nuke
    self.backend.db_nuke(self.config)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 64, in db_nuke
    db_command(config, command)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 96, in db_command
    raise RuntimeError('10 attempts to create database failed')
RuntimeError: 10 attempts to create database failed


My postgresql user is the owner of the selected database, but does not
have permission to create databases. 

I think the problem is here, but I don't want to give them additional
permissions just to initially populate the database.

Maybe some kind of non-destructive initialization might be possible,
without recreating the entire database?

By the way, why a database and not a schema?


At the same time, when I directly create Roundup users, it works for me.


$ roundup-admin create user username="admin" roles="Admin"
Enter tracker home: core
2023-12-18 20:03:10,205 INFO open database via service 'roundup_dev'
2023-12-18 20:03:10,241 INFO commit
2023-12-18 20:03:10,241 DEBUG SQL "select nextval('_user_ids') from
dual" None
2023-12-18 20:03:10,242 DEBUG SQL 'select id from _user where
_username=%s and __retired__=%s' ('admin', 0)
2023-12-18 20:03:10,245 DEBUG addnode user1 {'username': 'admin',
'roles': 'Admin', 'password': None, 'address': None, 'realname': None,
'phone': None, 'organisation': None, 'alternate_addresses': None,
'queries': [], 'timezone': None}
2023-12-18 20:03:10,245 DEBUG SQL 'insert into _user
(_activity,_actor,_address,_alternate_addresses,_creation,_creator,_organisation,_password,_phone,_realname,_roles,_timezone,_username,id)
values (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s)' ('2023-12-18
16:03:10.245', 1, None, None, '2023-12-18 16:03:10.245', 1, None, None,
None, None, 'Admin', None, 'admin', '1')
2023-12-18 20:03:10,246 DEBUG addjournal user1 <Date
2023-12-18.16:03:10.246> 1 create {}
2023-12-18 20:03:10,246 DEBUG SQL 'insert into user__journal
(nodeid,date,tag,action,params) values (%s,%s,%s,%s,%s)' ('1',
'2023-12-18 16:03:10.246', '1', 'create', '{}')
1
2023-12-18 20:03:10,247 INFO commit
2023-12-18 20:03:10,248 INFO close

$ roundup-admin create user username="anonymous" roles="Anonymous"
Enter tracker home: core
2023-12-18 20:03:55,461 INFO open database via service 'roundup_dev'
2023-12-18 20:03:55,493 INFO commit
2023-12-18 20:03:55,494 DEBUG SQL "select nextval('_user_ids') from
dual" None
2023-12-18 20:03:55,495 DEBUG SQL 'select id from _user where
_username=%s and __retired__=%s' ('anonymous', 0)
2023-12-18 20:03:55,496 DEBUG addnode user2 {'username': 'anonymous',
'roles': 'Anonymous', 'password': None, 'address': None, 'realname':
None, 'phone': None, 'organisation': None, 'alternate_addresses': None,
'queries': [], 'timezone': None}
2023-12-18 20:03:55,496 DEBUG SQL 'insert into _user
(_activity,_actor,_address,_alternate_addresses,_creation,_creator,_organisation,_password,_phone,_realname,_roles,_timezone,_username,id)
values (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s)' ('2023-12-18
16:03:55.497', 1, None, None, '2023-12-18 16:03:55.497', 1, None, None,
None, None, 'Anonymous', None, 'anonymous', '2')
2023-12-18 20:03:55,497 DEBUG addjournal user2 <Date
2023-12-18.16:03:55.497> 1 create {}
2023-12-18 20:03:55,497 DEBUG SQL 'insert into user__journal
(nodeid,date,tag,action,params) values (%s,%s,%s,%s,%s)' ('2',
'2023-12-18 16:03:55.497', '1', 'create', '{}')
2
2023-12-18 20:03:55,497 INFO commit
2023-12-18 20:03:55,505 INFO close


roundup_dev=> select * from public._user;
        _activity        | _actor | _address | _alternate_addresses |   
    _creation        | _creator | _organisation | _password | _phone |
_realname |  _roles   | _timezone | _username | id | __retired__ 
-------------------------+--------+----------+----------------------+-------------------------+----------+---------------+-----------+--------+-----------+-----------+-----------+-----------+----+-------------
 2023-12-18 16:03:10.245 |      1 |          |                      |
2023-12-18 16:03:10.245 |        1 |               |           |       
|           | Admin     |           | admin     |  1 |           0
 2023-12-18 16:03:55.497 |      1 |          |                      |
2023-12-18 16:03:55.497 |        1 |               |           |       
|           | Anonymous |           | anonymous |  2 |           0
(2 rows)



Second, there is a problem with using a schema other than 'public'. I
can't perform database migration when I create scheme named by my
postgresql username and use it in search_path. I see that Roundup
expected me to use the 'public' schema.


$ roundup-admin migrate
Enter tracker home: core
2023-12-18 03:13:02,011 INFO open database via service 'roundup_dev'
2023-12-18 03:13:02,033 INFO rollback
2023-12-18 03:13:02,033 DEBUG SQL 'CREATE TABLE schema (schema TEXT)'
None
2023-12-18 03:13:02,044 DEBUG SQL 'CREATE TABLE dual (dummy integer)'
None
2023-12-18 03:13:02,046 DEBUG SQL 'insert into dual values (1)' None
2023-12-18 03:13:02,047 DEBUG SQL 'CREATE TABLE otks (otk_key
VARCHAR(255),\n            otk_value TEXT, otk_time float)' None
2023-12-18 03:13:02,055 DEBUG SQL 'CREATE INDEX otks_key_idx ON
otks(otk_key)' None
2023-12-18 03:13:02,060 DEBUG SQL 'CREATE TABLE sessions (\n           
session_key VARCHAR(255), session_time float,\n            session_value
TEXT)' None
2023-12-18 03:13:02,065 DEBUG SQL 'CREATE INDEX sessions_key_idx ON\n   
        sessions(session_key)' None
2023-12-18 03:13:02,069 DEBUG SQL 'CREATE SEQUENCE ___textids_ids' None
2023-12-18 03:13:02,070 DEBUG SQL 'CREATE TABLE __textids (\n           
_textid integer primary key, _class VARCHAR(255),\n            _itemid
VARCHAR(255), _prop VARCHAR(255))' None
2023-12-18 03:13:02,079 DEBUG SQL 'CREATE TABLE __words (_word
VARCHAR(55),\n            _textid integer)' None
2023-12-18 03:13:02,080 DEBUG SQL 'CREATE INDEX words_word_idx ON
__words(_word)' None
2023-12-18 03:13:02,087 DEBUG SQL 'CREATE INDEX words_by_id ON __words
(_textid)' None
2023-12-18 03:13:02,092 DEBUG SQL 'CREATE UNIQUE INDEX
__textids_by_props ON __textids (_class, _itemid, _prop)' None
2023-12-18 03:13:02,097 DEBUG SQL 'DELETE FROM otks' None
2023-12-18 03:13:02,097 DEBUG SQL 'ALTER TABLE otks DROP otk_value' None
2023-12-18 03:13:02,098 DEBUG SQL 'ALTER TABLE otks ADD otk_value TEXT'
None
2023-12-18 03:13:02,099 DEBUG SQL 'DELETE FROM sessions' None
2023-12-18 03:13:02,099 DEBUG SQL 'ALTER TABLE sessions DROP
session_value' None
2023-12-18 03:13:02,099 DEBUG SQL 'ALTER TABLE sessions ADD
session_value TEXT' None
2023-12-18 03:13:02,100 DEBUG SQL 'CREATE INDEX words_both_idx ON
public.__words\n            USING btree (_word, _textid)' None
Traceback (most recent call last):
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 217, in open_connection
    self.load_dbschema()
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/rdbms_common.py",
line 305, in load_dbschema
    self.cursor.execute('select schema from schema')
psycopg2.errors.UndefinedTable: relation "schema" does not exist
LINE 1: select schema from schema
                           ^


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/user/Projects/www/roundup_dev/env/bin/roundup-admin", line
8, in <module>
    sys.exit(run())
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/scripts/roundup_admin.py",
line 50, in run
    sys.exit(tool.main())
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
line 2230, in main
    ret = self.run_command(args)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/admin.py",
line 2114, in run_command
    self.db = tracker.open(self.name)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/instance.py",
line 111, in open
    'db': backend.Database(self.config, name)
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/rdbms_common.py",
line 227, in __init__
    self.open_connection()
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 227, in open_connection
    self.fix_version_3_tables()
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/back_postgresql.py",
line 335, in fix_version_3_tables
    self.sql('''CREATE INDEX words_both_idx ON public.__words
  File
"/home/user/Projects/www/roundup_dev/env/lib64/python3.9/site-packages/roundup/backends/rdbms_common.py",
line 266, in sql
    cursor.execute(sql)
psycopg2.errors.UndefinedTable: relation "public.__words" does not exist


If I only use the 'public' schema for my database, the migration command
works well.

Thank you for your help.

-- 
With appreciation,
Ivanov

Hi John

Nice blog post... Time to change the design and not keeping just the metadata in the (PostgreSQL / mysql) database ...

Br
Norbert

-----Ursprüngliche Nachricht-----
Von: John P. Rouillard <ro...@cs...> 
Gesendet: Montag, 04. Dezember 2023 19:55
An: rou...@li...
Betreff: [Roundup-users] Running Roundup with kubernetes (k3s)

*EXTERNAL source*


Hi Folks:

Over the past few days I got a loaner odroid to work with.

I installed the k3s kubernetes software and got Roundup running.
Details are on the wiki at:


  https://wiki.roundup-tracker.org/DeployWithK3s

It's very much a work in progress. However if any of you are interested and have access to a k8s cluster feel free to try out my yaml (which is one of the worst config languages I have ever worked with).

Have a great week.
--
                                -- rouilj John Rouillard ===========================================================================
My employers don't acknowledge my existence much less my opinions.


_______________________________________________
Roundup-users mailing list
Rou...@li...
https://lists.sourceforge.net/lists/listinfo/roundup-users

Hi Folks:

Over the past few days I got a loaner odroid to work with.

I installed the k3s kubernetes software and got Roundup running.
Details are on the wiki at:


  https://wiki.roundup-tracker.org/DeployWithK3s

It's very much a work in progress. However if any of you are
interested and have access to a k8s cluster feel free to try out my
yaml (which is one of the worst config languages I have ever worked
with).

Have a great week.
--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Hello Ivanov:

In message <202...@pe...>,
"John P. Rouillard" writes:
>In message <bf0...@ri...>,
>iva...@ri... writes:
>>On 2023-11-06 23:13, John P. Rouillard wrote: 
>>> If you want to move forward with Roundup and run multiple trackers
>>> with one Roundup server instance, we can work on getting support for
>>> specifying the 'service' in config.ini. You would need to test using
>>> the current development code.
>>
>>Thank you. At the moment I plan to install only one tracker, but I think
>>it would be nice to have such an option. When you implement this, I will
>>be happy to test it.
>
>Since it only took a couple of hours, I implemented it in: 
>
>    changeset:   7696:4af0d235b570
>    tag:         tip
>    user:        John Rouillard <ro...@ie...>
>    date:        Tue Nov 07 12:11:37 2023 -0500
>    files:       CHANGES.txt doc/reference.txt
>                 roundup/backends/back_postgresql.py
>                 roundup/backends/rdbms_common.py roundup/configuration.py
>
>    description:
>    feat(db): support using postgresql service connection file
>
>    Add new service rdbms config option to set the service name to be used
>    with a postgresql service connection file.
>
>    This can be done using the PGSERVICE environment variable for a single
>    instance tracker server. For a multi-instance server this per-tracker
>    config option is needed.
>
>    Note that settings (host, user, (db)name...) in config.ini file will
>    override the service connection file setting. Also setting PGSERVICE
>    and service will use the service setting.
>
>You can pull the code from the repo using mercurial:
>
>  hg clone http://hg.code.sf.net/p/roundup/code roundup
>
>The issue is tracked at: https://issues.roundup-tracker.org/issue2551299
>
>You can send email to the is...@ro... with the subject:
>
>  [issue2551299] Connecting to PostgreSQL database using pg_service.conf
>
>to followup with any issues or just reply here.

Have you had a chance to test this?

Have a great week.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Hi Tonu:

In message <CAB...@ma...>
,
Tonu Mikk writes:
>Great, this helps a lot! I was able to run the demo tracker by changing the
>line to run the following:
>docker run --rm -p 127.0.0.1:8917:8080 --name roundup_demo -v
>C://users/tmikk/Documents/roundup-demo/usr/src/app/tracker

Are you missing a : between /roundup-demo and /usr?

>rounduptracker/roundup:latest demo
>
>I am not sure though how to run the image on Windows so that I could
>configure my own tracker.

Just to answer the question for others, you can reconfigure the demo
tracker's config.ini changing the web setting and anything else you
want to change.

If you want to make it accessible under the name "my_tracker" at
https://..../my_tracker you run:

   docker run --rm -p 127.0.0.1:8917:8080 --name roundup_demo -v
    C://users/tmikk/Documents/roundup-demo:/usr/src/app/tracker
    rounduptracker/roundup:latest my_tracker=tracker/demo

(You could also change the directory name from demo if you wish.)

If the argument after the docker image is not one of the special
command words:

 demo

 shell

or

 admin

the docker container starts roundup-server and passes all the
arguments after the docker image specification to roundup-server.

If there are no arguments it uses 'issue=tracker' and assumes that the
tracker home directory is the directory specified with -v. (With demo,
the tracker home is placed in a subdirectory of the directory
specified with -v.)

The proper argument is kind of hinted at in the section:

  Arguments for roundup-server

  Once you have initialized your tracker, any arguments placed at the
  end of the docker run command are passed to the
  roundup-server. These arguments replace the default arguments of
  issues=tracker.

under:

  https://roundup-tracker.org/docs/installation.html#running-your-container

Would it have helped you if I included a full docker command line in
that section?

>But I think I will leave it at that for now. I
>probably won't be using a Docker container to run Roundup.

Fair enough. I don't know how stable docker is on Windows.

>I also looked into installing Docker on RedHat 7, but wasn't successful.
>Followed a couple of guides, but didn't get it to work.

That's sort of what I expected. RedHat 7 is on its last legs at this
point.

>I will try using the Postgresql backend on RedHat 7 if I can get the
>libraries to work.

If you are using PostgreSQL, make sure that you either export/dump the
database or follow the PostgreSQL directions on executing a proper
point-in-time backup of the disk files. I have had a couple of people
who were just backing up the PostgreSQL files on a busy tracker
without properly configuring/notifying PostgreSQL. They found out the
hard way that they didn't really have recent backups of the data 8-(.

SQLite has the same concerns over getting a consistent backup. But it
appears to be more resilient when you backup the database file by
copying.

Have a great week.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Great, this helps a lot! I was able to run the demo tracker by changing the
line to run the following:
docker run --rm -p 127.0.0.1:8917:8080 --name roundup_demo -v
C://users/tmikk/Documents/roundup-demo/usr/src/app/tracker
rounduptracker/roundup:latest demo

I am not sure though how to run the image on Windows so that I could
configure my own tracker. But I think I will leave it at that for now. I
probably won't be using a Docker container to run Roundup.

I also looked into installing Docker on RedHat 7, but wasn't successful.
Followed a couple of guides, but didn't get it to work. I will try using
the Postgresql backend on RedHat 7 if I can get the libraries to work.

On Tue, Nov 14, 2023 at 2:18 PM John P. Rouillard <ro...@cs...> wrote:

> Hi Tonu:
>
> In message
> <CAB...@ma...>,
> Tonu Mikk via Roundup-users writes:
> >I attempted to run the Roundup docker image
> ><https://hub.docker.com/r/rounduptracker/roundup> and wasn't able to
> figure
> >it out.
>
> The installation guide has a section on running demo mode:
>
>
> https://roundup-tracker.org/docs/installation.html#demo-mode-using-docker
>
> however it expects to run with a Linux/Unix docker environment.
>
> I have never used docker in Windows. If your RedHat 7 box can run
> docker you may have more luck. But the version of Docker available
> there may be old enough that you will run into other issues.
>
> >I have the Docker desktop installed on my Windows 10 computer. I
> >then searched and found the Roundup docker image in the Docker Hub. I
> >pulled it. When I run the image in the Docker Desktop I get the following
> >printed out in the logs shown in Docker Desktop.  I have a feeling I am
> >doing something wrong, just not sure what.
> >
> >2023-11-14 10:00:26 Traceback (most recent call last):
> >[...]
> >2023-11-14 10:00:26     template = self._get_choice(
> >2023-11-14 10:00:26                ^^^^^^^^^^^^^^^^^
> >2023-11-14 10:00:26   File
> >"/usr/local/lib/python3.11/site-packages/roundup/admin.py", line 409, in
> >_get_choice
> >2023-11-14 10:00:26     argument = self.my_input('%s [%s]: ' % (prompt,
> >default))
> >2023-11-14 10:00:26
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >2023-11-14 10:00:26 EOFError: EOF when reading a line
> >2023-11-14 10:00:26 Installing issues tracker in tracker
> >2023-11-14 10:00:26 Templates:: jinja2, minimal, responsive, devel,
> classic
> >2023-11-14 10:00:26 Select template [classic]:
>
> It looks like you started the container in config mode but without
> interactive and terminal mode. You must use the -it flags as shown in:
>
>
> https://roundup-tracker.org/docs/installation.html#configuring-roundup-in-the-container
>
> >When I attempt to run the "instant gratification" of the demo tracker. I
> >first opened a command prompt and then did the tried to run
> >
> >> docker run --rm -p 127.0.0.1:8917:8080 --name roundup_demo -v \
> >>    $PWD:/usr/src/app/tracker rounduptracker/roundup:latest demo
>
> The command line expects a Unix shell (e.g. bash), but you are using
> windows cmd shell. So the \ at the end of the line doesn't join the
> two lines above. As a result docker doesn't see any of the arguments
> on the second line and reports the error above.
>
> You should be able to get past this by pasting the first and second
> lines (before and after the '\'; note don't paste the '\') on the same
> window command line.
>
> >and got this:
> >
> >--C:\Users\tmikk\Documents\roundup-demo>docker run --rm -p 127.0.0.1:8917
> :8080
> >--name roundup_demo -v \
> >"docker run" requires at least 1 argument.
> >See 'docker run --help'.
> >
> >Usage:  docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
> >
> >Create and run a new container from an image
> >
> >C:\Users\tmikk\Documents\roundup-demo>   $PWD:/usr/src/app/tracker
> >rounduptracker/roundup:latest demo
> >'$PWD:' is not recognized as an internal or external command,
> >operable program or batch file.
>
> Yup. The Windows command shell split that into two two separate
> lines/commands (docker and the line starting with $PWD). Docker needs
> to see one long command line.
>
> Also $PWD is replaced by the Unix shell with the current working
> directory (PWD => print working directory). I think the equivalent
> under windows is %CD%, but you may need to type the actual working
> directory.  The working directory will be the parent directory of your
> tracker's home directory.
>
> As I said I don't use docker under windows, so YMMV. Maybe somebody
> else on list is more familiar with the windows docker environment.
>
> Also you probably want to read:
>
>
> https://roundup-tracker.org/docs/installation.html#running-in-demo-mode-with-docker
>
>
> https://roundup-tracker.org/docs/installation.html#configuring-roundup-in-the-container
>
>
> https://roundup-tracker.org/docs/installation.html#running-your-container
>
> Also one open issue with the docker install is receiving
> email. Sending email works with the use of an external email server.
> Receiving email probably requires setting up something using the
> host's crontab (or Task Scheduler on Windows) with a command like:
>
>    docker exec roundup-tracker roundup-mailgw tracker \
>          imap username:password@imap_server inbox
>
> (again join the two lines omitting the '\' if you use the Task
> Scheduler). This might be a solution if you can use pop/imap to
> receive email. If you are not receiving/interacting with issues via
> email you don't have to worry about roundup-mailgw.
>
> Have a great day.
>
> --
>                                 -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>


-- 
Tonu Mikk
Developer | Disability Resource Center | disability.umn.edu
University of Minnesota | umn.edu
tm...@um...
Pronouns: He/Him

Hi Tonu:

In message
<CAB...@ma...>,
Tonu Mikk via Roundup-users writes:
>I attempted to run the Roundup docker image
><https://hub.docker.com/r/rounduptracker/roundup> and wasn't able to figure
>it out.

The installation guide has a section on running demo mode:

  https://roundup-tracker.org/docs/installation.html#demo-mode-using-docker

however it expects to run with a Linux/Unix docker environment.

I have never used docker in Windows. If your RedHat 7 box can run
docker you may have more luck. But the version of Docker available
there may be old enough that you will run into other issues.

>I have the Docker desktop installed on my Windows 10 computer. I
>then searched and found the Roundup docker image in the Docker Hub. I
>pulled it. When I run the image in the Docker Desktop I get the following
>printed out in the logs shown in Docker Desktop.  I have a feeling I am
>doing something wrong, just not sure what.
>
>2023-11-14 10:00:26 Traceback (most recent call last):
>[...]
>2023-11-14 10:00:26     template = self._get_choice(
>2023-11-14 10:00:26                ^^^^^^^^^^^^^^^^^
>2023-11-14 10:00:26   File
>"/usr/local/lib/python3.11/site-packages/roundup/admin.py", line 409, in
>_get_choice
>2023-11-14 10:00:26     argument = self.my_input('%s [%s]: ' % (prompt,
>default))
>2023-11-14 10:00:26
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>2023-11-14 10:00:26 EOFError: EOF when reading a line
>2023-11-14 10:00:26 Installing issues tracker in tracker
>2023-11-14 10:00:26 Templates:: jinja2, minimal, responsive, devel, classic
>2023-11-14 10:00:26 Select template [classic]:

It looks like you started the container in config mode but without
interactive and terminal mode. You must use the -it flags as shown in:

  https://roundup-tracker.org/docs/installation.html#configuring-roundup-in-the-container

>When I attempt to run the "instant gratification" of the demo tracker. I
>first opened a command prompt and then did the tried to run
>
>> docker run --rm -p 127.0.0.1:8917:8080 --name roundup_demo -v \
>>    $PWD:/usr/src/app/tracker rounduptracker/roundup:latest demo

The command line expects a Unix shell (e.g. bash), but you are using
windows cmd shell. So the \ at the end of the line doesn't join the
two lines above. As a result docker doesn't see any of the arguments
on the second line and reports the error above.

You should be able to get past this by pasting the first and second
lines (before and after the '\'; note don't paste the '\') on the same
window command line.

>and got this:
>
>--C:\Users\tmikk\Documents\roundup-demo>docker run --rm -p 127.0.0.1:8917:8080
>--name roundup_demo -v \
>"docker run" requires at least 1 argument.
>See 'docker run --help'.
>
>Usage:  docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
>
>Create and run a new container from an image
>
>C:\Users\tmikk\Documents\roundup-demo>   $PWD:/usr/src/app/tracker
>rounduptracker/roundup:latest demo
>'$PWD:' is not recognized as an internal or external command,
>operable program or batch file.

Yup. The Windows command shell split that into two two separate
lines/commands (docker and the line starting with $PWD). Docker needs
to see one long command line.

Also $PWD is replaced by the Unix shell with the current working
directory (PWD => print working directory). I think the equivalent
under windows is %CD%, but you may need to type the actual working
directory.  The working directory will be the parent directory of your
tracker's home directory.

As I said I don't use docker under windows, so YMMV. Maybe somebody
else on list is more familiar with the windows docker environment.

Also you probably want to read:

  https://roundup-tracker.org/docs/installation.html#running-in-demo-mode-with-docker

  https://roundup-tracker.org/docs/installation.html#configuring-roundup-in-the-container

  https://roundup-tracker.org/docs/installation.html#running-your-container

Also one open issue with the docker install is receiving
email. Sending email works with the use of an external email server.
Receiving email probably requires setting up something using the
host's crontab (or Task Scheduler on Windows) with a command like:

   docker exec roundup-tracker roundup-mailgw tracker \
         imap username:password@imap_server inbox

(again join the two lines omitting the '\' if you use the Task
Scheduler). This might be a solution if you can use pop/imap to
receive email. If you are not receiving/interacting with issues via
email you don't have to worry about roundup-mailgw.

Have a great day.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Hi,

I attempted to run the Roundup docker image
<https://hub.docker.com/r/rounduptracker/roundup> and wasn't able to figure
it out. I have the Docker desktop installed on my Windows 10 computer. I
then searched and found the Roundup docker image in the Docker Hub. I
pulled it. When I run the image in the Docker Desktop I get the following
printed out in the logs shown in Docker Desktop.  I have a feeling I am
doing something wrong, just not sure what.

2023-11-14 10:00:26 Traceback (most recent call last):
2023-11-14 10:00:26   File "/usr/local/bin/roundup-admin", line 8, in
<module>
2023-11-14 10:00:26     sys.exit(run())
2023-11-14 10:00:26              ^^^^^
2023-11-14 10:00:26   File
"/usr/local/lib/python3.11/site-packages/roundup/scripts/roundup_admin.py",
line 50, in run
2023-11-14 10:00:26     sys.exit(tool.main())
2023-11-14 10:00:26              ^^^^^^^^^^^
2023-11-14 10:00:26   File
"/usr/local/lib/python3.11/site-packages/roundup/admin.py", line 2152, in
main
2023-11-14 10:00:26     ret = self.run_command(args)
2023-11-14 10:00:26           ^^^^^^^^^^^^^^^^^^^^^^
2023-11-14 10:00:26   File
"/usr/local/lib/python3.11/site-packages/roundup/admin.py", line 2010, in
run_command
2023-11-14 10:00:26     return self.do_install(self.tracker_home, args)
2023-11-14 10:00:26            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-14 10:00:26   File
"/usr/local/lib/python3.11/site-packages/roundup/admin.py", line 1186, in
do_install
2023-11-14 10:00:26     template = self._get_choice(
2023-11-14 10:00:26                ^^^^^^^^^^^^^^^^^
2023-11-14 10:00:26   File
"/usr/local/lib/python3.11/site-packages/roundup/admin.py", line 409, in
_get_choice
2023-11-14 10:00:26     argument = self.my_input('%s [%s]: ' % (prompt,
default))
2023-11-14 10:00:26
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-14 10:00:26 EOFError: EOF when reading a line
2023-11-14 10:00:26 Installing issues tracker in tracker
2023-11-14 10:00:26 Templates:: jinja2, minimal, responsive, devel, classic
2023-11-14 10:00:26 Select template [classic]:

When I attempt to run the "instant gratification" of the demo tracker. I
first opened a command prompt and then did the tried to run

> docker run --rm -p 127.0.0.1:8917:8080 --name roundup_demo -v \
>    $PWD:/usr/src/app/tracker rounduptracker/roundup:latest demo


and got this:

--C:\Users\tmikk\Documents\roundup-demo>docker run --rm -p 127.0.0.1:8917:8080
--name roundup_demo -v \
"docker run" requires at least 1 argument.
See 'docker run --help'.

Usage:  docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

Create and run a new container from an image

C:\Users\tmikk\Documents\roundup-demo>   $PWD:/usr/src/app/tracker
rounduptracker/roundup:latest demo
'$PWD:' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\tmikk\Documents\roundup-demo>
Tonu Mikk
Developer | Disability Resource Center | disability.umn.edu
University of Minnesota | umn.edu
tm...@um...
Pronouns: He/Him

Thanks John and Norbert!  I will give a docker container a try.

On Tue, Nov 14, 2023 at 3:55 AM SCHLEMMER Norbert <Nor...@pd...>
wrote:

> Hello
>
> Maybe running Roundup as Docker container helps, maybe with PostgreSQL as
> backend and native fts
>
> Br
> Norbert
>


-- 
Tonu Mikk
Developer | Disability Resource Center | disability.umn.edu
University of Minnesota | umn.edu
tm...@um...
Pronouns: He/Him

Hello

Maybe running Roundup as Docker container helps, maybe with PostgreSQL as backend and native fts

Br
Norbert 

Hi John



Thanks again for your help, got it working...



Br

Norbert





[cid:image001.png@01DA1623.2CF0DCA0]