Re: Confirm: About freebsd Registration

2017-10-18 Thread Michael Butler 

On 10/18/17 17:40, Jonathan Chen wrote:

On 19 October 2017 at 10:06,   wrote:

I've forwarded this to the FreeBSD Foundation at
i...@freebsdfoundation.org for their action.

I would guess that Runbang Holdings should not be granted the
freebsd.*.cn domain names, since they probably have little or no
connection to the FreeBSD Foundation and its work.  I might be
wrong about that, of course, but the Foundation staff are the
ones to sort it out in any case.


Actually, this sort of emails are a common form of marketing spam. My
employers have received and ignored quite a few of these.


And I reported it (automagically) as spam through my account @spamcop 
(i.e. cisco) as I do with any spurious rubbish received via a 
mailing-list or not,


imb

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: svn commit: r424112 - in head/www/fcgiwrap: . files

2017-10-18 Thread Mathieu Arnold 
Le 18/10/2017 à 12:05, Mathieu Arnold a écrit :
> Le 17/10/2017 à 22:26, Xin LI a écrit :
>> Hi, Mathieu,
>>
>> Sorry for catching this late, but is there any reason not to simply
>> run the daemon under the desired credentials, instead of doing this
>> chown/chmod dance afterward?
>>
>> Not all systems start fcgiwrap daemon quick enough for the socket to
>> show up (a race condition, with potential of not setting it correctly,
>> which is observed about 3/5 times on my server).  Moreover, this will
>> also encourage using unneeded privileges (assuming fcgiwrap runs under
>> root credentials, which is the default fcgiwrap_user).
> There is a very good reason to not run the application with a different
> user than the web server, yes.

s/to not run/to run/.

Also, I had not imagined anyone would run their cgi as root. The default
user should probably be nobody or something less silly, but definitively
not root.

