A few pointers about launchd and daemondo

[Panagiotis Atmatzidis-2]

Greetings,

I've created my first launchd script. It's for OpenVPN2. Here are the  
files I've created so far:

devo:/opt/local/etc/LaunchDaemons root# ls -l org.macports.OpenVPN2/
total 16
-rwxr-xr-x   1 root  admin   957 Oct 30 23:06 OpenVPN2.wrapper
-rw-r--r--   1 root  admin  1026 Oct 30 23:39  
org.macports.OpenVPN2.plist

The Wrapper
-----
#!/bin/sh

. /etc/rc.common

load() {
                 if [ -d /System/Library/Extensions/tun.kext ]; then
                         kextload -q /System/Library/Extensions/
tun.kext;
                 else
                         echo "tun.kext not found in /System/Library/
Extensions/"
                 fi
         }

StartService() {
                 load; # first load the module
                 if [[ $( kextstat -l | grep -q 'tun' )$? == 0 ]]; then
                 /opt/local/sbin/openvpn2 --config /opt/local/etc/ovpn/
server.conf --writepid /opt/local/etc/ovpn/ovpn.pid --daemon OpenVPN2
                                 /usr/bin/logger "OpenVPN is loaded"
         else
                                 /usr/bin/logger "tun extensions is  
not loaded."
                 fi
}

StopService() {
   if [[ $( kextstat -l | grep -q 'tun' )$? == 0 ]]; then
         kextunload /System/Library/Extensions/tun.kext # first unload  
the module
   fi

   pid=`cat /opt/local/etc/ovpn/ovpn.pid` # get the pid number
   if [ $? -eq 0 ]; then
     kill $pid
   fi
}

RestartService() {
   StopService "$@"
   StartService "$@"
}

RunService "$1"


the .plist which is an: ln -sf /opt/local/etc/LaunchDaemons/
org.macports.OpenVPN2/org.macports.OpenVPN2.plist /Library/
LaunchDaemons/....
------------------------
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
<plist version='1.0'>
<dict>
<key>Label</key><string>org.macports.OpenVPN2</string>
<key>ProgramArguments</key>
<array>
         <string>/opt/local/bin/daemondo</string>
         <string>--label=OpenVPN2</string>
         <string>--start-cmd</string>
         <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
OpenVPN2.wrapper</string>
         <string>start</string>
         <string>;</string>
         <string>--stop-cmd</string>
         <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
OpenVPN2.wrapper</string>
         <string>stop</string>
         <string>;</string>
         <string>--restart-cmd</string>
         <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
OpenVPN2.wrapper</string>
         <string>restart</string>
         <string>;</string>
         <string>--pid=none</string>
</array>
<key>Debug</key><false/>
<key>Disabled</key><false/>
<key>OnDemand</key><false/>
<key>RunAtLoad</key><true/>
<key>NetworkState</key><true/>
</dict>
</plist>




However, there are two issues that I can't seem to be able to manage  
right now.

The first is that OpenVPN does not start at boot while the module is  
loaded succesfully. When I login to the system and kill daemondo, it  
relaunches itself and ovpn works fine. I suspect that the problem is  
en0. Launchd tries to launchd openvpn before en0 comes up. That's why  
I put the NetworkState keyword, but it does not seem to effect *any*  
startup script. I had issues with dnsmasq also in the recent past.

The second problem with this script is that when I unload it via  
launchd it does not kill the process. Launchd unloads the script and  
(probably) will not be launchd (if -w is added) in the next boot but  
daemondo keeps running the process nevertheless. Is this a normal  
behaviour?

I'm not *that* worried about the second. I'd prefer to have a solution  
about the first one, which is the most important for me.

Best regards & thanks in advance

Panagiotis (atmosx) Atmatzidis

email: atma@...
URL: http://www.convalesco.org
GnuPG key id: 0xFC4E8BB4
--
The wise man said: "Never argue with an idiot. They bring you down to  
their level and beat you with experience."

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[Panagiotis Atmatzidis-2]

Hello,

I solved both issues adjusting the wrapper accordingly. Should I throw  
a ticket for this wrapper for this to be added on macports? I don't  
know how to edit the port though...

# openvpn configuration file
#!/bin/sh

