Menu
▾
▴
roundup-users — Go here to ask questions about how to use Roundup
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(40) |
Sep
(2) |
Oct
(40) |
Nov
(12) |
Dec
(79) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(62) |
Feb
(12) |
Mar
(19) |
Apr
(15) |
May
(22) |
Jun
(20) |
Jul
(23) |
Aug
(28) |
Sep
(74) |
Oct
(74) |
Nov
(80) |
Dec
(203) |
| 2003 |
Jan
(65) |
Feb
(160) |
Mar
(161) |
Apr
(105) |
May
(87) |
Jun
(48) |
Jul
(71) |
Aug
(130) |
Sep
(112) |
Oct
(206) |
Nov
(108) |
Dec
(84) |
| 2004 |
Jan
(309) |
Feb
(128) |
Mar
(246) |
Apr
(266) |
May
(449) |
Jun
(239) |
Jul
(184) |
Aug
(152) |
Sep
(151) |
Oct
(305) |
Nov
(193) |
Dec
(167) |
| 2005 |
Jan
(182) |
Feb
(248) |
Mar
(191) |
Apr
(256) |
May
(152) |
Jun
(55) |
Jul
(120) |
Aug
(103) |
Sep
(125) |
Oct
(85) |
Nov
(85) |
Dec
(64) |
| 2006 |
Jan
(165) |
Feb
(148) |
Mar
(120) |
Apr
(85) |
May
(100) |
Jun
(69) |
Jul
(86) |
Aug
(157) |
Sep
(103) |
Oct
(101) |
Nov
(134) |
Dec
(178) |
| 2007 |
Jan
(110) |
Feb
(67) |
Mar
(224) |
Apr
(108) |
May
(87) |
Jun
(40) |
Jul
(64) |
Aug
(68) |
Sep
(70) |
Oct
(82) |
Nov
(48) |
Dec
(74) |
| 2008 |
Jan
(74) |
Feb
(102) |
Mar
(47) |
Apr
(29) |
May
(40) |
Jun
(18) |
Jul
(19) |
Aug
(88) |
Sep
(69) |
Oct
(43) |
Nov
(13) |
Dec
(25) |
| 2009 |
Jan
(49) |
Feb
(64) |
Mar
(47) |
Apr
(38) |
May
(23) |
Jun
(41) |
Jul
(72) |
Aug
(49) |
Sep
(44) |
Oct
(35) |
Nov
(7) |
Dec
(56) |
| 2010 |
Jan
(171) |
Feb
(42) |
Mar
(31) |
Apr
(68) |
May
(26) |
Jun
(8) |
Jul
(36) |
Aug
(28) |
Sep
(31) |
Oct
(40) |
Nov
(3) |
Dec
(5) |
| 2011 |
Jan
(2) |
Feb
(5) |
Mar
(6) |
Apr
(12) |
May
(6) |
Jun
(15) |
Jul
(17) |
Aug
(7) |
Sep
(13) |
Oct
(30) |
Nov
(17) |
Dec
(4) |
| 2012 |
Jan
(5) |
Feb
(8) |
Mar
(7) |
Apr
(11) |
May
(5) |
Jun
|
Jul
(15) |
Aug
(25) |
Sep
(23) |
Oct
(18) |
Nov
(14) |
Dec
(12) |
| 2013 |
Jan
(18) |
Feb
(8) |
Mar
(9) |
Apr
|
May
|
Jun
(6) |
Jul
(18) |
Aug
(6) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(16) |
| 2014 |
Jan
(13) |
Feb
(22) |
Mar
(10) |
Apr
|
May
(8) |
Jun
(23) |
Jul
(17) |
Aug
(3) |
Sep
(22) |
Oct
(34) |
Nov
(4) |
Dec
(2) |
| 2015 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(3) |
May
(19) |
Jun
(33) |
Jul
(11) |
Aug
(9) |
Sep
|
Oct
|
Nov
(15) |
Dec
(7) |
| 2016 |
Jan
(13) |
Feb
(9) |
Mar
(5) |
Apr
(8) |
May
(2) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2017 |
Jan
(11) |
Feb
(8) |
Mar
(8) |
Apr
(7) |
May
|
Jun
(7) |
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(8) |
Sep
(25) |
Oct
(4) |
Nov
(2) |
Dec
(3) |
| 2019 |
Jan
(20) |
Feb
(26) |
Mar
(18) |
Apr
(2) |
May
(5) |
Jun
(1) |
Jul
(9) |
Aug
(8) |
Sep
(8) |
Oct
(21) |
Nov
(8) |
Dec
(1) |
| 2020 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(15) |
May
(6) |
Jun
(2) |
Jul
(7) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
(5) |
Dec
(5) |
| 2021 |
Jan
|
Feb
(15) |
Mar
(50) |
Apr
(16) |
May
(22) |
Jun
(20) |
Jul
(5) |
Aug
(19) |
Sep
(1) |
Oct
(1) |
Nov
(42) |
Dec
(16) |
| 2022 |
Jan
(9) |
Feb
(5) |
Mar
(2) |
Apr
(6) |
May
(2) |
Jun
(10) |
Jul
(15) |
Aug
(9) |
Sep
(32) |
Oct
|
Nov
(14) |
Dec
(10) |
| 2023 |
Jan
(7) |
Feb
(6) |
Mar
(11) |
Apr
(16) |
May
(14) |
Jun
(7) |
Jul
(17) |
Aug
(1) |
Sep
|
Oct
(44) |
Nov
(24) |
Dec
(13) |
| 2024 |
Jan
(1) |
Feb
(25) |
Mar
(9) |
Apr
(10) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
|
From: John P. R. <ro...@cs...> - 2024-02-17 17:35:38
|
Hi Tonu an Anton: In message <CABDFm8h_YPapJyiYQY+iVX7CcopR7=u7_...@ma...> , Tonu Mikk via Roundup-users writes: >Yeah, this is really odd. It works when I am logged into my personal Chrome >profile, but doesn't work when I logged into our work Chrome profile. We >use Google apps for schools at work. I noticed that the Chrome profile >shows an error message in the Chrome Console. [image removed ...] >On Fri, Feb 16, 2024 at 9:04 PM Anton Savchuk via Roundup-users < >rou...@li...> wrote: >> I followed your link and clicked on the "Login". I've tried this with both >> latest versions of Firefox and Chrome. In both cases, after clicking I get >> the dropdown as expected. >> >> Did you do anything else to make it work? Or do you still have this >> problem? Tonu can you check the network tab of dev tools when loading the page under both profiles. You may see jquery being loaded in your working copy. Where is it loaded from? In your work profile, there should either be an error loading it, or there may be no request for jquery. According to Anton's README.txt about the tracker dependencies, there should not be a dependency on jquery. I wonder if you have an old cached copy of Bootstrap or something in your work profile. Maybe a forced refresh of the page (control-shift-R IIRC) would fix it? Note this may result in something else on the website breaking if the old cached copy and your new copy are incompatible 8-/. Have a great weekend. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
|
From: Tonu M. <tm...@um...> - 2024-02-17 15:21:33
|
Yeah, this is really odd. It works when I am logged into my personal Chrome profile, but doesn't work when I logged into our work Chrome profile. We use Google apps for schools at work. I noticed that the Chrome profile shows an error message in the Chrome Console. [image: image.png] On Fri, Feb 16, 2024 at 9:04 PM Anton Savchuk via Roundup-users < rou...@li...> wrote: > > Hello, Tonu! > > Thank you for your feedback. > > I followed your link and clicked on the "Login". I've tried this with both > latest versions of Firefox and Chrome. In both cases, after clicking I get > the dropdown as expected. > > Did you do anything else to make it work? Or do you still have this > problem? > > *Sent:* Friday, February 16, 2024 at 9:17 PM > *From:* "Tonu Mikk" <tm...@um...> > *To:* "Anton Savchuk" <a.s...@gm...> > *Cc:* rou...@li... > *Subject:* Re: [Roundup-users] Jinja2 based templates updated to > Bootstrap5 > Thanks for working on this, Anton! I tried this and couldn't get the login > to show up. I replaced the HTML and Static directories as noted in the > installation section. See http://music.drc.umn.edu/jazz/ . Anything I > could try? > _______________________________________________ > Roundup-users mailing list > Rou...@li... > https://lists.sourceforge.net/lists/listinfo/roundup-users > -- Tonu Mikk Developer | Disability Resource Center | disability.umn.edu University of Minnesota | umn.edu tm...@um... Pronouns: He/Him |
|
From: Anton S. <a.s...@gm...> - 2024-02-17 03:04:55
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> </div> <div> <div>Hello, Tonu!</div> <div> </div> <div>Thank you for your feedback.</div> <div> </div> <div>I followed your link and clicked on the "Login". I've tried this with both latest versions of Firefox and Chrome. In both cases, after clicking I get the dropdown as expected.</div> <div> </div> <div>Did you do anything else to make it work? Or do you still have this problem?</div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Sent:</b> Friday, February 16, 2024 at 9:17 PM<br/> <b>From:</b> "Tonu Mikk" <tm...@um...><br/> <b>To:</b> "Anton Savchuk" <a.s...@gm...><br/> <b>Cc:</b> rou...@li...<br/> <b>Subject:</b> Re: [Roundup-users] Jinja2 based templates updated to Bootstrap5</div> <div name="quoted-content"> <div>Thanks for working on this, Anton! I tried this and couldn't get the login to show up. I replaced the HTML and Static directories as noted in the installation section. See <a href="http://music.drc.umn.edu/jazz/" target="_blank">http://music.drc.umn.edu/jazz/</a> . Anything I could try?</div> </div> </div> </div> </div></div></body></html> |
|
From: Tonu M. <tm...@um...> - 2024-02-16 17:18:47
|
Thanks for working on this, Anton! I tried this and couldn't get the login to show up. I replaced the HTML and Static directories as noted in the installation section. See http://music.drc.umn.edu/jazz/ . Anything I could try? On Sun, Dec 24, 2023 at 3:05 AM Anton Savchuk via Roundup-users < rou...@li...> wrote: > 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 > > > > _______________________________________________ > Roundup-users mailing list > Rou...@li... > https://lists.sourceforge.net/lists/listinfo/roundup-users > -- Tonu Mikk Developer | Disability Resource Center | disability.umn.edu University of Minnesota | umn.edu tm...@um... Pronouns: He/Him |
|
From: John P. R. <ro...@cs...> - 2024-02-11 16:35:47
|
Hello all: I'm happy to share the news that the capstone project class in graduate software engineering at the University of Massachusetts at Boston has chosen two Roundup projects. The student teams chose: Roundup Classhelper Enhancement https://www.cs.umb.edu/~rouilj/CS682/spring2024/classhelper_enhancement.html The current classhelper has several issues. This project encapsulates the existing classhelper link within a new web-component. The new web component will replace the current frames-based classhelper. It will gracefully revert to the old classhelper if web components are not supported. Additionally, it will address various bugs and utilize the REST interface for searching and populating selection lists. Furthermore, it will serve as the foundation for enhanced helper capabilities in the future. Creating Chart from Index Table https://www.cs.umb.edu/~rouilj/CS682/spring2024/charts_from_index_search.html Building on the concepts in https://wiki.roundup-tracker.org/QueryResultPieCharts, this project aims to enhance the integration of simple charting with Python3. In addition to integrating the existing proof of concept, this project intends to support multiple groupings and potentially other chart types, depending on feasibility. For more complex charting and analysis needs, it is still recommended to download index data via CSV or access the backend database. I hope everybody has a great week. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
|
From: John P. R. <ro...@cs...> - 2024-02-08 15:42:59
|
Hi Tonu: In message <CAB...@ma...>, Tonu Mikk writes: >I got it to work! Congrats. >We have a couple of things we would like to track and I thought that >creating a generic url naming (/piano) might be a good way to go. We may >have more than one tracker and I can add another musical instrument /guitar >for example. It is a bit experimental right now and I don't know if it will >come to fruition. Tracking different types of issues at: https://roundup-tracker.org/docs/customizing.html#tracking-different-types-of-issues might also apply by using a field to track pianos vs guitars vs timpani etc. Have a great week. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
|
From: Tonu M. <tm...@um...> - 2024-02-08 15:41:27
|
Something else to note. When I set the SELinux to "enforcing" the tracker fails. The error log indicates that the tracker is trying to retrieve files from '/home/tmikk/.local/lib/python3.9/site-packages/roundup directory and not finding them. I believe I can modify the SELinux for roundup's use and still set it to "enforcing". On Thu, Feb 8, 2024 at 9:25 AM Tonu Mikk <tm...@um...> wrote: > I got it to work! > > I found the Apache modified wsgi handler in Roundup documentation. I tried > to modify it by using the roundup installation in my home directory > sys.path.insert(0, > '(home/tmikk/.local/lib/python3.9/site-packages/roundup') but that didn't > work. > > I then ran > sudo pip install roundup > > I got this message: > Requirement already satisfied: roundup in > /usr/local/lib/python3.9/site-packages (2.3.0) > WARNING: Running pip as the 'root' user can result in broken permissions > and conflicting behaviour with the system package manager. It is > recommended to use a virtual environment instead: > https://pip.pypa.io/warnings/venv > > I must have tried this command already as Roundup was already installed > using this method. I then used the Roundup's path > (/usr/local/lib/python3.9/site-packages) in the wsgi handler and also > changed the home directory path which made it work. My wsgi handler now > looks like this. > > import sys, os > sys.stdout = sys.stderr > > enabled = True > > if enabled: > # Add the directory with the roundup installation > # subdirectory to the python path. > sys.path.insert(0, ' /usr/local/lib/python3.9/site-packages ') > > # obtain the WSGI request dispatcher > from roundup.cgi.wsgi_handler import RequestDispatcher > > tracker_home = '/opt/trackers/classic' > application = RequestDispatcher(tracker_home) > else: > def application(environ, start_response): > status = '503 Service Unavailable' > output = 'service is down for maintenance' > response_headers = [('Content-type', 'text/plain'), > ('Content-Length', str(len(output)))] > start_response(status, response_headers) > return [output] > > We have a couple of things we would like to track and I thought that > creating a generic url naming (/piano) might be a good way to go. We may > have more than one tracker and I can add another musical instrument /guitar > for example. It is a bit experimental right now and I don't know if it will > come to fruition. > > Thanks for all the help! > > On Wed, Feb 7, 2024 at 3:47 PM Tonu Mikk <tm...@um...> wrote: > >> Thanks for these additional ideas! I am now seeing where the problem is. >> >> The command >> python3 -c 'import sys;print(sys.version); print(sys.prefix);' shows the >> same information as the test_wsgi output: >> 3.9.18 (main, Sep 7 2023, 00:00:00) >> [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] >> /usr >> >> When running >> python3 -c 'import roundup; print(roundup)' >> I get: >> <module 'roundup' from >> '/home/tmikk/.local/lib/python3.9/site-packages/roundup/__init__.py'> >> I had started the roundup install by first creating a python virtual >> environment in my home directory and then installing roundup there using >> pip. Looks like this is where my problem is. I don't even see roundup in >> /usr/lib64/python3.9/site-packages. >> >> I hadn't set the PYTHONPATH environment variable. >> >> The command >> python3 -c 'import sys; print("\n".join(sys.path))' >> >> gives me this output. >> /usr/lib64/python39.zip >> /usr/lib64/python3.9 >> /usr/lib64/python3.9/lib-dynload >> /home/tmikk/.local/lib/python3.9/site-packages >> /usr/lib64/python3.9/site-packages >> /usr/lib/python3.9/site-packages >> >> >> On Wed, Feb 7, 2024 at 3:30 PM John P. Rouillard <ro...@cs...> >> wrote: >> >>> Hi Tonu: >>> >>> In message >>> <CAB...@ma...> , >>> Tonu Mikk writes: >>> >The command >>> > python3 -c 'import roundup' >>> >runs without an error. >>> >>> Stupid idea does: >>> >>> python3 -c 'import sys;print(sys.version); print(sys.prefix);' >>> >>> print the same as your test_wsgi? I expect it will. >>> >>> Also can you run: >>> >>> python3 -c 'import roundup; print(roundup)' >>> >>> to see where the library is? It's possible you have it installed in >>> some odd place that the wsgi python invocation isn't looking. Do you >>> have PYTHONPATH set in your environment per chance? >>> >>> Also running: >>> >>> python3 -c 'import sys; print("\n".join(sys.path))' >>> >>> or printing sys.path from test_wsgi may give us some more info. >>> >>> If that's the case, you can add: >>> >>> # Add the directory with the roundup installation >>> # subdirectory to the python path. >>> sys.path.insert(0, '/home/roundup/install/lib/python') >>> >>> to the wsgi script as mentioned in a couple of places on the >>> installation page (search for sys.path). >>> >>> >I changed the test_wsgi.py to contain this: >>> >import sys >>> > >>> >def application(environ, start_response): >>> > status = '200 OK' >>> > >>> > output = u'' >>> > output += u'sys.version = %s\n' % repr(sys.version) >>> > output += u'sys.prefix = %s\n' % repr(sys.prefix) >>> > >>> > response_headers = [('Content-type', 'text/plain'), >>> > ('Content-Length', str(len(output)))] >>> > start_response(status, response_headers) >>> > >>> > return [output.encode('UTF-8')] >>> > >>> >Now the output in the browser shows: >>> >sys.version = '3.9.18 (main, Sep 7 2023, 00:00:00) \n[GCC 11.4.1 >>> 20230605 >>> >(Red Hat 11.4.1-2)]' >>> >sys.prefix = '/usr' >>> > >>> >I will try to use the virtual environment with mod_wsgi. Thanks for >>> >pointing this out! >>> >>> That's the more resiliant way to do it, but I would like to get to the >>> bottom of the issue you had with a os native installation. >>> >>> 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 >> > > > -- > Tonu Mikk > Developer | Disability Resource Center | disability.umn.edu > University of Minnesota | umn.edu > tm...@um... > Pronouns: He/Him > -- Tonu Mikk Developer | Disability Resource Center | disability.umn.edu University of Minnesota | umn.edu tm...@um... Pronouns: He/Him |
|
From: Tonu M. <tm...@um...> - 2024-02-08 15:26:37
|
I got it to work! I found the Apache modified wsgi handler in Roundup documentation. I tried to modify it by using the roundup installation in my home directory sys.path.insert(0, '(home/tmikk/.local/lib/python3.9/site-packages/roundup') but that didn't work. I then ran sudo pip install roundup I got this message: Requirement already satisfied: roundup in /usr/local/lib/python3.9/site-packages (2.3.0) WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv I must have tried this command already as Roundup was already installed using this method. I then used the Roundup's path (/usr/local/lib/python3.9/site-packages) in the wsgi handler and also changed the home directory path which made it work. My wsgi handler now looks like this. import sys, os sys.stdout = sys.stderr enabled = True if enabled: # Add the directory with the roundup installation # subdirectory to the python path. sys.path.insert(0, ' /usr/local/lib/python3.9/site-packages ') # obtain the WSGI request dispatcher from roundup.cgi.wsgi_handler import RequestDispatcher tracker_home = '/opt/trackers/classic' application = RequestDispatcher(tracker_home) else: def application(environ, start_response): status = '503 Service Unavailable' output = 'service is down for maintenance' response_headers = [('Content-type', 'text/plain'), ('Content-Length', str(len(output)))] start_response(status, response_headers) return [output] We have a couple of things we would like to track and I thought that creating a generic url naming (/piano) might be a good way to go. We may have more than one tracker and I can add another musical instrument /guitar for example. It is a bit experimental right now and I don't know if it will come to fruition. Thanks for all the help! On Wed, Feb 7, 2024 at 3:47 PM Tonu Mikk <tm...@um...> wrote: > Thanks for these additional ideas! I am now seeing where the problem is. > > The command > python3 -c 'import sys;print(sys.version); print(sys.prefix);' shows the > same information as the test_wsgi output: > 3.9.18 (main, Sep 7 2023, 00:00:00) > [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] > /usr > > When running > python3 -c 'import roundup; print(roundup)' > I get: > <module 'roundup' from > '/home/tmikk/.local/lib/python3.9/site-packages/roundup/__init__.py'> > I had started the roundup install by first creating a python virtual > environment in my home directory and then installing roundup there using > pip. Looks like this is where my problem is. I don't even see roundup in > /usr/lib64/python3.9/site-packages. > > I hadn't set the PYTHONPATH environment variable. > > The command > python3 -c 'import sys; print("\n".join(sys.path))' > > gives me this output. > /usr/lib64/python39.zip > /usr/lib64/python3.9 > /usr/lib64/python3.9/lib-dynload > /home/tmikk/.local/lib/python3.9/site-packages > /usr/lib64/python3.9/site-packages > /usr/lib/python3.9/site-packages > > > On Wed, Feb 7, 2024 at 3:30 PM John P. Rouillard <ro...@cs...> > wrote: > >> Hi Tonu: >> >> In message >> <CAB...@ma...> , >> Tonu Mikk writes: >> >The command >> > python3 -c 'import roundup' >> >runs without an error. >> >> Stupid idea does: >> >> python3 -c 'import sys;print(sys.version); print(sys.prefix);' >> >> print the same as your test_wsgi? I expect it will. >> >> Also can you run: >> >> python3 -c 'import roundup; print(roundup)' >> >> to see where the library is? It's possible you have it installed in >> some odd place that the wsgi python invocation isn't looking. Do you >> have PYTHONPATH set in your environment per chance? >> >> Also running: >> >> python3 -c 'import sys; print("\n".join(sys.path))' >> >> or printing sys.path from test_wsgi may give us some more info. >> >> If that's the case, you can add: >> >> # Add the directory with the roundup installation >> # subdirectory to the python path. >> sys.path.insert(0, '/home/roundup/install/lib/python') >> >> to the wsgi script as mentioned in a couple of places on the >> installation page (search for sys.path). >> >> >I changed the test_wsgi.py to contain this: >> >import sys >> > >> >def application(environ, start_response): >> > status = '200 OK' >> > >> > output = u'' >> > output += u'sys.version = %s\n' % repr(sys.version) >> > output += u'sys.prefix = %s\n' % repr(sys.prefix) >> > >> > response_headers = [('Content-type', 'text/plain'), >> > ('Content-Length', str(len(output)))] >> > start_response(status, response_headers) >> > >> > return [output.encode('UTF-8')] >> > >> >Now the output in the browser shows: >> >sys.version = '3.9.18 (main, Sep 7 2023, 00:00:00) \n[GCC 11.4.1 >> 20230605 >> >(Red Hat 11.4.1-2)]' >> >sys.prefix = '/usr' >> > >> >I will try to use the virtual environment with mod_wsgi. Thanks for >> >pointing this out! >> >> That's the more resiliant way to do it, but I would like to get to the >> bottom of the issue you had with a os native installation. >> >> 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 > -- Tonu Mikk Developer | Disability Resource Center | disability.umn.edu University of Minnesota | umn.edu tm...@um... Pronouns: He/Him |
|
From: Tonu M. <tm...@um...> - 2024-02-07 21:48:26
|
Thanks for these additional ideas! I am now seeing where the problem is.
The command
python3 -c 'import sys;print(sys.version); print(sys.prefix);' shows the
same information as the test_wsgi output:
3.9.18 (main, Sep 7 2023, 00:00:00)
[GCC 11.4.1 20230605 (Red Hat 11.4.1-2)]
/usr
When running
python3 -c 'import roundup; print(roundup)'
I get:
<module 'roundup' from
'/home/tmikk/.local/lib/python3.9/site-packages/roundup/__init__.py'>
I had started the roundup install by first creating a python virtual
environment in my home directory and then installing roundup there using
pip. Looks like this is where my problem is. I don't even see roundup in
/usr/lib64/python3.9/site-packages.
I hadn't set the PYTHONPATH environment variable.
The command
python3 -c 'import sys; print("\n".join(sys.path))'
gives me this output.
/usr/lib64/python39.zip
/usr/lib64/python3.9
/usr/lib64/python3.9/lib-dynload
/home/tmikk/.local/lib/python3.9/site-packages
/usr/lib64/python3.9/site-packages
/usr/lib/python3.9/site-packages
On Wed, Feb 7, 2024 at 3:30 PM John P. Rouillard <ro...@cs...> wrote:
> Hi Tonu:
>
> In message
> <CAB...@ma...> ,
> Tonu Mikk writes:
> >The command
> > python3 -c 'import roundup'
> >runs without an error.
>
> Stupid idea does:
>
> python3 -c 'import sys;print(sys.version); print(sys.prefix);'
>
> print the same as your test_wsgi? I expect it will.
>
> Also can you run:
>
> python3 -c 'import roundup; print(roundup)'
>
> to see where the library is? It's possible you have it installed in
> some odd place that the wsgi python invocation isn't looking. Do you
> have PYTHONPATH set in your environment per chance?
>
> Also running:
>
> python3 -c 'import sys; print("\n".join(sys.path))'
>
> or printing sys.path from test_wsgi may give us some more info.
>
> If that's the case, you can add:
>
> # Add the directory with the roundup installation
> # subdirectory to the python path.
> sys.path.insert(0, '/home/roundup/install/lib/python')
>
> to the wsgi script as mentioned in a couple of places on the
> installation page (search for sys.path).
>
> >I changed the test_wsgi.py to contain this:
> >import sys
> >
> >def application(environ, start_response):
> > status = '200 OK'
> >
> > output = u''
> > output += u'sys.version = %s\n' % repr(sys.version)
> > output += u'sys.prefix = %s\n' % repr(sys.prefix)
> >
> > response_headers = [('Content-type', 'text/plain'),
> > ('Content-Length', str(len(output)))]
> > start_response(status, response_headers)
> >
> > return [output.encode('UTF-8')]
> >
> >Now the output in the browser shows:
> >sys.version = '3.9.18 (main, Sep 7 2023, 00:00:00) \n[GCC 11.4.1 20230605
> >(Red Hat 11.4.1-2)]'
> >sys.prefix = '/usr'
> >
> >I will try to use the virtual environment with mod_wsgi. Thanks for
> >pointing this out!
>
> That's the more resiliant way to do it, but I would like to get to the
> bottom of the issue you had with a os native installation.
>
> 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
|
|
From: John P. R. <ro...@cs...> - 2024-02-07 21:30:59
|
Hi Tonu:
In message
<CAB...@ma...> ,
Tonu Mikk writes:
>The command
> python3 -c 'import roundup'
>runs without an error.
Stupid idea does:
python3 -c 'import sys;print(sys.version); print(sys.prefix);'
print the same as your test_wsgi? I expect it will.
Also can you run:
python3 -c 'import roundup; print(roundup)'
to see where the library is? It's possible you have it installed in
some odd place that the wsgi python invocation isn't looking. Do you
have PYTHONPATH set in your environment per chance?
Also running:
python3 -c 'import sys; print("\n".join(sys.path))'
or printing sys.path from test_wsgi may give us some more info.
If that's the case, you can add:
# Add the directory with the roundup installation
# subdirectory to the python path.
sys.path.insert(0, '/home/roundup/install/lib/python')
to the wsgi script as mentioned in a couple of places on the
installation page (search for sys.path).
>I changed the test_wsgi.py to contain this:
>import sys
>
>def application(environ, start_response):
> status = '200 OK'
>
> output = u''
> output += u'sys.version = %s\n' % repr(sys.version)
> output += u'sys.prefix = %s\n' % repr(sys.prefix)
>
> response_headers = [('Content-type', 'text/plain'),
> ('Content-Length', str(len(output)))]
> start_response(status, response_headers)
>
> return [output.encode('UTF-8')]
>
>Now the output in the browser shows:
>sys.version = '3.9.18 (main, Sep 7 2023, 00:00:00) \n[GCC 11.4.1 20230605
>(Red Hat 11.4.1-2)]'
>sys.prefix = '/usr'
>
>I will try to use the virtual environment with mod_wsgi. Thanks for
>pointing this out!
That's the more resiliant way to do it, but I would like to get to the
bottom of the issue you had with a os native installation.
Have a great day.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
|
|
From: Tonu M. <tm...@um...> - 2024-02-07 20:49:33
|
The command
python3 -c 'import roundup'
runs without an error.
I changed the test_wsgi.py to contain this:
import sys
def application(environ, start_response):
status = '200 OK'
output = u''
output += u'sys.version = %s\n' % repr(sys.version)
output += u'sys.prefix = %s\n' % repr(sys.prefix)
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output.encode('UTF-8')]
Now the output in the browser shows:
sys.version = '3.9.18 (main, Sep 7 2023, 00:00:00) \n[GCC 11.4.1 20230605
(Red Hat 11.4.1-2)]'
sys.prefix = '/usr'
I will try to use the virtual environment with mod_wsgi. Thanks for
pointing this out!
'3.9.18 (main, Sep 7 2023, 00:00:00) \n[GCC 11.4.1 20230605 (Red Hat
11.4.1-2)]'
sys.prefix = '/usr'
On Tue, Feb 6, 2024 at 5:06 PM John P. Rouillard <ro...@cs...> wrote:
> Hi Tonu:
>
> In message <CABDFm8gy3bPV+sk_kKtqfENncALrA9c-dY5X+OWW==
> mhQ...@ma...>
> ,
> Tonu Mikk writes:
> >Thanks Ralf and John! The file permissions need fixing. And there was
> >indeed an error in the Apache Virtual config file. The line
> >
> > WSGIScriptAlias /piano /opt/trackers/classic_wsgi.py
> >
> >Should have been
> > WSGIScriptAlias /piano /opt/trackers/classic/classic_wsgi.py
> >
> >Once I changed it and restarted Apache, I now get the following error:
> >
> >[Tue Feb 06 13:42:39.162045 2024] [wsgi:error] [pid 3131857:tid 3132046]
> >[remote 10.20.27.232:52794] File
> "/opt/trackers/classic/classic_wsgi.py",
> >line 1, in <module>
> >[Tue Feb 06 13:42:39.162058 2024] [wsgi:error] [pid 3131857:tid 3132046]
> >[remote 10.20.27.232:52794] from roundup.cgi.wsgi_handler import
> >RequestDispatcher
> >[Tue Feb 06 13:42:39.162089 2024] [wsgi:error] [pid 3131857:tid 3132046]
> >[remote 10.20.27.232:52794] ModuleNotFoundError: No module named
> 'roundup'
>
> Can you run
>
> python3 -c 'import roundup'
>
> without error?
>
> If so, it looks like test_wsgi isn't running the python environment in
> which you installed Roundup. With your wsgi-test try adding:
>
> import sys
>
> and replace output... with:
>
> output = b'Hooray, mod_wsgi is working: %s, %s' % (sys.version,
> sys.prefix)
>
> That should show your system installed python version and /usr.
>
> If the `python3 -c 'import roundup'` fails, then something went weird
> with your install.
>
> As an aside, you can use a venv created from the vendor's python3 by
> adding a python-home setting.
>
>
> https://modwsgi.readthedocs.io/en/develop/user-guides/virtual-environments.html
>
> Hope this helps.
> --
> -- 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
|
|
From: John P. R. <ro...@cs...> - 2024-02-06 23:06:54
|
Hi Tonu: In message <CABDFm8gy3bPV+sk_kKtqfENncALrA9c-dY5X+OWW==mhQ...@ma...> , Tonu Mikk writes: >Thanks Ralf and John! The file permissions need fixing. And there was >indeed an error in the Apache Virtual config file. The line > > WSGIScriptAlias /piano /opt/trackers/classic_wsgi.py > >Should have been > WSGIScriptAlias /piano /opt/trackers/classic/classic_wsgi.py > >Once I changed it and restarted Apache, I now get the following error: > >[Tue Feb 06 13:42:39.162045 2024] [wsgi:error] [pid 3131857:tid 3132046] >[remote 10.20.27.232:52794] File "/opt/trackers/classic/classic_wsgi.py", >line 1, in <module> >[Tue Feb 06 13:42:39.162058 2024] [wsgi:error] [pid 3131857:tid 3132046] >[remote 10.20.27.232:52794] from roundup.cgi.wsgi_handler import >RequestDispatcher >[Tue Feb 06 13:42:39.162089 2024] [wsgi:error] [pid 3131857:tid 3132046] >[remote 10.20.27.232:52794] ModuleNotFoundError: No module named 'roundup' Can you run python3 -c 'import roundup' without error? If so, it looks like test_wsgi isn't running the python environment in which you installed Roundup. With your wsgi-test try adding: import sys and replace output... with: output = b'Hooray, mod_wsgi is working: %s, %s' % (sys.version, sys.prefix) That should show your system installed python version and /usr. If the `python3 -c 'import roundup'` fails, then something went weird with your install. As an aside, you can use a venv created from the vendor's python3 by adding a python-home setting. https://modwsgi.readthedocs.io/en/develop/user-guides/virtual-environments.html Hope this helps. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
|
From: Tonu M. <tm...@um...> - 2024-02-06 19:50:16
|
Thanks Ralf and John! The file permissions need fixing. And there was indeed an error in the Apache Virtual config file. The line WSGIScriptAlias /piano /opt/trackers/classic_wsgi.py Should have been WSGIScriptAlias /piano /opt/trackers/classic/classic_wsgi.py Once I changed it and restarted Apache, I now get the following error: [Tue Feb 06 13:42:39.162045 2024] [wsgi:error] [pid 3131857:tid 3132046] [remote 10.20.27.232:52794] File "/opt/trackers/classic/classic_wsgi.py", line 1, in <module> [Tue Feb 06 13:42:39.162058 2024] [wsgi:error] [pid 3131857:tid 3132046] [remote 10.20.27.232:52794] from roundup.cgi.wsgi_handler import RequestDispatcher [Tue Feb 06 13:42:39.162089 2024] [wsgi:error] [pid 3131857:tid 3132046] [remote 10.20.27.232:52794] ModuleNotFoundError: No module named 'roundup' On Tue, Feb 6, 2024 at 1:32 PM John P. Rouillard <ro...@cs...> wrote: > Hi Tonu: > > In message > <CABDFm8j=AtOWt2EapqaNznqe=b25...@ma...> , > Tonu Mikk via Roundup-users writes: > >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 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 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Should this be /opt/trackers/classic/classic_wsgi.py so that the > Require applies? > > > 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: > > Looks like you told apache it was one directory up. > > > - 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: > >> [...] > >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". > > Yup the classic directory and therefore access to classic/test_wsgi > is allowed by Required. > > As Ralf noted, mode 777 is not what you want. My guess is mode 750 is > probably better for everything except for the db directory. The db > directory should be 770 with a setgid bit so the group is > inherited. > > Also the wsgi might need to set the os.umask to 002 (or 007 if you > want to secure the created files/directories from other users). That > way when Roundup creates new directories under db/{files,msgs} they > will be writable to mytrackergrp. If you have others in that group, > they can edit/remove files/messages if needed. If you are the only > person who will be doing maintenance, then the default umask of 022 > will work fine. > > Also as Ralf noted, he allowed access to just the wsgi script from > apache, not the tracker home. This should prevent apache from > accessing any of the tracker home. I haven't worked with apache in > years, so I'm not sure if your current config could allow a web user > to somehow request config.ini and see passwords etc. located in that > file. > > The install guide is light on a manual apache mod_wsgi setup. > > Also I am intrigued by your choice of path. What are you tracking on > pianos? Tuning requests? > > Hope this helps. > -- > -- 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 |
|
From: John P. R. <ro...@cs...> - 2024-02-06 19:22:12
|
Hi Tonu: In message <CABDFm8j=AtOWt2EapqaNznqe=b25...@ma...> , Tonu Mikk via Roundup-users writes: >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 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Should this be /opt/trackers/classic/classic_wsgi.py so that the Require applies? > 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: Looks like you told apache it was one directory up. > - 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: >> [...] >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". Yup the classic directory and therefore access to classic/test_wsgi is allowed by Required. As Ralf noted, mode 777 is not what you want. My guess is mode 750 is probably better for everything except for the db directory. The db directory should be 770 with a setgid bit so the group is inherited. Also the wsgi might need to set the os.umask to 002 (or 007 if you want to secure the created files/directories from other users). That way when Roundup creates new directories under db/{files,msgs} they will be writable to mytrackergrp. If you have others in that group, they can edit/remove files/messages if needed. If you are the only person who will be doing maintenance, then the default umask of 022 will work fine. Also as Ralf noted, he allowed access to just the wsgi script from apache, not the tracker home. This should prevent apache from accessing any of the tracker home. I haven't worked with apache in years, so I'm not sure if your current config could allow a web user to somehow request config.ini and see passwords etc. located in that file. The install guide is light on a manual apache mod_wsgi setup. Also I am intrigued by your choice of path. What are you tracking on pianos? Tuning requests? Hope this helps. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
|
From: Ralf S. <rs...@ru...> - 2024-02-06 18:37:07
|
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... |
|
From: Ralf S. <rs...@ru...> - 2024-02-06 18:30:19
|
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...
|
|
From: Tonu M. <tm...@um...> - 2024-02-06 17:35:39
|
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 |
|
From: John P. R. <ro...@cs...> - 2024-01-02 19:25:42
|
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.
|
|
From: John P. R. <ro...@cs...> - 2023-12-27 15:19:47
|
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. |
|
From: John P. R. <ro...@cs...> - 2023-12-27 15:15:07
|
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.
|
|
From: Nagy G. <gab...@gm...> - 2023-12-27 14:57:47
|
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. |
|
From: Nagy G. <gab...@gm...> - 2023-12-27 14:35:20
|
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
|
|
From: Anton S. <a.s...@gm...> - 2023-12-24 11:15:31
|
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. |
|
From: Nagy G. <gab...@gm...> - 2023-12-23 19:37:26
|
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
|
64 messages has been excluded from this view by a project administrator.