First question ever here...
I have OwnCloud running on a Raspberry Pi 2.
I can access it locally with no issues.
Ports 22, 80, and 443 have been forwarded.
I can SSH into the machine from outside local.
But, if I try to access http/https from outside of my local network, I get:
"You are accessing the server from an untrusted domain.
Please contact your administrator. If you are an administrator of this instance, configure the "trusted_domain" setting in config/config.php. An example configuration is provided in config/config.sample.php.
Depending on your configuration, as an administrator you might also be able to use the button below to trust this domain."
I have the following in my config.php:
'trusted_domains' =>
array (
0 => '192.168.10.10'
),
Commenting it out fixes the problem, but that's not the best solution.
I've spent some time looking around forums looking for answers and feel I have everything set up correctly. I'm just missing something...
FYI the router is an ASUS RT-N66W
When you're accessing it remotely, you're not using 192.168.10.10, you'd be using a public IP address or external hostname. It's this which you need to add to your trusted domains. Let's say you're accessing it using an external IP of 12.34.56.78:
'trusted_domains' =>
array (
0 => '192.168.10.10',
1 => '12.34.56.78'
),
And if you also decide to use an external hostname:
'trusted_domains' =>
array (
0 => '192.168.10.10',
1 => '12.34.56.78',
2 => 'owncloud.mydomain.com'
),
You can add as many of those as is necessary for your setup.
Additional to Nicks remarks there is also the example config file (config.sample.php) that helps you understand how to manipulate the real config file (config.php).
In case somebody wonders where to find the configuration files:
you will find them here
/var/www/owncloud/config/config.php
/var/www/owncloud/config/config.sample.php
Related
I've recenlty run into a very strange issue where PHP's dns_get_record() function is returning old results.
On the same server, if I use host or dig from the command line, I get the correct results.
I've even used dig to query each individual nameserver and all return the correct current value for the record.
The servers are running Ubuntu 16.04 and are up-to-date.
This is happening on 2 of my servers at Linode, not all of them, so it doesn't sounds like a Linode network thing.
After a few hours, the issue resolved itself without reboot.
There was never a hosts entry for the domain, and to the best of my knowledge, vanilla Ubuntu does not have any built-in DNS cache.
Can anyone explain how PHP's dns_get_record works and why it would provide different results from terminal host or dig?
I don't have such extensive knowledge but you may try a library.
Eg. bluelibraries/dns
This library allow you to use 4 types of DNS handlers.
PHP default dns_get_record()
DIG (if your system may run this command)
UDP - raw server calls (good only responses are smaller than 512 Bytes
TCP - raw server calls (personally, I would recommend this one).
You can try different calls with different handlers in the same time then you can compare the result and to pick the one which works for you.
Eg:
Retrieve records using dns_get_record, DIG, UDP and TCP
// PHP -> dns_get_record()
$records = DNS::getRecords('bluelibraries.com', RecordTypes::TXT, DnsHandlerTypes::DNS_GET_RECORD);
// DIG command
$records = DNS::getRecords('bluelibraries.com', RecordTypes::TXT, DnsHandlerTypes::DIG);
// UDP
$records = DNS::getRecords('bluelibraries.com', RecordTypes::TXT, DnsHandlerTypes::UDP);
//TCP
$records = DNS::getRecords('bluelibraries.com', RecordTypes::TXT);
One response example
Array
(
[0] => BlueLibraries\Dns\Records\Types\Txt\DomainVerification Object
(
[data:protected] => Array
(
[host] => bluelibraries.com
[class] => IN
[ttl] => 0
[type] => TXT
[txt] => google-site-verification=test-636b-4a56-b349-test
)
)
)
I'm very new to drush. We have a git repo of a drupal site that I would like to push to the remote server using drush. I can easily scp the drupal files or setup a cron on the remote that runs git pull but I still would like to learn how to push code and sync a remote drupal site with my local drupal.
Currently, I have drupal running locally and I use git to update the repo. The ssh is already configured and I can ssh to the remote drupal server using keys. I have also created .drush/aliases.drushrc.php file and I tested it by running drush #dev status. It worked well
<?php
$aliases['dev'] = array(
'root' => '/var/www/html',
'uri' => 'dev.example.com',
'remote-host' => '192.168.1.50'
);
?>
Now, I would like my local drupal site to be synchronized with our server on 192.168.1.50 server. The local drupal files are on my /home/ubuntu/drupal_site.
I have few questions:
What is the drush command/parameters to update remote drupal server?
What will be the drush command/parameters if remote server doesn't have drupal files yet?
Backup before synchronizing with drush ard or drush #dev ard or with the suited alias. You can set the backup path in the alias settings.
I think you named your remote server dev. That is why I keep this in the following and use the alias local for the local drupal site.
Add the alias for your local drupal site. Then you can use the following command to synchronize the files:
drush rsync #local #dev
There #local is the source and #dev the target. More details on how to use the command rsync can be displayed with:
drush help rsync
You also need to synchronize the database to get the remote site running. For this add the database account data to the alias data for #local and #dev. It will look something like this:
'databases' => array(
'default' => array(
'default' => array(
'driver' => 'mysql',
'username' => 'USERNAME',
'password' => 'PASSWORD',
'port' => '',
'host' => 'localhost',
'database' => 'DATABASE',
)
)
)
Replace the space holders with your data. Then databases can be synchronized with:
drush sql-sync #local #dev
There #local is the source and #dev the target.
Initially the synchronization will happen in one direction. After this it is good practice to synchronize files from development or test site to the productive site. The database is synchronized the other way around from productive site to development or test site.
Drush and Git workflows differ in a way, as Drush can pull packages separately – you could probably use Git to push to the server. Be sure to check the /files directory, which is usually in the .gitignore file – a possible approach would be to mirror the files directory directly from the live site.
A common approach to update and check 2 or several sites at the same time (being local and remote) would be to use Drush aliases for your sites on a script on your machine.
Articles like this one are a good starting point.
Well. I read some topics in SO but I not found a very specific answer.
I need to check with PHP if a PHP code is running in local or remote host. Currently I check with $_SERVER['SERVER_NAME'] but it is inconsistent. In this case, if I run PHP with listed IPs like 127.0.0.1 or localhost it'll consider local, otherwise remote. If I share my IP with a friend, my code still local, but it consider remote because the shared IP isn't listed.
Well, I think that check IP for localhost is not a good idea (except if you know a good method). I tried methods like gethostbyaddr() and gethostbyname() but don't work correctly too.
I don't have a PHP code to show, but my code is basically that:
// true = localhost
return $_SERVER['SERVER_NAME'] === '127.0.0.1';
The fundamental question is: what can determine that PHP is running local? What is "local" for PHP? I think that it can solve the problem.
Obs.: I don't have access to CMD/Shell with PHP.
You could do what most PHP frameworks do and set a flag during your app's bootstrap phase that defines which environment the code is running in. In it's simplest form:
// the setting when run on a dev machine
define('ENV', 'local');
Then it's a simple case of:
if ( ENV == 'local' )
{
// do stuff
}
This is how I do it, which I find more reliable than trying to detect for 127.0.0.1:
if( strpos(gethostname(), '.local') !== false ) { }
Basically, the hostname's on my workstations all have .local appended to it. You can change this to match your workstation's hostname entirely.
Check $_SERVER['REMOTE_ADDR']=='127.0.0.1'. This will only be true if running locally. Be aware that this means local to the server as well. So if you have any scripts running on the server which make requests to your PHP pages, they will satisfy this condition too.
If someone is visiting your site via the web, the IP address you see will never be 127.0.0.1 (or ::1 for IPV6), regardless of the usage of a proxy. (Unless of course you're running the proxy yourself on the same server ;)
As far as I know, only you will be able to know what addresses are local or not. Your network could be set up with IP addresses that don't look local at all. PHP cannot as far as I know determine this by itself.
I've been googling this one a lot but I still could not make it work. I have a MAMP web server installed on my mac and I've created some a web service. It work fine when I call it from the browser on my mac when I use localhost:8888/myfile.php and also when I use 192.168.0.108/~martin/myfile.php.
The problem is when I try to call the 192.168.0.108/~martin/myfile.php from my iPhone to do some testing, the requests time out. It is really weird because this was working 2 days ago. I'm not sure what has changed. I'm not very familiar with httpd.conf and htaccess files, but I did not change things there manually.
Any help would be appreciated!
Have you tried going to http://192.168.0.108:8888/myfile.php on your iPhone? If MAMP is running on 8888 you will need to specify the port to access it there.
Be sure to check your computer's IP too. It's possible that it changed over the last few days depending on your router's setup.
Also, make sure the iPhone is indeed on the same network as your local machine. Depending on your network setup, a subnet might not work either. I've driven myself crazy trying to connect to a box that was actually connected on a separate subnet.
Don't know if this helps anyone but I got this working by simply removing the ip host address and changing this to the wildcard. It started working straight away after this
I had success opening my local-folder by opening the host by the computer’s local hostname.
Solution 1: computer’s local hostname
Find your computer’s local hostname: macOS->System Preferences->Sharing->File Sharing
https://support.apple.com/et-ee/guide/mac-help/mchlp1177/mac
Near the "Computer's Name" you can find the info:
"Computers on your local network can access your computer at:
"mymac.local"
Opening the compuerts name "your_computers_name.local" in iOS-Safari worked for me:
http://[your_computers_name.local]
For example:
http://mymac.local
Solution 2: computer’s network address
Try it with the computer’s network address. If you select and activate file-sharing in the preferences you can find the network address. Looks like: "smb://name.example.com". Replace "smb" with "http".
Open the network address in iOS-Safari (connected via USB-Cable or Wifi):
http://[insert_your_computer_network_address]
For example you can access your files like:
http://name.example.com/myfile.php
This worked for me, too.
As an alternativ way to find the address write "hostname" in terminal of the host-computer:
$ hostname
This will return the host's name / network address.
Doesn't work?
Maybe you have to allow file sharing first? I don't know ...
macOS->System Preferences->Sharing->File Sharing: On
Well, I'm wondering if theres a way to run both rails and PHP on Lighty, on Ubuntu. I want to run both my PHP projects and Rails projects on the one server/domain.
I have little experience with Linux really, so forgive my naivety.
If theres a way of doing this please let me know :)
It's really quite simple to run them both. I do it all the time (ROR to run Redmine, and PHP for the rest).
You have 2 real options for ROR. Either serve it from FastCGI (what I do), or run it with a standalone server (like Mongrel, etc) and proxy to it. Both have advantages. FastCGI has the advantage that it's self-contained (no secondary server to run). The standalone has the advantage that it's easier to configure.
If you have specific questions, I can guide, but there are guides on the internet on how to do this.
My lighttpd.conf:
$HTTP["host"] =~ "my.ror.site" {
server.error-handler-404="/dispatch.fcgi"
fastcgi.server = (".fcgi" => ("ror_1" => (
"min-procs"=>8,
"max-procs" => 8,
"socket" => "/tmp/myrorlock.fastcgi",
"bin-path"=> "/path/to/ror/site/public/dispatch.fcgi",
"kill-signal" => 9,
"bin-environment" => ( "RAILS_ENV" => "production" )
)))
}
fastcgi.server = ( ".php" =>
(
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi -c /etc/php.ini",
"min-procs" => 1,
"disable-time" => 1,
"max-procs" => 1,
"idle-timeout" => 20,
"broken-scriptfilename" => "enable",
"bin-copy-environment"=> (
"PATH", "SHELL", "USER"
),
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "40",
"PHP_FCGI_MAX_REQUEST" => "50000"
)
)
)
)
And that's it. Note the kill-signal option. that's important, otherwise you'll wind up with zombie processes everywhere every time you restart the server...
Check out fastcgi.conf in the conf.d subdirectory of Lighty's configuration directory (not sure where it's located on Ubuntu, but a quick search suggests /etc/lighttpd). There are commented-out examples for both PHP and Rails; by combining the two, you should be able to get the set-up you're looking for (though I'd suggest getting one working first and then setting up the other).
FastCGI is the method by which Lighty can communicate with runtimes like Ruby or PHP. Lighty can also use SCGI, though I've never use it myself and am not sure how well it works (last I heard it was still experimental-ish).
You may also find the Optimizing FastCGI page on Lighty's documentation wiki helpful, though it's fairly PHP/MySQL-specific.
I don't use Lighty. Rails is best served with Passenger and Apache, considering the power of Passenger add-on to Apache. I served Wordpress (PHP) in the same domain as my Rails app by pointing its path to somewhere else. Here's an article to follow. HTH.