I have just installed Mura CMS.
I have Lucee installed and setup. However, it seems I am not completely "there" yet.
I can get to the Mura Page, but something seems missing:
When I go to: http://localhost:8888/cms I get a: 404 requested page could not be found and then right below this, we see:
Sample Modal Window This is just a sample…
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent
suscipit iaculis libero sed tristique. Quisque mollis dolor non tellus
placerat vitae sodales lectus porta. Curabitur ut suscipit tellus.
Maecenas rhoncus, ante etc.
Environment is:
LINUX Mint (Rebecca 17.1) - It is my personal laptop
MySQL 5.5 (from Software Manager)
MySQL WorkBench (Created Mura DB and User)
Lucee Express 4.5.1.000 (and also includes Tomcat 8) - Created the DSN in server
I am wanting to work with Mura as I am on a migration project to Mura from another CMS.
I did follow the information it seems to be the most relevant to start with Lucee: Installing Tomcat and Lucee on OS X using the lucee.war file
It seems I am missing something pretty simple at this point as is shown by this screen cap.
It does not look anything like the admin panel from their site:
I wound up getting some additional help. These steps were what was used under Linux Mint.
Setup MySQL and MySQL Workbench or phpMyAdmin would work as well
Created a new database and database user as directed in the Installation.txt from Mura
Insure that you have Lucee configured (creating the DSN) and that you are able to login
Moved Lucee Express to /home/your_home/lucee and made sure that Lucee works
Deleted all of the content from /home/your_home/lucee/webapps/ROOT
Extracted out the contents of the Mura.zip into /home/your_home/lucee/webapps/ROOT
Changed /home/your_home/lucee/webapps/ROOT/config/settings.ini.cfm at line 27 to be context= (blank)
Ran startup.sh at /home/your_home/lucee/bin
Navigated to http://localhost:8888 and the site comes up fine and was able to login.
Thanks!
Addressing the CSS issue
When a non standard ports, the base tag needs to be set
<base href="http://localhost:8888/mura-6.2.6271/">
OR perhaps
<base href="http://localhost:8888/mura-6.2.6271/admin">
This is set in a layouts file
Try editing your /config/settings.ini.cfm file by setting the context attribute to the value or the nested path to the Mura root. So if the Mura is access via /cms/admin the context value would be /cms
context=/cms
The reload the application by putting ?appreload in at request to the Mura root. The appreloadkey is also configurable in the settings.ini.cfm.
Related
I am making a web-app currently and I'm using WebStorm for my front and back end. My stack is as follows: Vue3(with axios), Node.js (with Express and Coors as well as mysql and mysql2), and of course, MySQL which I am using a server from AWS.
Below is my code for allowing more than one localhost to connect to the backend Node.js.
const corsOptions = {
origin:["http://localhost:3000", "http://192.168.56.1:3000", "http://10.3.14.231:3000/"]
}
The last 2 in the array are the "Network" links I get when I npm run dev -- --host. I then get this in the terminal:
> Network: http://192.168.56.1:3000/
> Network: http://10.3.14.231:3000/
> Local: http://localhost:3000/
So far, when I type any of the links in network to my phone, it doesn't work for the SQL. The Display and front end pop up just fine, but when I make an account, Firebase will work, but nothing is sent to MySQL.
If there's any questions please ask for clarification. I don't know if this will be an issue when I actually launch it, but I can't find anything else on this problem.
I used to have PhpStorm working brilliantly on my computer. No browser extensions. I could put breakpoints anywhere, go to some URL in browser, hit enter and then I would automatically be taken to breakpoint in given file. Files in project would open up automatically as I stepped through code.
Now, it is a total mess.
First here is my Xdebug info in the xdebug.ini (I don't specify anything Xdebug related in the php.ini):
zend_extension=/usr/local/php5/lib/php/extensions/no-debug-non-zts-20151012/xdebug.so
[xdebug]
xdebug.remote_enable=on
xdebug.default_enable=on
xdebug.remote_port=9000
xdebug.remote_host=localhost
If I run php -v I get
PHP 7.0.15 (cli) (built: Feb 13 2017 10:30:54) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.15, Copyright (c) 1999-2017, by Zend Technologies
with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans
iMac:xdebug-2.7.2 $
phpinfo() shows corresponding values set based on my .ini.
In PhpStorm I have PHP CLI set to 7.0, it is showing Xdebug 2.7.2.
Curious about that "Can't load xdebug" message, but php -v doesn't show same message. At first I had zend_extension defined in both php.ini and the xdebug .ini and would see that message when doing php -v but after removing from php.ini the message went away from php -v.
I have no idea if I need to do anything under Debug settings in Build, Deployment, but here is what is there by default:
Also, I have my project set to sync with a remote server but for debugging I don't want to use path mappings. That is how I had it before and PhpStorm messages about debug session ending and no path mappings found was never a problem.
Here is my Run->Config
In the past, I didn't worry about a start URL. No matter what URL I entered in browser it triggered debugging.
And here is what I have tried regarding path mappings:
I did that to see if it would fix things, but no.
My gut feeling says it is either a problem with Xdebug settings, my run->config, or the fact that I am using a virtual host and somewhere there is a localhost entry causing a problem.
So I am at a loss. If I select Listen for incoming... and go to URL, the focus does not go to PhpStorm with current breakpoint. I see in browser that things stopped and I go to PhpStorm and see that debug was triggered. But the second I hit step over or step into the debugging just ends.
Anything glaringly wrong with what I am doing?
Edit: Here is what I see in the xdebug log:
[89603] W: Creating socket for 'dev.courses.com:9000', poll success, but error: Operation now in progress (19).
[89603] E: Could not connect to client. :-(
[89603] Log closed at 2019-10-21 10:42:37
[89603]
[89603] Log opened at 2019-10-21 10:42:37
[89603] I: Connecting to configured address/port: dev.courses.com:9000.
[89603] W: Creating socket for 'dev.courses.com:9000', poll success, but error: Operation now in progress (19).
[89603] E: Could not connect to client. :-(
[89603] Log closed at 2019-10-21 10:42:37
Not sure the specifics of the error... Maybe this hints at something? The question I have is where in the config do I specify localhost vs my virtual host alias? Maybe that is what is messing things up?
You can find out what Xdebug is trying to do by using the xdebug.remote_log=/tmp/xdebug.log setting. This log will indicate which connection attempts are being made, and why they succeed or not.
Ok, so this turned out to be an xdebug issue, though not obvious at first.
Originally I didn't think to check the PHPStorm log. But the PHPStorm log showed
Argument for #NotNull parameter 'remoteFileUrl' of com/jetbrains/php/debug/xdebug/debugger/XdebugDriver.onBreak must not be null
Searching above error took me to
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360001498520-xdebug-works-only-with-first-line
Turns out my version of PHPStorm is known to not work with xdebug 2.7 so I downgraded to 2.6.1 and all is well :-)
thanks,
Brian
I managed to set up artifactory using our existing tomcat. I have set to ARTIFACTORY_HOME=/opt/artifactory, that part works well. There is, however, also the jfrog access.war file, which needs to be running as well. I didn't figure out which variable to use to specify its home, therefore it defaults to ~/.jfrog_access, which is not at all what I like.
I moved the content over to my $ARTIFACTORY_HOME/access and symlinked it, but that's not the way to go for sure. Any help appreciated.
In case someone is stumbling over this thread and struggles with the same problem:
Solution for me was to also extract the Context files (access.xml and artifactory.xml which are available in the zip file under <zip extract>/misc/tomcat) to the Tomcat configuration folder, e.g. $CATALINA_HOME/conf/Catalina/localhost/. After that the $ARTIFACTORY_HOME env will be recognized on Access startup.
A previous answer finally put me on the right track for solving this problem on Amazon Linux.
In addition to copying access.xml and artifactory.xml to ${catalina.home}/host/MY_HOSTNAME, I found that some other changes were needed.
I modified the docBase attributes in the XML context files because my server has multiple hostnames:
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/access.xml
<Context path="/access" docBase="${catalina.home}/host/repo.mydomain.org/access.war">
<Parameter name="jfrog.access.bundled" value="true" override="true"/>
<!-- enable annotations scanning of access jar files -->
<JarScanner scanClassPath="false">
<JarScanFilter defaultPluggabilityScan="false" pluggabilityScan="access*" defaultTldScan="false"/>
</JarScanner>
</Context>
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/artifactory.xml
<Context crossContext="true" path="/artifactory" docBase="${catalina.home}/host/repo.mydomain.org/artifactory.war">
</Context>
Important Note: In order to prevent the above two XML files from being deleted by Tomcat Manager during upgrades via Undeploy/Deploy WAR, make sure they are owned by root and not writable by the tomcat user:
chown root.root access.xml artifactory.xml
chmod 644 access.xml artifactory.xml
If you forget to do the above, you will likely end up missing these files, which will break the communication between the access and artifactory web applications, resulting in login failures ("Username or Password Are Incorrect"). In this case, these errors result from the lack of communication between the web applications, not a problem with the credentials themselves.
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/manager.xml
This gives me the ability to upload new versions of access.war and artifactory.war via https://repo.mydomain.org:8443/manager/html:
<Context docBase="${catalina.home}/webapps/manager" privileged="true" antiResourceLocking="false">
</Context>
Additionally, I created the following folder to serve as the artifactory.home:
sudo mkdir /usr/share/artifactory
sudo chown tomcat.tomcat /usr/share/artifactory
tomcat8.conf
Add (or modify) the following line:
JAVA_OPTS="-Dartifactory.home=/usr/share/artifactory -Djfrog.access.home=/usr/share/artifactory/access -Dartifactory.access.client.serverUrl.override=http://localhost:8080/access"
Note: The Access Client URL specified above must use localhost in order to avoid the Server HTTP parameter from being overwritten by Apache and its modules. For instance, if I use:
https://repo.mydomain.org/access/api/v1/system/ping
The Server HTTP header value in the response is:
Server: Apache/2.4.33 (Amazon) OpenSSL/1.0.2k-fips mod_jk/1.2.43
And the Access Client produces the following exception:
[ERROR] (o.j.a.c.AccessClientImpl:154) - Access client/server version mismatch. Client version: 4.1.5, Server version: 2.4.33 (Amazon) OpenSSL
Which means the Access Client is depending on the first string matching #.#.# in the server header. This seems like a really fragile part of the Access Client. They should have used X-JFrog-Access-Server or something instead of trying to control a value that is set by the web server. So, to reiterate, use http://localhost:8080/access to connect directly to the tomcat server.
Artifactory 6.2.0 depends on Apache Derby (the specific version can be found in jfrog-artifactory-oss-6.2.0.zip\artifactory-oss-6.2.0\tomcat\lib). This should be added as a shared library to Tomcat:
mkdir /usr/share/tomcat8/shared
cd /usr/share/tomcat8/shared
wget http://central.maven.org/maven2/org/apache/derby/derby/10.11.1.1/derby-10.11.1.1.jar
Add or modify the following line in catalina.properties:
shared.loader=${catalina.home}/shared/*.jar
Since we want https://repo.mydomain.org to go to the Artifactory webapp:
mkdir /usr/share/tomcat8/host/repo.mydomain.org/ROOT
echo '<html><head><meta http-equiv="refresh" content="0;URL=/artifactory"></meta></head><body></body></html>' > /usr/share/tomcat8/host/repo.mydomain.org/ROOT/index.html
And make sure the services automatically start on reboot:
sudo chkconfig httpd on
sudo chkconfig tomcat8 on
Artifactory will then be available at the url:
https://repo.mydomain.org/artifactory/webapp/
I have an instance of Tomcat 8.0.9, running on GNU/Linux 2.6.32-642.6.2.e16.x86_64, that responds with "401 Unauthorized" when I try to access the manager UI, no matter what I try.
I know Tomcat is running, because I get that page.
I know it is that specific instance of Tomcat, because if I shut it down and revisit the URL (https: //host.name:port/manager/html), I get a connection refused.
The browser doesn't even prompt me for username and password; it just goes straight to the "401 Unauthorized" page.
The server's catalina.out log even reports that it has deployed the manager webapp (paraphrased):
*.a few seconds ago* INFO [localhost-startStop-1] o.a.c.s.H.deployDirectory Deploying web application directory /path/to/webapps/manager
*milliseconds later* INFO [localhost-startStop-1] o.a.c.s.H.deployDirectory Deployment of web application directory /path/to/webapps/manager has finished in 22 ms
I started with the Apache docs (https: //host.name:port/docs/manager-howto.html), and then with several versions of this question on SO for troubleshooting, including one that seems to have the most answers.
Since I've never used the manager before, my go-to theory is that 'obvious' was exactly what I was missing; however, I tried all of the obvious stuff below:
I restarted Tomcat, multiple times in this process, verifying that a reload of the URL was indeed firing a connection refused with the server stopped, and then back to the 401 error with the server started.
I added admin-gui to the user's roles:
<role rolename="admin-gui" />
<role rolename="manager-gui" />
<user username="tomcat" password="s3cret" roles="admin-gui,manager-gui" />
The XML above is not inside a comment block - if I edit it in Gvim with syntax highlighting turned on, this is very obvious.
tomcat-users.xml is owned by tomcat, and is readable (it's mode 775, in fact). I know it's being read, because if I add nonsense elements to it, catalina.out reports this on startup.
I also added the other role to tomcat-users.xml, just in case (manager-jmx, admin-script, etc.). (I'm still not sure what's supposed to happen if you left those out, misspelled them, etc. I imagine the manager webapp wouldn't recognize rolenames outside its specific set, but naturally I can't confirm this yet.)
The following element exists in server.xml, inside an Engine element:
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" />
</Realm>
In case it's relevant, there's also this, earlier in server.xml:
<GlobalNamingResources>
<Resource auth="Container" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" name="UserDatabase" pathname="conf/tomcat-users.xml" type="org.apache.catalina.UserDatabase" />
</GlobalNamingResources>
In the Tomcat startup script, CATALINA_HOME points to the exact install path of Tomcat. There is no TOMCAT_HOME or JAVA_HOME, but JRE_HOME points to a symbolic link that points to an actual Java install (I followed that link and confirmed).
In the manager webapp, META-INF/context.xml, the Valve element is commented out.
Is there even a report of why I'm unauthorized, that gives me more information? I've tried scouring the manager webapp directory in the hopes there was yet another log there. (There isn't.)
I've seen this asked before, with no good answers, how do you configure jetty to allow access from an external server? I've just started messing around with solr and jetty and am using the example jetty instance that comes with solr.
solr is running fine on localhost, and I can query it from sites on the same server. However, I can't access the solr instance from another server. I've googled and read quite a bit in the last few days, but have not been able to discover what's keeping jetty from allowing non localhost access to solr.
Based on what I've read, I have tried added the following line to example/etc/jetty.xml
<Set name="Host">0.0.0.0</Set>
and still got no external response
then tried
<Set name="Host">x.x.x.x</Set>
where x.x.x.x is my server's IP address
and
<Set name="Host">host.domain.com</Set>
where host.domain.com is my server's FQDN
These both resulted in the error
java.net.BindException: Cannot assign requested address
when I started.
The start command I'm using is
sudo java -jar start.jar etc/jetty.xml
You can point me to where I can read on this or spoon feed me, I don't care. I'd just like to get past this hurdle so I can keep learning about setting up and using solr.
you should add a file called clientaccesspolicy.xml for cross domain access to your static web files directory:
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-methods="*" http-request-headers="*">
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
you should set you static directory to jetty using this code:
ResourceHandler staticHandler = new ResourceHandler();
staticHandler.setResourceBase("static/dir");
handlers.addHandler(staticHandler);