. /etc/rc.common

load() {
                if [ -d /System/Library/Extensions/tun.kext ]; then
                        kextload -q /System/Library/Extensions/tun.kext;
                else
                        echo "tun.kext not found in /System/Library/Extensions/"
                fi
        }

StartService() {
                #
                # Use the "ipconfig waitall" command to wait for all the
                # interfaces to come up:
                #
                ipconfig waitall
               
                load; # first load the module
                if [[ $( kextstat -l | grep -q 'tun' )$? == 0 ]]; then
                 /opt/local/sbin/openvpn2 --config /opt/local/etc/ovpn/
server.conf --writepid /opt/local/etc/ovpn/ovpn.pid --daemon OpenVPN2
                                /usr/bin/logger "OpenVPN is loaded"
         else
                                /usr/bin/logger "tun extensions is not loaded."
                fi
}

StopService() {
        pid=`cat /opt/local/etc/ovpn/ovpn.pid`
        if [ $? -eq 0 ]; then
            kill $pid
        fi


        if [[ $( kextstat -l | grep -q 'tun' )$? == 0 ]]; then
    kextunload /System/Library/Extensions/tun.kext
       
                if [[ $( kextstat -l | grep -q 'tun' )$? == 0 ]]; then
                        /usr/bin/logger "The tun module is unloaded successfully"
                else
                        /usr/bin/logger "There was a problem. I was not able to unload tun  
module!!!"
    fi
        fi


}

RestartService() {
   StopService "$@"
   StartService "$@"
}

RunService "$1"





Panagiotis (atmosx) Atmatzidis

email: atma@...
URL: http://www.convalesco.org
GnuPG key id: 0xFC4E8BB4
--
The wise man said: "Never argue with an idiot. They bring you down to  
their level and beat you with experience."

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[shdjsahwkjq ehwq kehwkq h]

On Oct 30, 2009, at 2:55 PM, Panagiotis Atmatzidis wrote:

> Greetings,
>
> I've created my first launchd script. It's for OpenVPN2. Here are  
> the files I've created so far:

Just out of general curiosity, why use openVPN2?  I have been meaning  
to create a set of launchd items that start the built in VPN server on  
OS X.  It is really quite trivial with the inbuilt one.  Just start it  
up, give it a range, plop in some user:pass stuff, and you have a  
pretty nice VPN ready to go.

Apparently OS X Sever has a GUI for this, but OS X Client does not  
even claim to support it, though it does, and has been every day I am  
at the coffee shop :)

What advantages, and what am I missing out on by using this method  
over openVPN?

> devo:/opt/local/etc/LaunchDaemons root# ls -l org.macports.OpenVPN2/
> total 16
> -rwxr-xr-x   1 root  admin   957 Oct 30 23:06 OpenVPN2.wrapper
> -rw-r--r--   1 root  admin  1026 Oct 30 23:39  
> org.macports.OpenVPN2.plist

I do not like the way in which launchd scrips are put into play in  
MacPorts.  I never could understand the magic it was doing under the  
hood.  Since I consider them almost always starting servers of some  
form, I have moved to making my own normal .plist files and putting  
them in files/tld.app.binary.plist, so org.pure-ftpd.ftpd.plist or  
similar.

it would seem every time I needed to add something a little out of the  
ordinary I was getting stuck, whereas a plist is rather simple for me  
to understand, and just as easy to copy into place.