> My use case is a git server, the web server runs as www, and to be able
> to write to the repositories the gitweb application must be run as git.
>
> I have:
>
> fcgiwrap_enable="YES"
> fcgiwrap_profiles="git"
> fcgiwrap_socket_owner="www"
> fcgiwrap_git_socket="unix:/var/run/fcgiwrap/git.socket"
> fcgiwrap_git_user="git"
>
>> Cheers,
>>
>> On Mon, Oct 17, 2016 at 5:03 AM, Mathieu Arnold  wrote:
>>> Author: mat
>>> Date: Mon Oct 17 12:03:08 2016
>>> New Revision: 424112
>>> URL: https://svnweb.freebsd.org/changeset/ports/424112
>>>
>>> Log:
>>>   Add changing the owner/group/mode for the socket.
>>>
>>>   PR:   213385
>>>   Submitted by: mat
>>>   Approved by:  maintainer
>>>   Sponsored by: Absolight
>>>
>>> Modified:
>>>   head/www/fcgiwrap/Makefile   (contents, props changed)
>>>   head/www/fcgiwrap/files/fcgiwrap.in
>>>
>>> Modified: head/www/fcgiwrap/Makefile
>>> ==
>>> --- head/www/fcgiwrap/Makefile  Mon Oct 17 12:03:03 2016(r424111)
>>> +++ head/www/fcgiwrap/Makefile  Mon Oct 17 12:03:08 2016(r424112)
>>> @@ -2,7 +2,7 @@
>>>
>>>  PORTNAME=  fcgiwrap
>>>  PORTVERSION=   1.1.0
>>> -PORTREVISION=  3
>>> +PORTREVISION=  4
>>>  CATEGORIES=www
>>>  MASTER_SITES=  http://www.skysmurf.nl/comp/FreeBSD/distfiles/
>>>
>>>
>>> Modified: head/www/fcgiwrap/files/fcgiwrap.in
>>> ==
>>> --- head/www/fcgiwrap/files/fcgiwrap.in Mon Oct 17 12:03:03 2016
>>> (r424111)
>>> +++ head/www/fcgiwrap/files/fcgiwrap.in Mon Oct 17 12:03:08 2016
>>> (r424112)
>>> @@ -19,6 +19,9 @@
>>>  # - tcp6:[ipv6_addr]:port (for ipv6)
>>>  # fcgiwrap_flags=
>>>  # Use fcgiwrap_user to run fcgiwrap as user
>>> +# Use fcgiwrap_socket_mode to change the mode of the socket
>>> +# Use fcgiwrap_socket_owner to change the owner of the socket
>>> +# Use fcgiwrap_socket_group to change the group of the socket
>>>
>>>  # fcgiwrap rc.d script supports multiple profiles (a-la rc.d/nginx)
>>>  # When profiles are specified, the non-profile specific parameters become 
>>> defaults.
>>> @@ -29,10 +32,12 @@
>>>  # fcgiwrap_enable="YES"
>>>  # fcgiwrap_profiles="myserver myotherserver"
>>>  # fcgiwrap_flags="-c 4"
>>> +# fcgiwrap_socket_owner="www"
>>>  # fcgiwrap_myserver_socket="unix:/var/run/fcgiwrap.myserver.socket"
>>>  # fcgiwrap_myserver_user="myuser"
>>>  # 
>>> fcgiwrap_myotherserver_socket="unix:/var/run/fcgiwrap.myotherserver.socket"
>>>  # fcgiwrap_myotherserver_user="myotheruser"
>>> +# fcgiwrap_myserver_socket_mode="0775"
>>>  # fcgiwrap_myotherserver_flags=""  # No flags for this profile.
>>>
>>>  . /etc/rc.subr
>>> @@ -62,6 +67,26 @@ fcgiwrap_precmd() {
>>> install -d -o root -g wheel -m 1777 /var/run/fcgiwrap
>>>  }
>>>
>>> +fcgiwrap_postcmd() {
>>> +   # This is only for unix sockets
>>> +   case "${fcgiwrap_socket}" in
>>> +   unix:*)
>>> +   ;;
>>> +   *)
>>> +   return
>>> +   ;;
>>> +   esac
>>> +   if [ -n "${fcgiwrap_socket_mode}" ]; then
>>> +   chmod ${fcgiwrap_socket_mode} ${fcgiwrap_socket#unix:}
>>> +   fi
>>> +   if [ -n "${fcgiwrap_socket_owner}" ]; then
>>> +   chown ${fcgiwrap_socket_owner} ${fcgiwrap_socket#unix:}
>>> +   fi
>>> +   if [ -n "${fcgiwrap_socket_group}" ]; then
>>> +   chgrp ${fcgiwrap_socket_group} ${fcgiwrap_socket#unix:}
>>> +   fi
>>> +}
>>> +
>>>  fcgiwrap_cleansocket() {
>>> # Workaround the fact that fcgiwrap doesn't cleanup his socket at 
>>> stopping
>>> case ${fcgiwrap_socket} in
>>> @@ -78,6 +103,7 @@ pidfile="${pidprefix}.pid"  # May be a d
>>>  procname="%%PREFIX%%/sbin/${name}"
>>>  command="/usr/sbin/daemon"
>>>  start_precmd="fcgiwrap_precmd"
>>> +start_postcmd="fcgiwrap_postcmd"
>>>  stop_postcmd="fcgiwrap_cleansocket"
>>>
>>>  load_rc_config $name
>>> @@ -86,6 +112,9 @@ load_rc_config $name

Re: Confirm: About freebsd Registration

2017-10-18 Thread Lee Brown 
On Wed, Oct 18, 2017 at 2:40 PM, Jonathan Chen  wrote:

> On 19 October 2017 at 10:06,   wrote:
> > I've forwarded this to the FreeBSD Foundation at
> > i...@freebsdfoundation.org for their action.
> >
> > I would guess that Runbang Holdings should not be granted the
> > freebsd.*.cn domain names, since they probably have little or no
> > connection to the FreeBSD Foundation and its work.  I might be
> > wrong about that, of course, but the Foundation staff are the
> > ones to sort it out in any case.
>
> Actually, this sort of emails are a common form of marketing spam. My
> employers have received and ignored quite a few of these.
>
> Cheers.
> --
> Jonathan Chen 
>

Same here.  They are not even on the list of accredited registrars
, they are
just expensive brokers.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Confirm: About freebsd Registration

2017-10-18 Thread Diane Bruce 
On Wed, Oct 18, 2017 at 05:06:14PM -0400, scratch65...@att.net wrote:
> I've forwarded this to the FreeBSD Foundation at
> i...@freebsdfoundation.org for their action.  

http://www.techrepublic.com/blog/it-security/the-chinese-domain-scam/

> 
> I would guess that Runbang Holdings should not be granted the
> freebsd.*.cn domain names, since they probably have little or no
> connection to the FreeBSD Foundation and its work.  I might be
> wrong about that, of course, but the Foundation staff are the
> ones to sort it out in any case.
> 
> 
> [Default] On Thu, 19 Oct 2017 00:21:04 +0800, "Tony Liu"
>  wrote:
> 
> >Dear Manager,
> >(Please forward this to your CEO, because this is urgent. Thanks)
> >This is Tony Liu, Senior Manager of a Network Service Company which is the 
> >domain name registration center in Shanghai, China. On October 16th, 2017, 
> >we received an application from Runbang Holdings Ltd requested ??freebsd?? 
> >as their internet keyword and China (CN) domain names( freebsd.cn/ 
> >freebsd.com.cn/ freebsd.net.cn/ freebsd.org.cn).  But after checking it, we 
> >find this name conflict with your company name or trademark. In order to 
> >deal with this matter better, it??s necessary to send email to you and 
> >confirm whether this company is your distributor or business partner in 
> >China?
> >Best Regards
> >Tony Liu
> >Senior Manager
> >
> >
> >China Registrar Headquarters
> >www.chinaregistrar.org
> >8008, Tianan Building, No. 1399 Jinqiao Road, 
> >Shanghai 200120, China
> >0086-21-6191-8696(Tel) 
> >0086-1377-4400-340( Mobi)
> >0086-21-6191-8697(Fax)
> >___
> >freebsd-ports@freebsd.org mailing list
> >https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Confirm: About freebsd Registration

2017-10-18 Thread Jonathan Chen 
On 19 October 2017 at 10:06,   wrote:
> I've forwarded this to the FreeBSD Foundation at
> i...@freebsdfoundation.org for their action.
>
> I would guess that Runbang Holdings should not be granted the
> freebsd.*.cn domain names, since they probably have little or no
> connection to the FreeBSD Foundation and its work.  I might be
> wrong about that, of course, but the Foundation staff are the
> ones to sort it out in any case.

Actually, this sort of emails are a common form of marketing spam. My
employers have received and ignored quite a few of these.

Cheers.
-- 
Jonathan Chen 

> [Default] On Thu, 19 Oct 2017 00:21:04 +0800, "Tony Liu"
>  wrote:
>
>>Dear Manager,
>>(Please forward this to your CEO, because this is urgent. Thanks)
>>This is Tony Liu, Senior Manager of a Network Service Company which is the 
>>domain name registration center in Shanghai, China. On October 16th, 2017, we 
>>received an application from Runbang Holdings Ltd requested ??freebsd?? as 
>>their internet keyword and China (CN) domain names( freebsd.cn/ 
>>freebsd.com.cn/ freebsd.net.cn/ freebsd.org.cn).  But after checking it, we 
>>find this name conflict with your company name or trademark. In order to deal 
>>with this matter better, it??s necessary to send email to you and confirm 
>>whether this company is your distributor or business partner in China?
>>Best Regards
>>Tony Liu
>>Senior Manager
>>
>>
>>China Registrar Headquarters
>>www.chinaregistrar.org
>>8008, Tianan Building, No. 1399 Jinqiao Road,
>>Shanghai 200120, China
>>0086-21-6191-8696(Tel)
>>0086-1377-4400-340( Mobi)
>>0086-21-6191-8697(Fax)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Confirm: About freebsd Registration

2017-10-18 Thread scratch65535 
I've forwarded this to the FreeBSD Foundation at
i...@freebsdfoundation.org for their action.  

I would guess that Runbang Holdings should not be granted the
freebsd.*.cn domain names, since they probably have little or no
connection to the FreeBSD Foundation and its work.  I might be
wrong about that, of course, but the Foundation staff are the
ones to sort it out in any case.


[Default] On Thu, 19 Oct 2017 00:21:04 +0800, "Tony Liu"
 wrote:

>Dear Manager,
>(Please forward this to your CEO, because this is urgent. Thanks)
>This is Tony Liu, Senior Manager of a Network Service Company which is the 
>domain name registration center in Shanghai, China. On October 16th, 2017, we 
>received an application from Runbang Holdings Ltd requested ??freebsd?? as 
>their internet keyword and China (CN) domain names( freebsd.cn/ 
>freebsd.com.cn/ freebsd.net.cn/ freebsd.org.cn).  But after checking it, we 
>find this name conflict with your company name or trademark. In order to deal 
>with this matter better, it??s necessary to send email to you and confirm 
>whether this company is your distributor or business partner in China?
>Best Regards
>Tony Liu
>Senior Manager
>
>
>China Registrar Headquarters
>www.chinaregistrar.org
>8008, Tianan Building, No. 1399 Jinqiao Road, 
>Shanghai 200120, China
>0086-21-6191-8696(Tel) 
>0086-1377-4400-340( Mobi)
>0086-21-6191-8697(Fax)
>___
>freebsd-ports@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Policy for Apache module installation / deinstallation (LoadModule manipulation)

2017-10-18 Thread Miroslav Lachman 

Chris H wrote on 10/18/2017 19:25:

On Wed, 18 Oct 2017 02:16:37 +0200 Miroslav Lachman <000.f...@quip.cz> wrote



Installing a Module would:
  o search for the Module line in httpd.conf (commented/uncommented)
  o create a commented line (if not exist)
  o present a banner regarding the [httpd.conf] line


I agree with this.


DeInstalling a Module would:
  o search for the Module line (commented/uncommented)
  o nuke the line (if exists)
  o produce a banner regarding what happened

I don't think this method is too intrusive (regarding httpd.conf)
because if the Module line doesn't exist; placing a commented line,
and providing a banner as to how to Activate it, is/should be expected.
OTOH removing a Module line on a Module you are UNinstalling should
be expected; as the Module no longer exists, and can no longer be
enabled. This process should also present a banner, as to what just
occurred.


But there is a big problem on pkg upgrade which means deinstall + 
install. All users of some module are left without this module after 
simple pkg upgrade and this is bad. It is the same as if 'pkg delete 
apache24' deletes whole httpd.conf which it does not if it was modified.


That's why I propose

DeInstalling a Module would:
  o search for the Module line (commented only)
  o nuke the line (if exists and is commented)
  o produce a banner "You may need to manually remove LoadModule 
mod_whatever if it is no longer needed."


pkg upgrade should leave the machine in working state just after restart 
of upgraded services. No need to re-enable some module again and again 
after each pkg upgrade.


Plain pkg upgrade should not revert any changes in config files which I 
did on purpose.


Miroslav Lachman

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: requesting policy for Apache module installation (LoadModule manipulation)

2017-10-18 Thread Chris H 
On Wed, 18 Oct 2017 02:16:37 +0200 Miroslav Lachman <000.f...@quip.cz> wrote

> Hello,
> I would like to ask some changes in how Apache modules are installed.
> There are many maintainers and many different sources for Apache 
> modules. Some modules are installing sample files, some are modifying 
> httpd.conf (LoadModule line) after each install / deinstall.
> 
> The modification after each deinstall is really a mess. If I installed 
> mod_xsendfile, enabled it in httpd.conf and later will use pkg upgrade 
> it will modify my httpd.conf in unwanted way - the mod_xsendfile will be 
> disabled. Same applies to many other modules.
> 
> Some modules (mod_php) is installed and enabled by default. (different 
> behaviour for different modules? Why?)
> 
> Can this behaviour be changed (unified) for all Apache modules to not 
> touch these lines (modules enabled by user)?
> 
> If some port install some config file and user did some changes, this 
> file must not be deleted by deinstalling the port so why Apache modules 
> can remove / comment out lines touched by users?
> 
> Broken Apache webserver after each pkg upgrade is really annoying.
> 
> 
> Making all ports use the same script post-install / post-deinstall would 
> be nice too.
> 
> For example mod_php uses
> 
> "scripts":{
>"post-install":"/usr/local/sbin/apxs -e -a -n php5 libphp5.so",
>"pre-deinstall":"/usr/local/sbin/apxs -e -A -n php5 libphp5.so"
> },
> 
> mod_xsendfile uses
> 
> "scripts":{
>"post-install":"/usr/local/sbin/apxs -e -A -n xsendfile 
> /usr/local/libexec/apache24/mod_xsendfile.so",
>"post-deinstall":"/usr/bin/sed -i '' -E 
> '/LoadModule[[:blank:]]+xsendfile_module/d' 
> /usr/local/etc/apache24/httpd.conf\necho \"Don't forget to remove all 
> mod_xsendfile-related directives in your httpd.conf\""
> }
> 
> to achieve the same results (broken httpd.conf)
> 
> mod_php uses pre-deinstall
> mod_xsendfile uses post-deinstall
> 
> mod_php enables mod_php on installation by apxs -e -a
> mod_xsendfile adds commented line by apxs -e -A
> 
> This is just example of two modules. I looked at more modules and they 
> are almost unique - each using different targets, different apxs options 
> etc.
> 
> I am proposing not touching httpd.conf on deinstall at all and just 
> printing the warning that the corresponding LoadModule line should be 
> removed if it is no longer necessary. (by running apxs command?)
> 
> Also use "apxs -e -A -n moduleName" on install only if there is no 
> LoadModule line for this module:
> 
> "post-install":"/usr/bin/grep -E '^#?LoadModule.*php5_module' 
> /usr/local/etc/apache24/httpd.conf || /usr/local/sbin/apxs -e -A -n php5 
> libphp5.so"
> 
> Another way to achieve this can be separate file in apache24/modules.d/ 
> installed as sample and if user wants to enable it, just rename it to 
> moduleName.conf. Then it will not be touched by pkg upgrade / deinstall 
> phase.
Thank you for bringing this up, Miroslav. This has always annoyed me
as well -- and I'm a Module maintainer. :)
If it were up to me;

Installing a Module would:
 o search for the Module line in httpd.conf (commented/uncommented)
 o create a commented line (if not exist)
 o present a banner regarding the [httpd.conf] line

DeInstalling a Module would:
 o search for the Module line (commented/uncommented)
 o nuke the line (if exists)
 o produce a banner regarding what happened

I don't think this method is too intrusive (regarding httpd.conf)
because if the Module line doesn't exist; placing a commented line,
and providing a banner as to how to Activate it, is/should be expected.
OTOH removing a Module line on a Module you are UNinstalling should
be expected; as the Module no longer exists, and can no longer be
enabled. This process should also present a banner, as to what just
occurred.

Thanks again, for bringing this up.

--Chris

P.S. IMHO this probably should have been prefaced with [RFC]
eg; [RFC] Policy for Apache Module Installation / Deinstallation
just my 2¢ :)
> 
> Miroslav Lachman
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Confirm: About freebsd Registration

2017-10-18 Thread Tony Liu 
Dear Manager,
(Please forward this to your CEO, because this is urgent. Thanks)
This is Tony Liu, Senior Manager of a Network Service Company which is the 
domain name registration center in Shanghai, China. On October 16th, 2017, we 
received an application from Runbang Holdings Ltd requested “freebsd” as their 
internet keyword and China (CN) domain names( freebsd.cn/ freebsd.com.cn/ 
freebsd.net.cn/ freebsd.org.cn).  But after checking it, we find this name 
conflict with your company name or trademark. In order to deal with this matter 
better, it’s necessary to send email to you and confirm whether this company is 
your distributor or business partner in China?
Best Regards
Tony Liu
Senior Manager


China Registrar Headquarters
www.chinaregistrar.org
8008, Tianan Building, No. 1399 Jinqiao Road, 
Shanghai 200120, China
0086-21-6191-8696(Tel) 
0086-1377-4400-340( Mobi)
0086-21-6191-8697(Fax)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

IT Operations Professionals, Systems Engineers and Administrators Contact Email List

2017-10-18 Thread Adam Smith 


Hi,

I hope you are the right person to discuss about "IT Operations Professionals, 
Systems Engineers and Administrators Contact Email List".

Reach: System and Network Administrators, Engineers, Developers, Programmers, 
System Architects, Technical Managers, C-Level, VPs, Directors and more as per 
your criteria.

List Includes: Contact Name, Company Name, and Company URL, Title, Verified 
Email, Physical Address, Phone Number, Fax Number and Industry etc...

Usage: Unlimited

Let me know if you would be looking for this information?

Thank you and I look forward to hearing from you.

Regards,
Adam Smith
B2B and Tradeshow Data Specialist

"OPT-OUT"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: svn commit: r424112 - in head/www/fcgiwrap: . files

2017-10-18 Thread Mathieu Arnold 
Le 17/10/2017 à 22:26, Xin LI a écrit :
> Hi, Mathieu,
>
> Sorry for catching this late, but is there any reason not to simply
> run the daemon under the desired credentials, instead of doing this
> chown/chmod dance afterward?
>
> Not all systems start fcgiwrap daemon quick enough for the socket to
> show up (a race condition, with potential of not setting it correctly,
> which is observed about 3/5 times on my server).  Moreover, this will
> also encourage using unneeded privileges (assuming fcgiwrap runs under
> root credentials, which is the default fcgiwrap_user).

There is a very good reason to not run the application with a different
user than the web server, yes.

My use case is a git server, the web server runs as www, and to be able
to write to the repositories the gitweb application must be run as git.

I have:

fcgiwrap_enable="YES"
fcgiwrap_profiles="git"
fcgiwrap_socket_owner="www"
fcgiwrap_git_socket="unix:/var/run/fcgiwrap/git.socket"
fcgiwrap_git_user="git"

> Cheers,
>
> On Mon, Oct 17, 2016 at 5:03 AM, Mathieu Arnold  wrote:
>> Author: mat
>> Date: Mon Oct 17 12:03:08 2016
>> New Revision: 424112
>> URL: https://svnweb.freebsd.org/changeset/ports/424112
>>
>> Log:
>>   Add changing the owner/group/mode for the socket.
>>
>>   PR:   213385
>>   Submitted by: mat
>>   Approved by:  maintainer
>>   Sponsored by: Absolight
>>
>> Modified:
>>   head/www/fcgiwrap/Makefile   (contents, props changed)
>>   head/www/fcgiwrap/files/fcgiwrap.in
>>
>> Modified: head/www/fcgiwrap/Makefile
>> ==
>> --- head/www/fcgiwrap/Makefile  Mon Oct 17 12:03:03 2016(r424111)
>> +++ head/www/fcgiwrap/Makefile  Mon Oct 17 12:03:08 2016(r424112)
>> @@ -2,7 +2,7 @@
>>
>>  PORTNAME=  fcgiwrap
>>  PORTVERSION=   1.1.0
>> -PORTREVISION=  3
>> +PORTREVISION=  4
>>  CATEGORIES=www
>>  MASTER_SITES=  http://www.skysmurf.nl/comp/FreeBSD/distfiles/
>>
>>
>> Modified: head/www/fcgiwrap/files/fcgiwrap.in
>> ==
>> --- head/www/fcgiwrap/files/fcgiwrap.in Mon Oct 17 12:03:03 2016
>> (r424111)
>> +++ head/www/fcgiwrap/files/fcgiwrap.in Mon Oct 17 12:03:08 2016
>> (r424112)
>> @@ -19,6 +19,9 @@
>>  # - tcp6:[ipv6_addr]:port (for ipv6)
>>  # fcgiwrap_flags=
>>  # Use fcgiwrap_user to run fcgiwrap as user
>> +# Use fcgiwrap_socket_mode to change the mode of the socket
>> +# Use fcgiwrap_socket_owner to change the owner of the socket
>> +# Use fcgiwrap_socket_group to change the group of the socket
>>
>>  # fcgiwrap rc.d script supports multiple profiles (a-la rc.d/nginx)
>>  # When profiles are specified, the non-profile specific parameters become 
>> defaults.
>> @@ -29,10 +32,12 @@
>>  # fcgiwrap_enable="YES"
>>  # fcgiwrap_profiles="myserver myotherserver"
>>  # fcgiwrap_flags="-c 4"
>> +# fcgiwrap_socket_owner="www"
>>  # fcgiwrap_myserver_socket="unix:/var/run/fcgiwrap.myserver.socket"
>>  # fcgiwrap_myserver_user="myuser"
>>  # 
>> fcgiwrap_myotherserver_socket="unix:/var/run/fcgiwrap.myotherserver.socket"
>>  # fcgiwrap_myotherserver_user="myotheruser"
>> +# fcgiwrap_myserver_socket_mode="0775"
>>  # fcgiwrap_myotherserver_flags=""  # No flags for this profile.
>>
>>  . /etc/rc.subr
>> @@ -62,6 +67,26 @@ fcgiwrap_precmd() {
>> install -d -o root -g wheel -m 1777 /var/run/fcgiwrap
>>  }
>>
>> +fcgiwrap_postcmd() {
>> +   # This is only for unix sockets
>> +   case "${fcgiwrap_socket}" in
>> +   unix:*)
>> +   ;;
>> +   *)
>> +   return
>> +   ;;
>> +   esac
>> +   if [ -n "${fcgiwrap_socket_mode}" ]; then
>> +   chmod ${fcgiwrap_socket_mode} ${fcgiwrap_socket#unix:}
>> +   fi
>> +   if [ -n "${fcgiwrap_socket_owner}" ]; then
>> +   chown ${fcgiwrap_socket_owner} ${fcgiwrap_socket#unix:}
>> +   fi
>> +   if [ -n "${fcgiwrap_socket_group}" ]; then
>> +   chgrp ${fcgiwrap_socket_group} ${fcgiwrap_socket#unix:}
>> +   fi
>> +}
>> +
>>  fcgiwrap_cleansocket() {
>> # Workaround the fact that fcgiwrap doesn't cleanup his socket at 
>> stopping
>> case ${fcgiwrap_socket} in
>> @@ -78,6 +103,7 @@ pidfile="${pidprefix}.pid"  # May be a d
>>  procname="%%PREFIX%%/sbin/${name}"
>>  command="/usr/sbin/daemon"
>>  start_precmd="fcgiwrap_precmd"
>> +start_postcmd="fcgiwrap_postcmd"
>>  stop_postcmd="fcgiwrap_cleansocket"
>>
>>  load_rc_config $name
>> @@ -86,6 +112,9 @@ load_rc_config $name
>>  fcgiwrap_enable=${fcgiwrap_enable:-"NO"}
>>  fcgiwrap_user=${fcgiwrap_user:-"root"}
>>  fcgiwrap_socket=${fcgiwrap_socket:-"unix:/var/run/fcgiwrap/fcgiwrap.sock"}
>> +fcgiwrap_socket_mode=${fcgiwrap_socket_mode:-"0755"}
>> +fcgiwrap_socket_owner=${fcgiwrap_socket_owner:-"root"}
>> +fcgiwrap_socket_group=${fcgiwrap_socket_group:-"wheel"}
>>
>>  # This handles

Re: RE: Openfire 4.1.6 compile failed

2017-10-18 Thread Pietro Cerutti 
Hi Doug,

I can't reproduce it here. What are exactly the commands you're issuing 
to upgrade the port?

I don't see where the .logs.CB0BLDkFGJLs symlink might be coming from.

Does removing it manually help?

Thanks,

On Oct 18 17 01:13, Doug Sampson wrote:
> > During upgrade of openfire from 4.1.5 to 4.16 the following error was
> > observed:
> > 
> > ===>  Installing for openfire-4.1.6,1
> > ===>  Checking if openfire already installed
> > ===>   Registering installation for openfire-4.1.6,1
> > Installing openfire-4.1.6,1...
> > ===> Creating groups.
> > Using existing group 'openfire'.
> > ===> Creating users
> > Using existing user 'openfire'.
> > pkg-static: Fail to rename /usr/local/share/java/openfire/.logs.a8He9zi58mQv
> > -> /usr/local/share/java/openfire/logs:Is a directory
> > *** Error code 70
> > 
> > Stop.
> > make[1]: stopped in /usr/ports/net-im/openfire
> > *** Error code 1
> > 
> > Stop.
> > make: stopped in /usr/ports/net-im/openfire
> > 
> > ===>>> A backup package for openfire-4.1.5,1 should
> >be located in /usr/ports/packages/portmaster-backup
> > 
> > ===>>> Installation of openfire-4.1.6,1 (net-im/openfire) failed
> > ===>>> Aborting update
> > 
> > ===>>> Update for net-im/openfire failed
> > ===>>> Aborting update
> > 
> > ===>>> There are messages from installed ports to display,
> >but first take a moment to review the error messages
> >above.  Then press Enter when ready to proceed.
> > 
> > 
> 
> # ll /usr/local/share/java/openfire
> total 36
> lrwxr-xr-x  1 openfire  openfire17 Aug 29 17:32 .logs.CB0BLDkFGJLs -> 
> /var/log/openfire
> lrwxr-xr-x  1 openfire  openfire23 Aug 29 17:32 conf -> 
> /usr/local/etc/openfire
> lrwxr-xr-x  1 openfire  openfire16 Aug 29 17:32 embedded-db -> 
> /var/db/openfire
> drwxr-xr-x  3 openfire  openfire   512 Aug 31 12:13 enterprise
> drwxr-xr-x  2 openfire  openfire   512 Aug 30 15:08 fastpath
> drwxr-xr-x  2 openfire  openfire   512 Aug 31 12:45 index
> drwxr-xr-x  2 root  openfire  1024 Oct 17 18:01 lib
> drwxr-xr-x  2 openfire  openfire   512 Oct 17 17:40 logs
> drwxr-xr-x  3 openfire  openfire   512 Aug 30 15:08 monitoring
> drwxr-xr-x  2 openfire  openfire   512 Aug 30 15:08 nodejs
> drwxr-xr-x  5 openfire  openfire  2048 Oct 17 18:01 plugins
> drwxr-xr-x  4 root  openfire   512 Oct 17 18:01 resources
> #

-- 
Pietro Cerutti
The FreeBSD Project
g...@freebsd.org


signature.asc
Description: PGP signature

FreeBSD ports you maintain which are out of date

2017-10-18 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/py-spyder | 2.3.7   | v3.2.4
+-+
misc/tkinfo | 2.8 | 2.11
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Debugging ports

2017-10-18 Thread Piotr Kubaj via freebsd-ports 

Well, 11-STABLE now has LLVM 5.0 too, so it should work as well as in head. I 
actually tried it on the recent 11-STABLE.

On 17-10-18 10:03:49, Guido Falsi wrote:

On 10/18/2017 09:59, Piotr Kubaj wrote:

According to https://wiki.freebsd.org/lldb, it should work just fine on
amd64, apart from kernel debugger. I suppose there should be some
improvements for other archs too, since that page was updated 1.5 years
ago :)


Great! And good to know, I'll give it a spin the next time I need to
debug something on head :)

--
Guido Falsi 

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



--
_ 
/ All Gods were immortal. \

| |
\ -- Stanislaw J. Lec, "Unkempt Thoughts" /
- 
   \   ^__^

\  (oo)\___
   (__)\   )\/\
   ||w |
   || ||


signature.asc
Description: PGP signature

Re: Debugging ports

2017-10-18 Thread Guido Falsi 
On 10/18/2017 09:59, Piotr Kubaj wrote:
> According to https://wiki.freebsd.org/lldb, it should work just fine on
> amd64, apart from kernel debugger. I suppose there should be some
> improvements for other archs too, since that page was updated 1.5 years
> ago :)

