PeterKjeldsen

Q: Access Log reports all visitors as from 127.0.0.1

Even Googlebot and Bingbot has the IP address 127.0.0.1 in Apache Access Log


Does anyone know how to fix this problem, which occurs in both OS X Server 5.0.3 and 5.0.4 after updating from 5.0.2? 

Mac mini, OS X Server, 5.0.4 (Build 15S2259)

Posted on Sep 25, 2015 10:54 AM

Close

Q: Access Log reports all visitors as from 127.0.0.1

  • All replies
  • Helpful answers

Previous Page 2
  • by PeterKjeldsen,

    PeterKjeldsen PeterKjeldsen Oct 24, 2015 3:23 AM in response to scottl31
    Level 1 (0 points)
    Oct 24, 2015 3:23 AM in response to scottl31

    We don't use the wikis since the updates from snow leopard to lion showed that Apple could not be trusted anymore. Our setup is only using very few services in the server. The server app has become a laughing stock, one version had webmail the next did not, another version had GD library the next had it removed and all custom scripts had to be redone etc.

     

    The IP problem in the log files is really minor to the nagging suspicion if everything else is ok. If you're running mission critical/life and death stuff I would consider OS X an unreliable platform. Not because of crashes or freezing up, but because of Apple's flip flop attitude to updates and new versions that does not support previous functionality.

     

    Wether El Capitan is better than Yosemite I don't know yet because I always wait 4-5 months and sometimes longer for Apple to weed out the worst problems after the release, before I install it. Anyway our OS X Mac mini server (past EOL but maintained) is only used to run the server app so the only criteria here in dependability and security, so for the server app I update quickly with each version released for security reasons.

  • by DazeConfusedAndLost,

    DazeConfusedAndLost DazeConfusedAndLost Oct 24, 2015 9:00 AM in response to PeterKjeldsen
    Level 1 (34 points)
    Oct 24, 2015 9:00 AM in response to PeterKjeldsen

    PeterKjeldsen wrote:

     

    We don't use the wikis since the updates from snow leopard to lion showed that Apple could not be trusted anymore. Our setup is only using very few services in the server. The server app has become a laughing stock, one version had webmail the next did not, another version had GD library the next had it removed and all custom scripts had to be redone etc.

     

    The IP problem in the log files is really minor to the nagging suspicion if everything else is ok. If you're running mission critical/life and death stuff I would consider OS X an unreliable platform. Not because of crashes or freezing up, but because of Apple's flip flop attitude to updates and new versions that does not support previous functionality.

     

    Wether El Capitan is better than Yosemite I don't know yet because I always wait 4-5 months and sometimes longer for Apple to weed out the worst problems after the release, before I install it. Anyway our OS X Mac mini server (past EOL but maintained) is only used to run the server app so the only criteria here in dependability and security, so for the server app I update quickly with each version released for security reasons.

    There is also an update to to El Cap (10.11.1). So it looks like you will have some downtime when you update/upgrade.

  • by scottl31,

    scottl31 scottl31 Oct 24, 2015 9:02 AM in response to PeterKjeldsen
    Level 1 (13 points)
    Servers Enterprise
    Oct 24, 2015 9:02 AM in response to PeterKjeldsen

    What do you mean "Apple could not be trusted anymore"? Is it that they can't seem to implement something and maintain it and keep it working over multiple server revisions? We still have some sites on SL server, but are going to move them to the Yosemite server soon. But we have the wiki on there that we like to use, and I couldn't figure out how to move the calendar. So we may just leave that one on SL.

  • by scottl31,

    scottl31 scottl31 Oct 24, 2015 9:07 AM in response to DazeConfusedAndLost
    Level 1 (13 points)
    Servers Enterprise
    Oct 24, 2015 9:07 AM in response to DazeConfusedAndLost

    Daze, why will there be down time going to El Cap?

  • by DazeConfusedAndLost,

    DazeConfusedAndLost DazeConfusedAndLost Oct 24, 2015 9:09 AM in response to scottl31
    Level 1 (34 points)
    Oct 24, 2015 9:09 AM in response to scottl31

    scottl31 wrote:

     

    Daze, why will there be down time going to El Cap?

    Server downtime. The OS upgrades will take a little bit of time and the older the hardware, the longer it takes. While that is going on, Server's services will be unavailable.

  • by PeterKjeldsen,

    PeterKjeldsen PeterKjeldsen Oct 24, 2015 9:28 AM in response to DazeConfusedAndLost
    Level 1 (0 points)
    Oct 24, 2015 9:28 AM in response to DazeConfusedAndLost

    You know what? I'll upgrade to El Cap tomorrow and see how it goes just for laughs and kicks I'll test it tonight on another mini...

  • by scottl31,

    scottl31 scottl31 Oct 24, 2015 9:47 AM in response to PeterKjeldsen
    Level 1 (13 points)
    Servers Enterprise
    Oct 24, 2015 9:47 AM in response to PeterKjeldsen

    We have always just gotten a new server SL->ML->Yos. Been afraid to upgrade in place after the horror stories of the Lion upgrade. It would be cool if you did that upgrade and let us know how it goes.

  • by PeterKjeldsen,

    PeterKjeldsen PeterKjeldsen Oct 24, 2015 9:49 AM in response to scottl31
    Level 1 (0 points)
    Oct 24, 2015 9:49 AM in response to scottl31

    If you ever used xGrid and Podcast Producer/Podcast composer on the SL server for anything an update will blow them away. You can also wave bye bye to at some stage webmail/SquirrelMail (I'm not sure which update), but you can download the easier to deal with Roundcube, and GD library will become problematic as mentioned earlier. And of course our wikis were all lost for some obscure reason, I had backups but the update could not handle it automatically. It could be a glitch here no one knows.

     

    If you rely on the settings in System Preferences to reboot your server at preset times that functionality will also vanish.

     

    Apart from those issues the server runs... day in and day out with no interruption (except from updates), almost as good as when it was running OS X only as a server back in the day on Tiger.

  • by DazeConfusedAndLost,

    DazeConfusedAndLost DazeConfusedAndLost Oct 31, 2015 10:19 AM in response to PeterKjeldsen
    Level 1 (34 points)
    Oct 31, 2015 10:19 AM in response to PeterKjeldsen

    Just a heads up. There is an issue with the %a variable. For whatever reason, the %a remote ip address variable is returning a random remote ip address under certain situation(s). That is, it does not match the remote host %h variable used in the proxy access log. The one I noticed is with "Google favicon" bots from Google ip range. If you have scripts/programs/apps to scan through your logs, you may want to use the proxy access log until this is sorted out. Or just be aware that the remote ip addresses in those specific entries are incorrect.

  • by ccaggi,

    ccaggi ccaggi Nov 10, 2015 2:45 AM in response to DazeConfusedAndLost
    Level 1 (0 points)
    Nov 10, 2015 2:45 AM in response to DazeConfusedAndLost

    While the service_proxy_access.log file includes the originating IP number changing the virtual host CustomLogs so that they are "combinedProxy" does not (the first field is the virtual host name). Note I don't need combinedvhostproxy as I use a separate access file for each virtual host but that doesn't work either.

  • by DazeConfusedAndLost,

    DazeConfusedAndLost DazeConfusedAndLost Nov 12, 2015 1:50 PM in response to ccaggi
    Level 1 (34 points)
    Nov 12, 2015 1:50 PM in response to ccaggi

    ccaggi wrote:

     

    While the service_proxy_access.log file includes the originating IP number changing the virtual host CustomLogs so that they are "combinedProxy" does not (the first field is the virtual host name). Note I don't need combinedvhostproxy as I use a separate access file for each virtual host but that doesn't work either.

    You may have missed PeterKjeldsen's post on page 1 of this thread (post #6). It links to the other thread about editing the server apache config file.

    None of the pre-defined LogFormat will give you the originating IP address as of the current version of Server app (5.0.15). Not combinedProxy, and not combinedvhostproxy. That is because the variable %{last-x-forwarded-for}e is not returning a value. However, the %a variable will work.* You will need to add that to whatever LogFormat line you use for your logs. For example:

    Change:

        LogFormat "%{last-x-forwarded-host}e %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedproxy

    to:

        LogFormat "%{last-x-forwarded-host}e %a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedproxy

     

    You will need to restart web services for the change to take effect. Using the Server app UI is easiest.

     

    The file you need to edit is:

    /Library/Server/Web/Config/apache2/httpd_server_app.conf

     

    *: See my post above regarding funky Google ip ranges.

  • by ccaggi,

    ccaggi ccaggi Nov 12, 2015 7:36 PM in response to DazeConfusedAndLost
    Level 1 (0 points)
    Nov 12, 2015 7:36 PM in response to DazeConfusedAndLost

    Thanks, that fixed that problem. Now onto more Server 5.0.15 brokenness (sigh).

  • by scottl31,

    scottl31 scottl31 Jan 2, 2016 12:04 PM in response to PeterKjeldsen
    Level 1 (13 points)
    Servers Enterprise
    Jan 2, 2016 12:04 PM in response to PeterKjeldsen

    Hi guys,

     

    I have not gone to El Cap yet and still on server 5.015.

     

    But I notice that in console, when I click on the logs under apache2, it says "you do not have permission to read this log" and they are grayed out. if I go and manually change the permissions on the apache2 folder and contents, it reverts back later.

     

    Anybody know what's going on, and how to fix it?

     

    Thanks,

    Scott

Previous Page 2