Not logged in. · Lost password · Register

All posts by justjed (12)

topic: selinux ACLs for write access, and php's is_writeable() function -- can't work? (install.php fails due to access error in /data/ directory, but apache/php has access via ACL)  in the forum: General Help and Support Installation and Configuration
Avatar
justjed #1
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
Sorry for the delay in getting back to you. The SA didn't get back to me with any attempts/results for changing the ACLs. Instead, finally, what I got was a whole new server instance, no ACLs, and an SELinux context which I think isn't necessary, but also doesn't appear to do any damage either. I have sudo, so now can chown -R apache;apache the whole DOCUMENT_ROOT.

However, CentOS 7.5.1804 has a 5.4 version of PHP, so install.php won't proceed. That's a whole nother problem, and I'd rather be on a LTS release of Ubuntu Server. Oh well -- not my call, at least not yet.

Thanks for helping.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
topic: selinux ACLs for write access, and php's is_writeable() function -- can't work? (install.php fails due to access error in /data/ directory, but apache/php has access via ACL)  in the forum: General Help and Support Installation and Configuration
Avatar
justjed #2
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
In reply to post ID 63868
Quote by Michaelsy:
Maybe you receive a meaningful error message if you write a small PHP script that performs such a write access?

Oh, I should've tried that. I've not done any meaningful IT work in a couple decades - quite rusty. Anyways, I get a permission error on the fopen(), but no specifics. If other options come to naught, I'll have to dig into PHP to see about enhancing the error reporting.

getfacl /where/your/dokuwikifiles/are/.
getfacl /where/your/dokuwikifiles/are/data
document_root:
user::rwx
user:apache:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:apache:rwx
default:group::rwx
default:mask::rwx
default:other::r-x
data/
user::rwx
user:apache:rwx                 #effective:r-x
group::rwx                      #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:user:apache:rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Hmmm, that "effective" comment could be the pointer to the issue. I found an article mentioning that getfacl adds this comment to indicate the "effective" result. I will have to point this out to the sysadmin. I haven't messed with ACLs since VMS 4.0, in 1984; I bet Posix ACLs are a bit different. :-D

what is the result of ls -Z in dokuwiki directory?

The unconfined_u:object_r:httpd_sys_rw_content_t:s0 is there, as in the 1st StackExchange example, but not the httpd_sys_rw_content_t. So, a second thing to suggest.

Thank you both.

Addendum: my test script to open a file for write works in document_root, but not data/ so I think it must be the difference in the ACL, as in "#effective: r-x".
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
topic: selinux ACLs for write access, and php's is_writeable() function -- can't work? (install.php fails due to access error in /data/ directory, but apache/php has access via ACL)  in the forum: General Help and Support Installation and Configuration
Avatar
justjed #3
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
In reply to post ID 63863
Thank you for the clarification. Yes, both selinux and ACLs are in use. In re-reading my post, I see I manged to omit the critical part of the description. install.php exits with a message complaining about the data/ dir not being writeable. With no error messages in the Apache logs, I can't tell what the underlying reason for that is.

Apache is running as user/group apache:apache, and the document_root for Dokuwiki is not owned by apache. Access for Apache to that directory is granted via a selinux context/labels and ACL. The sysadmin claims he has tested this and it works for him.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
This post was edited on 2018-12-14, 15:04 by justjed.
topic: selinux ACLs for write access, and php's is_writeable() function -- can't work? (install.php fails due to access error in /data/ directory, but apache/php has access via ACL)  in the forum: General Help and Support Installation and Configuration
Avatar
justjed #4
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
Subject: selinux ACLs for write access, and php's is_writeable() function -- can't work?
I'm trying to install DokuWiki in an environment where the server admin doesn't want to chown -R apache:apache for the DokuWiki directory tree, and (so far) hasn't shown interest in using the PHP-FPM plugin to run scripts as the script owner. His approach has been to grant write access using a selinux ACL. OS is CentOS Linux release 7.6.1810 (Core). DokuWiki 2018-04-22a.