Great! And good to know, I'll give it a spin the next time I need to
debug something on head :)

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Debugging ports

2017-10-18 Thread Piotr Kubaj via freebsd-ports 

According to https://wiki.freebsd.org/lldb, it should work just fine on amd64, 
apart from kernel debugger. I suppose there should be some improvements for 
other archs too, since that page was updated 1.5 years ago :)

On 17-10-18 09:54:05, Guido Falsi wrote:

On 10/18/2017 09:52, Piotr Kubaj wrote:

Shouldn't lldb be the replacement for gdb in base?


I'm not keeping an eye on that, but I don't think it's ready at present.

--
Guido Falsi 

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



--
_ 
/ Due to lack of disk space, this fortune \

\ database has been discontinued. /
- 
   \   ^__^

\  (oo)\___
   (__)\   )\/\
   ||w |
   || ||


signature.asc
Description: PGP signature

Re: Debugging ports

2017-10-18 Thread Guido Falsi 
On 10/18/2017 09:52, Piotr Kubaj wrote:
> Shouldn't lldb be the replacement for gdb in base?

I'm not keeping an eye on that, but I don't think it's ready at present.

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Debugging ports

2017-10-18 Thread Piotr Kubaj via freebsd-ports 

Shouldn't lldb be the replacement for gdb in base?