> The Wrapper
>
> [snip... removed wrapper code]
>
>
> the .plist which is an: ln -sf /opt/local/etc/LaunchDaemons/
> org.macports.OpenVPN2/org.macports.OpenVPN2.plist /Library/
> LaunchDaemons/....
> ------------------------
> <?xml version='1.0' encoding='UTF-8'?>
> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
> "http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
> <plist version='1.0'>
> <dict>
> <key>Label</key><string>org.macports.OpenVPN2</string>
> <key>ProgramArguments</key>
> <array>
>        <string>/opt/local/bin/daemondo</string>
>        <string>--label=OpenVPN2</string>
>        <string>--start-cmd</string>
>        <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
> OpenVPN2.wrapper</string>
>        <string>start</string>
>        <string>;</string>
>        <string>--stop-cmd</string>
>        <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
> OpenVPN2.wrapper</string>
>        <string>stop</string>
>        <string>;</string>
>        <string>--restart-cmd</string>
>        <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
> OpenVPN2.wrapper</string>
>        <string>restart</string>
>        <string>;</string>
>        <string>--pid=none</string>
> </array>
> <key>Debug</key><false/>
> <key>Disabled</key><false/>
> <key>OnDemand</key><false/>
> <key>RunAtLoad</key><true/>
> <key>NetworkState</key><true/>
> </dict>
> </plist>
>
>
> However, there are two issues that I can't seem to be able to manage  
> right now.
>
> The first is that OpenVPN does not start at boot while the module is  
> loaded succesfully. When I login to the system and kill daemondo, it  
> relaunches itself and ovpn works fine. I suspect that the problem is  
> en0. Launchd tries to launchd openvpn before en0 comes up. That's  
> why I put the NetworkState keyword, but it does not seem to effect  
> *any* startup script. I had issues with dnsmasq also in the recent  
> past.

Are you sure that "NetworkState" is what you are looking for?
 From the man page  $man 5 launchd.plist

      NetworkState <boolean>
      If true, the job will be kept alive as long as the network is up,
      where up is defined as at least one non-loopback interface being  
up
      and having IPv4 or IPv6 addresses assigned to them.  If false, the
      job will be kept alive in the inverse condition.

NetworkState seems to be for keeping a job alive if the network is up,  
or keeping it dead if the network is down.  In your case, the app is  
not up yet.  My interpretation is that since the app never launched  
via launchd, the NetworkState test never comes into play.

I could be wrong, that is just how I am reading that man page.

I have a machine that loads a good chunk of IP's into an interface,  
and I need to make sure they are all up before moving on, or the final  
app will not work correctly.  I used `ipconfig` to make sure this  
happened in a "wrapper" script.

$man ipconfig
There is a lot of good stuff in there that could help you, even just  
the logging verbosity you can kick up and see what is going on.

The argument I used was

      waitall     Blocks until all network services have completed  
configuring,
                 or have timed out in the process of configuring.
                  This is only useful for initial system start-up time
                 synchronization for legacy network services that are inca-
                  pable of dealing with dynamic network configuration  
changes.

If you were to add to your wrapper/start script:
/usr/sbin/ipconfig waitall

Then a basic test of the result of that command:
$? tests the last command ran, as far as I now, or set the result to a  
variable...
        if [[ $? -eq 0 ]]
        then
                echo "Interfaces are NOT up"
        else
                echo "Interfaces are up"
        fi

You probably have to put that in a while loop, and keep on trying  
until the interfaces are all up.  I would be inclined to put a little  
`sleep 1` in there to reduce the number of checks.  And a counter to  
make sure it does not accidentally run wild and keep running forever,  
sort of a safety net to exit.  If loopcount > 100 then exit type of  
thing.

> The second problem with this script is that when I unload it via  
> launchd it does not kill the process. Launchd unloads the script and  
> (probably) will not be launchd (if -w is added) in the next boot but  
> daemondo keeps running the process nevertheless. Is this a normal  
> behaviour?

I can not help on this one, unload should not only remove the job, but  
also stop it if it is running.  Though I find this very dependent on  
how the app itself works.  For example, I never seem to get a  
unloading of Apache2 to stop apache, which I assume is why there are  
tools like `apachectl stop`.

Apache spawns a number of processes of itself as needed, so to me, it  
make sense that launchd would only be able to track the initial app it  
started.  If I had a launchd item that started 10 copies of `find`,  
and then unloaded that launchd, I would imagine I would only stop 9 of  
those copies, the rest would keep running.  Or maybe I only stop the  
script itself, and all the copies of `find` keep running.

Maybe keep that in mind when working on this.

> I'm not *that* worried about the second. I'd prefer to have a  
> solution about the first one, which is the most important for me.


I would get a standalone launchd plist calling a script that does the  
work of starting the job as you want it.  While you can jam all sorts  
of commands and scripting into a launchd file, I find them to be messy  
and hard to debug.  You have to take special care with spaces, quotes,  
and paths and some other little "gotcha" areas.

I find if I can get a local script to start my app as I want it, then  
I just have one command in my plist to call that script, things are a  
lot cleaner.