The docs at https://secure.php.net/manual/en/function.is-writable.php don't really address this, but there's a contributed note mentioning a way to have is_writeable() use GID instead of UID, so that implies that php is doing only a user ID check against the directory / file permissions.

I'm reluctant to comment out the check in install.php, as I've found a few other instances of is_writable() in the php code.

Am I correct that is_writeable() doesn't properly involve ACL permissions? I did find a couple really old bug reports against PHP for this, but nothing recent.

Advice appreciated.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
topic: Media Upload Fails -- is a manual workaround possible? (Greebo) (Large file upload is failing - used to work. If I upload using sftp, can I manually create metadata?)  in the forum: General Help and Support General Stuff
Avatar
justjed #5
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
In reply to post ID 63064
Quote by Michaelsy:
I've often uploaded media files via FTP, but I've never cared about the changes information. As far as I know, .changes only provides the user with additional information. This means that this information is not relevant to the functionality of the system.

HTH - Michael Sy.

Ah, okay. Thanks. I figured Doku was doing some sort of indexing or something.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
topic: Media Upload Fails -- is a manual workaround possible? (Greebo) (Large file upload is failing - used to work. If I upload using sftp, can I manually create metadata?)  in the forum: General Help and Support General Stuff
Avatar
justjed #6
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
Subject: Media Upload Fails -- is a manual workaround possible? (Greebo)
I'm running Release 2018-04-22a "Greebo". Probably, the version doesn't matter. I've previously uploaded files in media manager up to 20MB. Now, I'm trying to upload a 13MB file, and it runs to about 64% and then fails with no error message in DokuWiki other than "Failed".

I've gone into cPanel and looked at the "Errors" display, and found none. I've downloaded the raw Apache logs and found the PUT request for the file, but there are no error messages there either. Nor am I out of disk space or other resources on the host.

I've found other discussions speaking to config options for size limits, but at the moment, I'm pretty unsure how I'd pursue that with GoDaddy, and their wait time in chat is 72 minutes. Ugh! 8-(

Since I have ssh access, I can upload the file in question using sftp. If I then manually create the appropriate file in data/media_meta/{namespace}, is that a possible workaround? (Yes, I know, I will need to pursue a correction if possible at some point, but I need to get this done.)

If that'll work, can someone tell me what needs to be in the .changes file? Some columns are obvious, but the 1st column is a large integer, and I don't know what that is.

Thanks.

Update: I am able to upload the file using the File Manager function of cPanel. Maybe that's meaningless, but if there were a hard limit in the Apache config, wouldn't cPanel be affected as well?
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
This post was edited on 2018-10-11, 03:29 by justjed.
topic: Sound Player Widget Does Not Appear for Certain Media  in the forum: General Help and Support General Stuff
Avatar
justjed #7
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
In reply to post ID 55263
Oh, good grief!
amtor.wav:     RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 8000 Hz
clover.wav:    RIFF (little-endian) data, WAVE audio, Microsoft ADPCM, mono 22050 Hz

I'm tempted to file a webkit bug. The files that don't work are both Adaptive differential pulse-code modulation. Shouldn't matter, but obviously it does.

Again,thanks.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
topic: Sound Player Widget Does Not Appear for Certain Media  in the forum: General Help and Support General Stuff
Avatar
justjed #8
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
In reply to post ID 55257
I am using uBlock Origin, but I have re-tested to check, being sure to 'disable for this site', and also toggled the 'large media elements' just for fun.

There are many messages in the dev console. One seems relevant
Timestamp: 01/27/2017 09:29:56 AM
Warning: Media resource http://localhost/na0tc/lib/exe/fetch.php?media=audio:sound_clover.wav could not be decoded.
Source File: http://localhost/na0tc/doku.php?id=documents#section2007
Line: 0

This is puzzling, since it's a WAV file. It also plays in the browser, if I click on the link to the file, either on the page, or in the media manager. In this case, it plays via the VideoLanClient plugin. And, on my local system, it plays from the command line using the 'play' command in Linux. I'm quite puzzled by the 'could not be decoded' message, as I would assume that the browser is using the same underlying libraries to handle media formats. I could be mistaken in this, but I suppose it's possible.