On 17-10-18 09:47:25, Guido Falsi wrote:

On 10/18/2017 06:33, Jan Beich wrote:

Kubilay Kocak  writes:


On 10/18/17 8:29 AM, Jan Beich wrote:


Guido Falsi  writes:


On 10/17/2017 23:11, Guido Falsi wrote:



Thing is, recompiling with WITH_DEBUG doesn't help (I only get
memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to
CMAKE_ARGS (the port uses CMake).


Sorry, I clearly did not parse your message correctly.

Looks strange though, WITH_DEBUG always worked for me... Usually I
compile the whole set in poudriere with WITH_DEBUG, to make sure all
libraries have symbols too.


WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer
which may hinder stack unwinding, doesn't enable debug symbols for ports
not respecting CFLAGS, often a nop for non-C/C++ ports, etc.


Could the framework WITH_DEBUG block remove this (and potentially) other
relevant flags from C*FLAGS if present with variable modifiers?


Only for what make(1) inherits when Mk/bsd.port.mk is parsed. A lot more
ports pass the option via makefiles under WRKSRC that cannot be altered
short of patching or overriding all CFLAGS.

To get accurate list of offenders an -exp run WITH_DEBUG=1 is required
then grep(1) build logs for -fomit-frame-pointer and -O* flags. This can
result in bugs against ports that fail to properly respect CFLAGS, so the
port maintainers can help with patches.