Once you have that working, it is up to you to use `daemondo` or not.

Hopefully some of this is of help.  I am not very versed in much of  
this, so it is mostly just to point you in a direction that hopefully  
gets you where you need to go.
--
Scott * If you contact me off list replace talklists@ with scott@ *

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[Panagiotis Atmatzidis-2]

On 05 Νοε 2009, at 1:54 π.μ., Scott Haneda wrote:

> On Oct 30, 2009, at 2:55 PM, Panagiotis Atmatzidis wrote:
>
>> Greetings,
>>
>> I've created my first launchd script. It's for OpenVPN2. Here are  
>> the files I've created so far:
>
> Just out of general curiosity, why use openVPN2?  I have been  
> meaning to create a set of launchd items that start the built in VPN  
> server on OS X.  It is really quite trivial with the inbuilt one.  
> Just start it up, give it a range, plop in some user:pass stuff, and  
> you have a pretty nice VPN ready to go.
>
> Apparently OS X Sever has a GUI for this, but OS X Client does not  
> even claim to support it, though it does, and has been every day I  
> am at the coffee shop :)
>
> What advantages, and what am I missing out on by using this method  
> over openVPN?

None I believe. I run a mac mini G4 ppc with MacOSX Tiger Desktop  
edition though and I don't plan to buy the server edition of tiger for  
home usage only. So actually I don't have that option. I can't recall  
now, but there are also a few more advantages to openvpn over the  
standard L2TP/IPsec implementation.

>
>> devo:/opt/local/etc/LaunchDaemons root# ls -l org.macports.OpenVPN2/
>> total 16
>> -rwxr-xr-x   1 root  admin   957 Oct 30 23:06 OpenVPN2.wrapper
>> -rw-r--r--   1 root  admin  1026 Oct 30 23:39  
>> org.macports.OpenVPN2.plist
>
> I do not like the way in which launchd scrips are put into play in  
> MacPorts.  I never could understand the magic it was doing under the  
> hood.  Since I consider them almost always starting servers of some  
> form, I have moved to making my own normal .plist files and putting  
> them in files/tld.app.binary.plist, so org.pure-ftpd.ftpd.plist or  
> similar.

It works with abstractions. In some cases even triple ones. Launchd  
calles a script, which calls a second script, which (it may) call a  
third script. While the magic of launchd should be the capability to  
handle everything using a clean .plist file, but apparently that's not  
the case.

>
> it would seem every time I needed to add something a little out of  
> the ordinary I was getting stuck, whereas a plist is rather simple  
> for me to understand, and just as easy to copy into place.

True. plist and XML in general is *easy* to understand. Launchd is  
easy to explain, it's hard to make it work though. I believe that it  
is a great idea, implemented badly. But that's my opinion, I don't  
plan to start a flamewar, but for me (and I've lost several hours on  
it) lacks of flexibility and I fail to see how it will replace cron  
(among other things).