You've given me some things to look into, in further experiments. Thank you.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
topic: CQ CQ from Somewhere in the U.S.  in the forum: Community User Introductions
Avatar
justjed #9
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
In reply to post ID 55252
For benefit of anyone attempting to send me a PM:

https://forum.dokuwiki.org/thread/6427
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
topic: Forum: private mails limited (only active members can use it)  in the forum: Announcements and Rules
Avatar
justjed #10
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
In reply to post ID 49454
While I recognize difficulties in dealing with spam, this approach creates the difficulty that new users are unable to reply to PMs initiated by other users. Possibly, a better method would be to restrict initiation of a PM, but still permit replies. As it is, I'm now unable to reply to a PM without exposing my e-mail address, thus giving the impression of just blowing off the message, so the sender will think maybe I'm just an inconsiderate sod.

No doubt, attempting to do this is difficult given that the PM system relies on external e-mail.

Perhaps it'd be best to also prohibit sending PMs to user who can't reply via the forum. Or maybe include a warning on the PM form when the recipient is in this restricted class.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
topic: Sound Player Widget Does Not Appear for Certain Media  in the forum: General Help and Support General Stuff
Avatar
justjed #11
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
Subject: Sound Player Widget Does Not Appear for Certain Media
DokuWiki Version: Release 2016-06-26a "Elenor of Tsort"
Environment:
 - GoDaddy Linux cPanel shared hosting, and
 - Local install, Linux Mint 17.3, Apache2

I have several .WAV files in the :audio: namespace. Using the media linkage, the generated page displays a player widget in the browser for each of them, except two. Syntax for one of the non-working is:
{{ :audio:sound_clover.wav |CLOVER}}
Using the ?linkonly attribute results in a link to the media file, so it seems that internal name/location resolution is working.
Using the root:audio: namespace results in the player widget being displayed, but it it unresponsive.
{{ root:audio:sound_clover.wav }}
FWIW: There are 11 working .WAV files, and 2 non-working. in addition to sound_clover.wav, the other non-working is mt63-c.wav. All the audio files are in the audio namespace, and all behave as expected in the media manager.

I have isolated the sound_clover.wav media link in the playground, in order to rule out some odd interaction with other markup or page elements, and the results are the same. I also renamed the file from clover.wav to sound_clover.wav, to rule out some odd interaction with the filename itself -- same behaviour was observed using the original filename of just "clover".

http://new.na0tc.org/doku.php?id=playground:playground

Identical behavior is reproduced on my local system also in a Wiki using Release 2015-08-10a "Detritus"

Permission is granted to download the "clover" wav file for anyone who wishes to attempt to reproduce the problem.

Thank you in advance for any help.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
The author has attached one file to this post:
wiki_play_widget.jpg 7.4 kBytes
You have no permission to open this file.
topic: CQ CQ from Somewhere in the U.S.  in the forum: Community User Introductions
Avatar
justjed #12
Member since Jan 2017 · 12 posts · Location: DM79MO
Group memberships: Members
Show profile · Link to this post
Subject: CQ CQ from Somewhere in the U.S.
Howdy folks.

I'm a late middle-age former IT guy who inherited responsibility for a couple websites for a couple of amateur radio clubs. I'm converting one of them to DokuWiki - nearly finished and looking forward to abandoning GoDaddy's awful "Website Builder" interface.

I use DokuWiki at home for a couple things, one being a sort of note-taking, recording, personal site, and the other was supposed to be a private Wiki for myself and some friends to share information, but they all sort-of dropped off the project, but I keep it around.

I have a lot of IT experience, mostly development - Fortran, C, Macro-11, Perl, PHP, Oracle, sysadmin, DBA, network admin (mostly DECnet). I used to write HTML in a text editor. :) Don't care much for Javascript and complicated CMS systems.

I've already gotten one alert from GoDaddy for exceeding resource allocation, so I won't post a URL here. Maybe later, when I get a better handle on long-term performance.
Any sufficiently advanced technology is indistinguishable from a yo-yo -- Enoch Root
Close Smaller – Larger + Reply to this post:
Special characters:
Special queries
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2019-05-25, 05:45:37 (UTC +02:00)