I'm preparing a patch related to WITH_DEBUG, which, if accepted, will
need an exp-run before going in.

That would be a good chance to perform a check for these kind of things.

But I'm still working on it and will need a little more time. I'll let
you know as soon as I have something I am willing to show.

BTW on head gdb is gone from base for i386/amd64 AFAIK, so ports gdb
will be the only way to go in the future.

--
Guido Falsi 

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



--
 
/ The student in question is performing  \

| minimally for his peer group and is an |
\ emerging underachiever./
 
   \   ^__^

\  (oo)\___
   (__)\   )\/\
   ||w |
   || ||


signature.asc
Description: PGP signature

Re: Debugging ports

2017-10-18 Thread Guido Falsi 
On 10/18/2017 06:33, Jan Beich wrote:
> Kubilay Kocak  writes:
> 
>> On 10/18/17 8:29 AM, Jan Beich wrote:
>>
>>> Guido Falsi  writes:
>>>
 On 10/17/2017 23:11, Guido Falsi wrote:

>>
>> Thing is, recompiling with WITH_DEBUG doesn't help (I only get
>> memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to
>> CMAKE_ARGS (the port uses CMake).

 Sorry, I clearly did not parse your message correctly.

 Looks strange though, WITH_DEBUG always worked for me... Usually I
 compile the whole set in poudriere with WITH_DEBUG, to make sure all
 libraries have symbols too.