>
>> The Wrapper
>>
>> [snip... removed wrapper code]
>>
>>
>> the .plist which is an: ln -sf /opt/local/etc/LaunchDaemons/
>> org.macports.OpenVPN2/org.macports.OpenVPN2.plist /Library/
>> LaunchDaemons/....
>> ------------------------
>> <?xml version='1.0' encoding='UTF-8'?>
>> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
>> "http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
>> <plist version='1.0'>
>> <dict>
>> <key>Label</key><string>org.macports.OpenVPN2</string>
>> <key>ProgramArguments</key>
>> <array>
>>       <string>/opt/local/bin/daemondo</string>
>>       <string>--label=OpenVPN2</string>
>>       <string>--start-cmd</string>
>>       <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
>> OpenVPN2.wrapper</string>
>>       <string>start</string>
>>       <string>;</string>
>>       <string>--stop-cmd</string>
>>       <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
>> OpenVPN2.wrapper</string>
>>       <string>stop</string>
>>       <string>;</string>
>>       <string>--restart-cmd</string>
>>       <string>/opt/local/etc/LaunchDaemons/org.macports.OpenVPN2/
>> OpenVPN2.wrapper</string>
>>       <string>restart</string>
>>       <string>;</string>
>>       <string>--pid=none</string>
>> </array>
>> <key>Debug</key><false/>
>> <key>Disabled</key><false/>
>> <key>OnDemand</key><false/>
>> <key>RunAtLoad</key><true/>
>> <key>NetworkState</key><true/>
>> </dict>
>> </plist>
>>
>>
>> However, there are two issues that I can't seem to be able to  
>> manage right now.
>>
>> The first is that OpenVPN does not start at boot while the module  
>> is loaded succesfully. When I login to the system and kill  
>> daemondo, it relaunches itself and ovpn works fine. I suspect that  
>> the problem is en0. Launchd tries to launchd openvpn before en0  
>> comes up. That's why I put the NetworkState keyword, but it does  
>> not seem to effect *any* startup script. I had issues with dnsmasq  
>> also in the recent past.
>
> Are you sure that "NetworkState" is what you are looking for?
> From the man page  $man 5 launchd.plist
>
>     NetworkState <boolean>
>     If true, the job will be kept alive as long as the network is up,
>     where up is defined as at least one non-loopback interface being  
> up
>     and having IPv4 or IPv6 addresses assigned to them.  If false, the
>     job will be kept alive in the inverse condition.
>
> NetworkState seems to be for keeping a job alive if the network is  
> up, or keeping it dead if the network is down.  In your case, the  
> app is not up yet.  My interpretation is that since the app never  
> launched via launchd, the NetworkState test never comes into play.
>
> I could be wrong, that is just how I am reading that man page.
>
> I have a machine that loads a good chunk of IP's into an interface,  
> and I need to make sure they are all up before moving on, or the  
> final app will not work correctly.  I used `ipconfig` to make sure  
> this happened in a "wrapper" script.
>
> $man ipconfig
> There is a lot of good stuff in there that could help you, even just  
> the logging verbosity you can kick up and see what is going on.
>
> The argument I used was
>
>     waitall     Blocks until all network services have completed  
> configuring,
> or have timed out in the process of configuring.
>                 This is only useful for initial system start-up time
> synchronization for legacy network services that are inca-
>                 pable of dealing with dynamic network configuration  
> changes.
>
> If you were to add to your wrapper/start script:
> /usr/sbin/ipconfig waitall

Thanks, I figure this out [1]. Here is my solution on the problem. I  
have just two interfaces here, en0 and tun. We need to load tun, after  
en0 is up.

>> The second problem with this script is that when I unload it via  
>> launchd it does not kill the process. Launchd unloads the script  
>> and (probably) will not be launchd (if -w is added) in the next  
>> boot but daemondo keeps running the process nevertheless. Is this a  
>> normal behaviour?
>
> I can not help on this one, unload should not only remove the job,  
> but also stop it if it is running.  Though I find this very  
> dependent on how the app itself works.  For example, I never seem to  
> get a unloading of Apache2 to stop apache, which I assume is why  
> there are tools like `apachectl stop`.
>
> Apache spawns a number of processes of itself as needed, so to me,  
> it make sense that launchd would only be able to track the initial  
> app it started.  If I had a launchd item that started 10 copies of  
> `find`, and then unloaded that launchd, I would imagine I would only  
> stop 9 of those copies, the rest would keep running.  Or maybe I  
> only stop the script itself, and all the copies of `find` keep  
> running.
>
> Maybe keep that in mind when working on this.

This one was also bad shell script. Apparently now it does [1].  
However, the shell script I wrote can be done a lot better, I just  
don't have the time (and will at this point) to polish it.

>
>> I'm not *that* worried about the second. I'd prefer to have a  
>> solution about the first one, which is the most important for me.
>
>
> I would get a standalone launchd plist calling a script that does  
> the work of starting the job as you want it.  While you can jam all  
> sorts of commands and scripting into a launchd file, I find them to  
> be messy and hard to debug.  You have to take special care with  
> spaces, quotes, and paths and some other little "gotcha" areas.

Yes, this is true.

>
> I find if I can get a local script to start my app as I want it,  
> then I just have one command in my plist to call that script, things  
> are a lot cleaner.
>
> Once you have that working, it is up to you to use `daemondo` or not.
>
> Hopefully some of this is of help.  I am not very versed in much of  
> this, so it is mostly just to point you in a direction that  
> hopefully gets you where you need to go.
> --
> Scott * If you contact me off list replace talklists@ with scott@ *
>

