Am trying to install macports on a newly installed mountain lion, I installed first the xCode and then installed the xCode command line tools. After that, I ran the xCode and agreed for the terms and condition, then installed the macports dmg package.
Once I did, I ran the self update command and it worked but then any self install or self upgrade won't work.
Mo-Mughrabis-MacBook-Pro:~ mo$ sudo port -v selfupdate
---> Updating MacPorts base sources using rsync
receiving file list ... done
sent 36 bytes received 69 bytes 30.00 bytes/sec
total size is 3543040 speedup is 33743.24
receiving file list ... done
sent 36 bytes received 76 bytes 32.00 bytes/sec
total size is 512 speedup is 4.57
MacPorts base version 2.1.2 installed,
MacPorts base version 2.1.2 downloaded.
---> Updating the ports tree
Synchronizing local ports tree from rsync://rsync.macports.org/release/tarballs/ports.tar
receiving file list ... done
sent 36 bytes received 70 bytes 30.29 bytes/sec
total size is 53821440 speedup is 507749.43
receiving file list ... done
sent 36 bytes received 77 bytes 32.29 bytes/sec
total size is 512 speedup is 4.53
Creating port index in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports
Total number of ports parsed: 0
Ports successfully parsed: 0
Ports failed: 0
Up-to-date ports skipped: 15604
---> MacPorts base is already the latest version
The ports tree has been updated. To upgrade your installed ports, you should run
port upgrade outdated
Mo-Mughrabis-MacBook-Pro:~ mo$ sudo port upgrade outdated
Error: No ports matched the given expression
When i tried to run sudo port install I got the following
Mo-Mughrabis-MacBook-Pro:~ mo$ sudo port install
Can't map the URL 'file://.' to a port description file ("Could not find Portfile in /Users/mo").
Please verify that the directory and portfile syntax are correct.
To use the current port, you must be in a port's directory.
Any one can help me out on what i might have done wrong here?
Thanks,
Since you just barely installed MacPorts, none of the actual ports (that you most likely had on another computer) have been installed yet.
If you run port installed, you'll notice that it returns empty.
So congratulations; 0 out of 0 ports are outdated ;-)
If you want all the same ports that you had on your other Mac(s), fire up Terminal and run port installed on those machines. That should give you a list of everything, and you can either export that list, or pick-and-choose the ones you want on your new Mountain Lion installation.
And then it will be as simple as
port install [which program]
for each of those ports that you want.
I've got the same message following this command port clean --all, because MacPorts simply found nothing to do (clean).
Related
As stated in title, I have LAMP configuration with Apache2.4.29, the problem is when I open a new port other than 80(in this case, port 12743), it could not be accessed through edge browser as port 80 does.
I added a line here under /etc/apache2/ports.conf:
appended a paragraph under /etc/apache2/sites-enabled/000-default.conf
after that I used the following command to restart Apache2:
all these shows no warning nor error messages.
The Ubuntu currently has ufw inactive, and used iptables and fail2ban instead:
however, attempts to access the website via new port failed returning the following page:
I wonder what might be the problem.
Problem solved, what I needed was just a sudo reboot.
It turned out that adding ports shall require not only an Apache2 restart but also a server reboot.
I am having some difficulty installing Snapper(http://snapper.io/) on Ubuntu Server 16.04.
When I follow instructions from Snapper for Ubuntu 16.04, I am getting the below error:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
libsnapper
0 upgraded, 1 newly installed, 0 to remove and 41 not upgraded.
Need to get 197 kB of archives.
After this operation, 674 kB of additional disk space will be used.
Err:1
(download.opensuse.org/repositories/filesystems:/snapper/xUbuntu_16.04 libsnapper 0.5.1 Protocol "http" not supported or disabled in libcurl
E: Failed to fetch)
(download.opensuse.org/repositories/filesystems:/snapper/xUbuntu_16.04/./amd64/libsnapper_0.5.1_amd64.deb Protocol "http" not supported or disabled in libcurl)
This seems to work fine for Ubuntu 16.04 Desktop. Can I make it work for server???
I just changed the https to http in the /etc/apt/sources.list.d/snapper.list and now it works
This is a work around as opensuse org does not support https i guess.
https://github.com/openSUSE/snapper/issues/357
All of the questions about this error show people running check_nrpe -H [some_remote_ip], in contrast to an error-free run on localhost.
I, however, can't even get this to run on localhost:
$> ./check_nrpe -H localhost
CHECK_NRPE: Error - Could not complete SSL handshake.
The service does appear to be up and running:
$> sudo netstat -apn | grep :5666
tcp 0 0 0.0.0.0:5666 0.0.0.0:* LISTEN 5847/nrpe
tcp6 0 0 :::5666 :::* LISTEN 10216/nrpe
And the daemon returns no errors
$> sudo service nagios-nrpe-server status
* nagios-nrpe is running
My nrpe.cfg file has allowed_hosts set correctly:
allowed_hosts=127.0.0.1,10.0.1.2,0.0.0.0
Contents of /var/log/syslog with debugging turned on:
Nov 1 22:54:44 <MYHOST> nrpe[11156]: Connection from ::1 port 6601
Nov 1 22:54:44 <MYHOST> nrpe[11156]: Host ::1 is not allowed to talk to us!
Nov 1 22:54:44 <MYHOST> nrpe[11156]: Connection from ::1 closed.
Does anyone have any idea what's going on, this seems almost nonsensical. Thanks!
Note that my example may be different than yours.
First change to the folder having your nrpe command and run:
./nrpe --version
The output from that command will look something like this:
NRPE - Nagios Remote Plugin Executor
Copyright (c) 1999-2008 Ethan Galstad (nagios#nagios.org)
Version: nrpe-3.0
Last Modified: 07-12-2016
License: GPL v2 with exemptions (-l for more info)
SSL/TLS Available, OpenSSL 0.9.6 or higher required
Notice that the last line tells you that SSL is indeed supported by this build of NRPE. If it is not there, then you'll have to install a version that was compiled with SSL support (which may mean compiling one of for yourself, depending on where you got it). The docs for the source code are pretty clear on how this is done.
If you DO have the SSL line above, look at the required version on the line and check your system to be sure that at least that version has been installed. I used this command:
rpm -qa | grep openssl
And received output looking like this:
libopenssl1_0_0-32bit-1.0.1k-2.39.1.x86_64
openssl-1.0.1k-2.39.1.x86_64
Both openssl and libopenssl are required for NRPEs SSL support to function correctly. I strongly recommend that if these are not installed, to use your systems package installer (aptget, yum, zypper, ...) to fetch and install them. If these are already installed, but you still have errors, then you will likely have a configuration issue in:
/etc/ssl/openssl.cnf
Fixing that is well outside of the scope/space available here. I recommend to upgrade both of these via a working, on-line package - these packages always include a default configuration which should work fine with NRPE - assuming the version is equal to or higher than required.
I think that check_nrpe is trying to use IPv6.
The IPv6 localhost ip is ::1, so adding this to your allowed_hosts= line in _nrpe.cfg_ and restarting nrpe will tick this box for you.
Alternatively as another responder replied you can just add -4 to your check_nrpe command to force it to stick to IPv4.
I was having the same issue and it's only when I saw the ::1 in the question it dawned on me what was happening.
I am not sure if it is still relevant, but I had the same issue and discovered someone had changed the /etc/hosts.allow file, blocking the access. Somehow this results in the following errors:
Client: Connection refused by TCP wrapper
Server: Error: (nerrs = 0)(!log_opts) Could not complete SSL handshake with <Client IP> : rc=-1 SSL-error=5
Changing the /etc/hosts.allow file solved the issue.
Browsing the hints when I write this message it seems this is a tough question with all kind of patches, but no clear answer ... Anyway, I try my chance, here it is.
I'm using Eclipse Helios PDT on Ubuntu 10.04, with XDebug and the corresponding section in php.ini as following:
xdebug support enabled
Version 2.0.5
Supported protocols Revision
DBGp - Common DeBuGger Protocol $Revision: 1.125.2.6 $
GDB - GNU Debugger protocol $Revision: 1.87 $
PHP3 - PHP 3 Debugger protocol $Revision: 1.22 $
Directive Local Value Master Value
xdebug.auto_trace Off Off
xdebug.collect_includes On On
xdebug.collect_params 0 0
xdebug.collect_return Off Off
xdebug.collect_vars Off Off
xdebug.default_enable On On
xdebug.dump.COOKIE no value no value
xdebug.dump.ENV no value no value
xdebug.dump.FILES no value no value
xdebug.dump.GET no value no value
xdebug.dump.POST no value no value
xdebug.dump.REQUEST no value no value
xdebug.dump.SERVER no value no value
xdebug.dump.SESSION no value no value
xdebug.dump_globals On On
xdebug.dump_once On On
xdebug.dump_undefined Off Off
xdebug.extended_info On On
xdebug.idekey no value no value
xdebug.manual_url http://www.php.net http://www.php.net
xdebug.max_nesting_level 100 100
xdebug.profiler_aggregate Off Off
xdebug.profiler_append Off Off
xdebug.profiler_enable Off Off
xdebug.profiler_enable_trigger Off Off
xdebug.profiler_output_dir /tmp /tmp
xdebug.profiler_output_name cachegrind.out.%p cachegrind.out.%p
xdebug.remote_autostart Off Off
xdebug.remote_enable Off Off
xdebug.remote_handler dbgp dbgp
xdebug.remote_host localhost localhost
xdebug.remote_log no value no value
xdebug.remote_mode req req
xdebug.remote_port 9000 9000
xdebug.show_exception_trace Off Off
xdebug.show_local_vars Off Off
xdebug.show_mem_delta Off Off
xdebug.trace_format 0 0
xdebug.trace_options 0 0
xdebug.trace_output_dir /tmp /tmp
xdebug.trace_output_name trace.%c trace.%c
xdebug.var_display_max_children 128 128
xdebug.var_display_max_data 512 512
xdebug.var_display_max_depth 3 3
I've been using Eclipse for PHP development without any problem so far, but never used debugging. When I launch the project in debugging mode I get the application correctly launched in the browser in the background, my by Debug/PHPDebug perspective is empty, while in the Eclipse console I have the message in the Title of this posting.
Thanks for any help
If Eclipse is stopping at 57%, then the remote debugging process couldn't be started. This might the case, when...
You didn't enable remote debugging in the file /PHP/php.ini:
xdebug.remote_enable=on
the remote host ip address (client which starts debug session (your IDE)) isn't correct:
xdebug.remote_host=IP_ADDRESS
Instead of defining the remote hosts ip address you can enable "multihost" remote debugging using:
xdebug.remote_connect_back=1
Also checkout the xdebug documentation for all settings: http://xdebug.org/docs/all_settings
I was struggling to setup xdebug and eclipse for an age.
I use ubuntu 12.04 on a 32bit system.
To setup the latest version of eclipse (juno) and the lamp tech stack i can strongly recommend this tutorial. There's a very good guide for setting up virtual hosts, too - script included.
Instead of following their section on installing xdebug, rather use xdebug's custom installation instructions referred to by #hakre in a related post.
Once xdebug shows up in the phpinfo output, you can continue by setting up eclipse for xdebug as described in the tutorial mentioned before.
If it still doesn't work make sure you
have read the answer above
xdebug's port is free and matches eclipse's debug configuration -> server tab -> server section -> configure button (9030 by default!)
and try
cutting the quotes from the zend_extension property within your php.ini file
putting all your xdebug-settings in your php.ini file - i dont have a xdebug.ini file in use.
repeating the filename within eclipse debug-configuration -> server tab -> url section -> last input field as shown below.
I found the problem for me was related to a specific browser, Firefox, and possibly due to an update of java to 7_21.
See my solution here
Eclipse, XAMPP, xDebug - waiting for XDebug session - stays in 57%
I had the same issue and searched for ages trying to fix it! I verified everything with my remote host, my port listening, and my Eclipse settings. I finally found the problem was that I needed to specify the IDE for XDebug in my php.ini, like:
xdebug.idekey=ECLIPSE_DBGP
Try edit the php.ini at: wamp\bin\apache\Apache2.4.4\bin
xdebug.remote_enable = on
xdebug.remote_host="localhost"
xdebug.remote_connect_back=1
I had the ame issue - editing the php folder php.ini when using WAMP seems to be not enough.
I had the exact same problem after I made a custom php build which accidentally replaced the original apache php module:
/usr/lib64/httpd/modules/libphp5.so
/usr/lib64/httpd/modules/libphp5-zts.so
To me, the fix is:
sudo rpm -e --nodeps php
sudo dnf install php
sudo service httpd restart
I found that for me it was the missing xdebug.idekey=ECLIPSE_DBGP in c:>\php\php.ini
Anyway this is my current php.ini configuration for xdebug, note I've not set the remote address:
[xdebug]
zend_extension=C:\php\ext\php_xdebug-2.9.6-7.3-vc15-nts-x86_64.dll
xdebug.remote_enable=1
xdebug.remote_connect_back=1
xdebug.remote_handler=dbgp
;xdebug.remote_host=127.0.0.10
xdebug.remote_autostart=1
xdebug.remote_port=9000
xdebug.show_local_vars=1
xdebug.expose_remotely=always
xdebug.default_enable=1
xdebug.idekey=ECLIPSE_DBGP
My environment:
W10 x64, php7.3.18 non-threadsafe, IIS as webserver
Something that I've noticed recently on two different machines is that Apache2 installed via MacPorts seems to have stopped launching when I boot up. The honest truth is that I can't swear it did so before, but it's something I think I'd notice because installing the LaunchDaemon is part of my install process. In fact, if I try to reload the LaunchDaemon, it fails:
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist
org.macports.apache2: Already loaded
Unless I start Apache manually (using sudo apachectl restart), grep'ing for either "apache2" or "httpd" in my process list only produces this:
$ sudo ps -ef | egrep "apache2|httpd"
0 52 1 0 0:00.06 ?? 0:00.08 /opt/local/bin/daemondo --label=apache2 --start-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart ; --pid=none
1410639199 6960 6792 0 0:00.00 ttys001 0:00.00 egrep apache2|httpd
Looks like the daemon itself is in place, but no executable. As far as I know/can tell, the relevant executables (httpd and apachectl) are executable by everyone.
Has anyone else noticed this? Any ideas?
UPDATE
As requested below, I did execute launchctl list. The list is long and I'm not sure how to snip it, but suffice to say that no org.macports.* items are listed. That in itself is interesting because my MySQL daemon is loaded the same way. It works, but also doesn't appear in the list. Let me know if the entire output is really needed.
UPDATE
I assumed that I had executed launchctl list under sudo, but prompted by mipadi's comment below, I tried again ensuring that I did so and I assumed incorrectly. When executed under sudo, the MacPorts items appear:
51 - org.macports.mysql5
52 - org.macports.apache2
I'm not sure whether that will help, but it's a little more info nonetheless.
UPDATE
I've asked a different, but related, question at LaunchDaemons and Environment Variables. I'll update both questions as I learn more.
UPDATE
Today, based on mailing list input, I tried using a wildcard home directory. Academically, it's a little more inclusive than I'd like, but the practical reality is that I'm the only one using this computer; certainly the only one who'd have Apache config files laying around.
Include "/Users/*/Dropbox/Application Support/apache/conf.d.osx/*.conf"
Include "/Users/*/Library/Application Support/MacPorts/apache/conf.d/*.conf"
Unfortunately...
httpd: Syntax error on line 512 of /opt/local/apache2/conf/httpd.conf: Wildcard patterns not allowed in Include /Users/*/Dropbox/Application Support/apache/conf.d.osx/*.conf
I found my answer to this problem here:
https://trac.macports.org/ticket/36101
"I apparently fixed this when changing my local dnsmasq config. In /etc/hosts I added my servername (gala) to the loopback entry:
127.0.0.1 localhost gala
and then I changed ServerName in /opt/local/apache2/conf/httpd.conf to match:
ServerName gala
Apache now starts at boot for me."
Since I now know why Apache has stopped loading on startup, I'm going to articulate that answer and mark this question as answered. The reason Apache has stopped launching on boot is that I'm trying to share an httpd.conf file across systems. The config file needs to Include files from directories that exist within my home directory. Since the home directory is different on each machine, I was trying to reference the ${HOME} environment variable.
This works fine when manually starting after the machine is booted, but fails on startup because the environment variable isn't yet set. As mentioned above, see this question for more information.
Rob:
Had the same problem: "sudo launchctl load -w ..." started Apache2 while I was logged in, but did not work during startup (the "-w" should have taken care of that). Also, as you noticed, the daemon seems to be registered with launchctl. It will show up with "sudo launchctl list" and another "sudo launchctl load ..." will result in the error message.
I played with "sudo port load apache2" and "sudo port unload apache2", but could not get httpd running on reboot.
In the end, I got rid of the MacPorts startup item: "sudo port unload apache2", checked with "sudo launchctl list" that org.macports.apache2 is no longer registered for startup.
Afterwards, I followed the steps on http://diymacserver.com > Docs > Tiger > Starting Apache. I only had to adapt the path from /usr/local/... to /opt/local/...
Now the MacPorts Apache2 is starting fine with every reboot.
Good luck, Klaus
I found that my MacPorts apache2 was not starting on boot because of an “error” in my httpd.conf.
I was using
Listen 127.0.0.1:80
Listen 192.168.2.1:80
Listen 123.123.123.123:80 # Example IP, not the one I was really using
And in Console.app I was seeing
4/8/12 4:59:06.208 PM org.macports.apache2: (49)Can't assign requested address: make_sock: could not bind to address 192.168.2.1:80
4/8/12 4:59:06.208 PM org.macports.apache2: no listening sockets available, shutting down
4/8/12 4:59:06.208 PM org.macports.apache2: Unable to open logs
I tried adjusting permissions on all the log folders (despite the fact that logs were being written just fine when I manually started apache2) and that didn't help.
Even though the Apache Documentation for Listen clearly states
Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.
I decided to try switching back to just using
Listen 80
And after doing so apache2 is starting on boot with no errors or warnings.
If you're using Subversion with Apache, you may find that Apache is not starting because the mod_dav_svn.so file has moved to /opt/local/libexec. You'll need to adjust your Apache startup files to account for the new location of this file.
In newer versions of MacPorts you can run sudo port load apache2 to instruct MacPorts to take care of the launchctl setup and automatically start the process. To stop the process run port unload.
After loading check /opt/local/apache2/logs/error_log for errors, including configuration issues.
In addition to my previous answer I have also found that sometimes Apache fails to start because something else with the system is not yet ready.
On one OS X Server machine I also use the DNS to create a “internal only” DNS name for the machine and that name is used in my Apache configuration. Sometimes when Apache tries to start the DNS server is not yet ready and Apache fails to load because the hostname isn’t valid.
I have also seen this on other non-Server systems without local DNS as well where something else required by Apache must not be ready yet.
One thing that has worked is to edit the apache2.wrapper located at /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper that MacPorts’ daemondo uses to start up Apache.
Edit the Start() function to add a sleep command to wait a bit before launching Apache.
Original (Lines 14-17 on my machine)
Start()
{
[ -x /opt/local/apache2/bin/apachectl ] && /opt/local/apache2/bin/apachectl start > /dev/null
}
With wait time added
Start()
{
[ -x /opt/local/apache2/bin/apachectl ] && sleep 10 && /opt/local/apache2/bin/apachectl start > /dev/null
}