>>>
>>> WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer
>>> which may hinder stack unwinding, doesn't enable debug symbols for ports
>>> not respecting CFLAGS, often a nop for non-C/C++ ports, etc.
>>
>> Could the framework WITH_DEBUG block remove this (and potentially) other
>> relevant flags from C*FLAGS if present with variable modifiers?
> 
> Only for what make(1) inherits when Mk/bsd.port.mk is parsed. A lot more
> ports pass the option via makefiles under WRKSRC that cannot be altered
> short of patching or overriding all CFLAGS.
> 
> To get accurate list of offenders an -exp run WITH_DEBUG=1 is required
> then grep(1) build logs for -fomit-frame-pointer and -O* flags. This can
> result in bugs against ports that fail to properly respect CFLAGS, so the
> port maintainers can help with patches.

I'm preparing a patch related to WITH_DEBUG, which, if accepted, will
need an exp-run before going in.

That would be a good chance to perform a check for these kind of things.

But I'm still working on it and will need a little more time. I'll let
you know as soon as I have something I am willing to show.

BTW on head gdb is gone from base for i386/amd64 AFAIK, so ports gdb
will be the only way to go in the future.

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: py27-fail2ban-0.10.1

2017-10-18 Thread Alex V. Petrov 
Yes, it works! That's what you need. Thank you all.