Thank you nevertheless. I was "saved" by the 'ipconfig wait' keyword.  
I thought that launchd came up to make us get rid of the script lying  
all over the place in /. Probably it's not like that. Still I fail to  
see the "greatness" in launchd.


[1]  http://www.convalesco.org/2009/10/31/manage-to-launch-openvpn-at-boot-under-macosx/

Panagiotis (atmosx) Atmatzidis

email: atma@...
URL: http://www.convalesco.org
GnuPG key id: 0xFC4E8BB4
--
The wise man said: "Never argue with an idiot. They bring you down to  
their level and beat you with experience."

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[Nico Nachtigall]

Hi guys,

I'd like to have gtk apps localized.
At the moment e.g wireshark is english only on my system and pan2 got
translated only in 1/3 or so.

/> locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL=

Am I missing some packages or there are just no translations in macports?


Cheers
Nico

--
http://www.hochzeit-fotograf.org/
http://www.hochzeitsbuch.info/
_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[Ryan Schmidt-24]

On Nov 5, 2009, at 02:08, Nico Nachtigall wrote:

> I'd like to have gtk apps localized.
> At the moment e.g wireshark is english only on my system and pan2 got
> translated only in 1/3 or so.
>
> /> locale
> LANG="de_DE.UTF-8"
> LC_COLLATE="de_DE.UTF-8"
> LC_CTYPE="de_DE.UTF-8"
> LC_MESSAGES="de_DE.UTF-8"
> LC_MONETARY="de_DE.UTF-8"
> LC_NUMERIC="de_DE.UTF-8"
> LC_TIME="de_DE.UTF-8"
> LC_ALL=
>
> Am I missing some packages or there are just no translations in  
> macports?

Most ports should be installing all available localizations by  
default. For each port you find that doesn't have localizations  
working properly, you should feel free to file tickets in the issue  
tracker to have that resolved, if possible.


P.S: To start a new thread, please use the "New Message" feature in  
your email program; don't "Reply" to unrelated messages as this messes  
up the threading.



_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[Ryan Schmidt-24]

On Nov 4, 2009, at 17:54, Scott Haneda wrote:

> I have moved to making my own normal .plist files and putting them  
> in files/tld.app.binary.plist, so org.pure-ftpd.ftpd.plist or similar.

Since pure-ftpd's web site is pureftpd.org (not pure-ftpd.org which  
appears to be owned by a domain squatter), the name of the plist  
should be org.pureftpd.whatever (not org.pure-ftpd.whatever).


_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[shdjsahwkjq ehwq kehwkq h]

On Nov 9, 2009, at 12:21 AM, Ryan Schmidt wrote:

> On Nov 4, 2009, at 17:54, Scott Haneda wrote:
>
>> I have moved to making my own normal .plist files and putting them  
>> in files/tld.app.binary.plist, so org.pure-ftpd.ftpd.plist or  
>> similar.
>
> Since pure-ftpd's web site is pureftpd.org (not pure-ftpd.org which  
> appears to be owned by a domain squatter), the name of the plist  
> should be org.pureftpd.whatever (not org.pure-ftpd.whatever).

I have been meaning to ask about this, as the current port is  
pureftpd, and mind is pure-ftpd.  All binaries are pure-ftpd, the only  
thing that is not is the webite.

The app is "Pure-FTPd".  When I work out this variant conflicts issue,  
what is the procedure for the fact there is an old per with the name  
of pureftpd, and I am going with pure-ftpd?

Where does it state the the correct naming conventions for laaunchd  
plists?

I never knew the name was supposed to resolve back to the reverse of  
the website.

What do you do on a hosted site, for example:
developersfiles.com/imagetool

-> com.developersfiles.imagetool ?

Seems weird to hold them all under a domain that just hosts the  
files.  SF.net being one of them, but they at least use  
projectname.sourceforge.net

And then, all this is in macports, so maybe I should use  
org.macports.pure-ftpd.whatever.
--
Scott * If you contact me off list replace talklists@ with scott@ *

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[Ryan Schmidt-24]

On Nov 9, 2009, at 04:50, Scott Haneda wrote:

> On Nov 9, 2009, at 12:21 AM, Ryan Schmidt wrote:
>
>> On Nov 4, 2009, at 17:54, Scott Haneda wrote:
>>
>>> I have moved to making my own normal .plist files and putting them  
>>> in files/tld.app.binary.plist, so org.pure-ftpd.ftpd.plist or  
>>> similar.
>>
>> Since pure-ftpd's web site is pureftpd.org (not pure-ftpd.org which  
>> appears to be owned by a domain squatter), the name of the plist  
>> should be org.pureftpd.whatever (not org.pure-ftpd.whatever).
>
> I have been meaning to ask about this, as the current port is  
> pureftpd, and mind is pure-ftpd.  All binaries are pure-ftpd, the  
> only thing that is not is the webite.
>
> The app is "Pure-FTPd".  When I work out this variant conflicts  
> issue, what is the procedure for the fact there is an old per with  
> the name of pureftpd, and I am going with pure-ftpd?

Prior to MacPorts 1.8.0, the advice was: never rename a port, because  
we have no facility for supporting that. Now we do: the "replaced_by"  
keyword. So if you want to change the port name, you would leave a  
"stub port" called pureftpd which says it has been "replaced_by pure-
ftpd". This way, anybody who already has the port pureftpd installed  
will be properly advised to upgrade to pure-ftpd via "port outdated".

Note the port name doesn't have to match the binary name (though I can  
see how it might be clearer). For example, the port pkgconfig installs  
the binary pkg-config.


> Where does it state the the correct naming conventions for laaunchd  
> plists?

http://developer.apple.com/macosx/launchd.html

"Apple suggests the use of the reverse-DNS naming convention; for  
instance, com.apple.syslogd.plist. This is an excellent convention,  
and you should follow it when defining your own services."


> I never knew the name was supposed to resolve back to the reverse of  
> the website.
>
> What do you do on a hosted site, for example:
> developersfiles.com/imagetool
>
> -> com.developersfiles.imagetool ?

Could be.


> Seems weird to hold them all under a domain that just hosts the  
> files.  SF.net being one of them, but they at least use projectname.sourceforge.net

The files do not need to live on the domain; the purpose of the naming  
convention is to avoid filename clashes on the user's computer. To  
achieve this, the files are named using the reverse of a domain name  
that you or the project owns.


> And then, all this is in macports, so maybe I should use  
> org.macports.pure-ftpd.whatever.

The launchd plists MacPorts automatically creates for you with the  
startupitem keywords do use the org.macports prefix, so that would be  
appropriate.

Before I used MacPorts, when I compiled software by hand and created  
my own plists for things, I used com.ryandesign as the prefix, because  
they were plists I had created. Even if the plist was for, say, the  
lighttpd web server, I didn't want to name the plist with the  
net.lighttpd prefix, because that seemed to imply to me that the  
developers of lighttpd had created the plist and were responsible for  
its content, which was not correct; I was.


_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

[shdjsahwkjq ehwq kehwkq h]

>> The app is "Pure-FTPd".  When I work out this variant conflicts  
>> issue, what is the procedure for the fact there is an old per with  
>> the name of pureftpd, and I am going with pure-ftpd?
>
> Prior to MacPorts 1.8.0, the advice was: never rename a port,  
> because we have no facility for supporting that. Now we do: the  
> "replaced_by" keyword. So if you want to change the port name, you  
> would leave a "stub port" called pureftpd which says it has been  
> "replaced_by pure-ftpd". This way, anybody who already has the port  
> pureftpd installed will be properly advised to upgrade to pure-ftpd  
> via "port outdated".
>
> Note the port name doesn't have to match the binary name (though I  
> can see how it might be clearer). For example, the port pkgconfig  
> installs the binary pkg-config.

Seriously, every port I touch has some aspect to it that makes it more  
than just a straight port :)  I used to hate p5's. I love p5's now.  
P5's are totally my friends, all other ports, I am making a list, when  
I go on my killing spree, alphabetical, keeping ASSP rightly at the  
top of that list

Thanks for your other explanations, they were helpful, especially to  
see you had the same thoughts as I did wit using your name in a plist.
--
Scott * If you contact me off list replace talklists@ with scott@ *

_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users