18.10.2017 13:02, Matthias Fechner пишет:
> Hi Alex,
> 
> Am 17.10.17 um 14:20 schrieb Alex V. Petrov:
>> Need a working sample for the new version of the port for pf.
> 
> I have it working now.
> Put into your pf.conf where the rules from fail2ban be added the line:
> # Anchor for fail2ban
> anchor "f2b/*"
> 
> In your jail.local:
> [DEFAULT]
> banaction = pf[actiontype=]
> 
> The rest you can keep on standard. Just add and enable your jails into
> fail2ban that should run.
> This configuration will block all connections from the IP. If you want
> to only specific on some ports you can use another actiontype, but there
> is another bug that will cause this not to work in 0.10.1.
> 
> 
> Gruß,
> Matthias
> 

-- 
-
Alex.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: py27-fail2ban-0.10.1

2017-10-18 Thread Matthias Fechner 

Hi Alex,

Am 17.10.17 um 14:20 schrieb Alex V. Petrov:

Need a working sample for the new version of the port for pf.


I have it working now.
Put into your pf.conf where the rules from fail2ban be added the line:
# Anchor for fail2ban
anchor "f2b/*"

In your jail.local:
[DEFAULT]
banaction = pf[actiontype=]

The rest you can keep on standard. Just add and enable your jails into 
fail2ban that should run.
This configuration will block all connections from the IP. If you want 
to only specific on some ports you can use another actiontype, but there 
is another bug that will cause this not to work in 0.10.1.



Gruß,
Matthias

--
"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the universe trying to 
produce bigger and better idiots. So far, the universe is winning." -- 
Rich Cook

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"