Re: monitoring ruby app memory usage with passenger-recycler (was: Cannot require library for passenger in ruby)

2018-02-23 Thread Karli Sjöberg via freebsd-ports

___
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: monitoring ruby app memory usage with passenger-recycler (was: Cannot require library for passenger in ruby)

2018-02-23 Thread Karli Sjöberg via freebsd-ports
On Thu, 2018-02-22 at 18:28 +, Marcin Cieslak wrote:
> On Thu, 22 Feb 2018, Karli Sjöberg wrote:
> 
> > 
> > > 
> > > How do I interpret the output of 'procstat -v ' though? Can
> > > I
> > > sum
> > > up all of the RES or PRES numbers to get the total virtual memory
> > > that
> > > this process is consuming?
> > I hacked at it a bit and came up with an updated patch that
> > includes
> > the changes you made, plus my own.
> > 
> > Since "private dirty RSS" isn´t available, I´ve used "maximum RSS"
> > from
> > 'procstat -r ', which is far from perfect, but it´s better
> > than
> > nothing. It now runs and does what you´d expect :)
> > 
> > I have attached it to this email.
> Thanks! Now we should try to integrate it into the passenger itself
> :)

No it´s just 'foreman_maintain' that needs fixing. I´m actually d
oing the git dance right now getting it accepted upstream :)

https://github.com/theforeman/foreman_maintain/pull/146

/K

> 
> I think you might be looking for "private resident pages" (PRES),
> but I am not sure. 
> 
> For your particular problem I would log procstat -v output in its
> entirety
> at regular intervals and see where the memory grows.
> 
> Happy you got there somehow :)
> 
> Marcin
___
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: monitoring ruby app memory usage with passenger-recycler (was: Cannot require library for passenger in ruby)

2018-02-22 Thread Karli Sjöberg via freebsd-ports
On Thu, 2018-02-22 at 10:11 +0100, Karli Sjöberg via freebsd-ports
wrote:
> On Thu, 2018-02-22 at 07:50 +0100, Karli Sjöberg via freebsd-ports
> wrote:
> > On Tue, 2018-02-20 at 21:31 +, Marcin Cieslak wrote:
> > > On Mon, 19 Feb 2018, Karli Sjöberg wrote:
> > > 
> > > > > What is the tool you are trying to deploy? foreman_maintain?
> > > 
> > > Sorry, I was too quick. This foreman_main is used to
> > > download/update
> > > foreman
> > > from RedHat Satellite servers, which is not what you want.
> > 
> > Well, I want the "foreman_maintain" package, which includes
> > "passenger-
> > recycler", so I guess I do want it :)
> > 
> > > 
> > > However, the passenger-recycler script is a standalone script
> > > which
> > > could possibly used with this little fix:
> > 
> > Ooh, awesome! Yeah, should´ve figured since it´s only at 0.1.3 :)
> > 
> > > 
> > > https://github.com/theforeman/foreman_maintain/pull/143
> > > 
> > > To apply this, please add files/patch-bin_passenger-recycler in
> > > the
> > > port I've sent before:
> > > 
> > > --- bin/passenger-recycler.orig 2018-02-20 21:09:18 UTC
> > > +++ bin/passenger-recycler
> > > @@ -41,10 +41,10 @@ def process_status?(pid)
> > >  end
> > >  
> > >  require 'phusion_passenger'
> > > +PhusionPassenger.locate_directories
> > >  require 'phusion_passenger/platform_info'
> > >  require 'phusion_passenger/platform_info/ruby'
> > >  require 'phusion_passenger/admin_tools/memory_stats'
> > > -PhusionPassenger.locate_directories
> > >  stats = PhusionPassenger::AdminTools::MemoryStats.new
> > >  unless stats.platform_provides_private_dirty_rss_information?
> > >puts 'Please run as root or platform unsupported'
> > 
> > Yes, this works, thanks!
> > 
> > > 
> > > 
> > > But the real problem is that Passenger does think it supports
> > > getting process private dirty RSS memory information only on
> > > Linux:
> > > 
> > > https://github.com/phusion/passenger/blob/219ad24159ae4033a342e6a
> > > d7
> > > 53
> > > cfee05d98bae0/src/ruby_supportlib/phusion_passenger/admin_tools/m
> > > em
> > > or
> > > y_stats.rb#L121
> > > 
> > > In file
> > > src/ruby_supportlib/phusion_passenger/admin_tools/memory_stats.rb
> > > :
> > > 
> > > 120   def platform_provides_private_dirty_rss_information?
> > > 121 return os_name_simple == "linux"
> > > 122   end
> > > 
> > > This support probably would need to be written. So,
> > > unfortunately,
> > > passenger-recycler
> > > as written will exit with:
> > > 
> > >   Please run as root or platform unsupported
> > 
> > Yes, I have now gotten to this stage at least, thank you very much!
> > I
> > don´t mind having a look at it, it might be simplest thing to
> > write,
> > or
> > it´s hell, but I´ll have a look!
> > 
> > Thank you for pointing me in the right direction!
> > 
> > /K
> > 
> > > 
> > > But passenger-recycler does something very simple - if the amount
> > > of
> > > "private resident RSS
> > > memory" is higher than specified amount in the configuration
> > > file,
> > > it
> > > kills the process.
> > > 
> > > You might get a much better monitoring on FreeBSD by monitoring
> > > the
> > > output of
> > > 
> > > procstat -v 
> > > 
> > > which will give you details about the memory usage of the process
> > > and
> > > see how it is growing
> > > over time. Maybe you can pinpoint the shared library that causes
> > > this, if you are lucky.
> 
> How do I interpret the output of 'procstat -v ' though? Can I
> sum
> up all of the RES or PRES numbers to get the total virtual memory
> that
> this process is consuming?

I hacked at it a bit and came up with an updated patch that includes
the changes you made, plus my own.

Since "private dirty RSS" isn´t available, I´ve used "maximum RSS" from
'procstat -r ', which is far from perfect, but it´s better than
nothing. It now runs and does what you´

Re: monitoring ruby app memory usage with passenger-recycler (was: Cannot require library for passenger in ruby)

2018-02-22 Thread Karli Sjöberg via freebsd-ports
On Thu, 2018-02-22 at 07:50 +0100, Karli Sjöberg via freebsd-ports
wrote:
> On Tue, 2018-02-20 at 21:31 +, Marcin Cieslak wrote:
> > On Mon, 19 Feb 2018, Karli Sjöberg wrote:
> > 
> > > > What is the tool you are trying to deploy? foreman_maintain?
> > 
> > Sorry, I was too quick. This foreman_main is used to
> > download/update
> > foreman
> > from RedHat Satellite servers, which is not what you want.
> 
> Well, I want the "foreman_maintain" package, which includes
> "passenger-
> recycler", so I guess I do want it :)
> 
> > 
> > However, the passenger-recycler script is a standalone script which
> > could possibly used with this little fix:
> 
> Ooh, awesome! Yeah, should´ve figured since it´s only at 0.1.3 :)
> 
> > 
> > https://github.com/theforeman/foreman_maintain/pull/143
> > 
> > To apply this, please add files/patch-bin_passenger-recycler in the
> > port I've sent before:
> > 
> > --- bin/passenger-recycler.orig 2018-02-20 21:09:18 UTC
> > +++ bin/passenger-recycler
> > @@ -41,10 +41,10 @@ def process_status?(pid)
> >  end
> >  
> >  require 'phusion_passenger'
> > +PhusionPassenger.locate_directories
> >  require 'phusion_passenger/platform_info'
> >  require 'phusion_passenger/platform_info/ruby'
> >  require 'phusion_passenger/admin_tools/memory_stats'
> > -PhusionPassenger.locate_directories
> >  stats = PhusionPassenger::AdminTools::MemoryStats.new
> >  unless stats.platform_provides_private_dirty_rss_information?
> >puts 'Please run as root or platform unsupported'
> 
> Yes, this works, thanks!
> 
> > 
> > 
> > But the real problem is that Passenger does think it supports
> > getting process private dirty RSS memory information only on Linux:
> > 
> > https://github.com/phusion/passenger/blob/219ad24159ae4033a342e6ad7
> > 53
> > cfee05d98bae0/src/ruby_supportlib/phusion_passenger/admin_tools/mem
> > or
> > y_stats.rb#L121
> > 
> > In file
> > src/ruby_supportlib/phusion_passenger/admin_tools/memory_stats.rb:
> > 
> > 120   def platform_provides_private_dirty_rss_information?
> > 121 return os_name_simple == "linux"
> > 122   end
> > 
> > This support probably would need to be written. So, unfortunately,
> > passenger-recycler
> > as written will exit with:
> > 
> > Please run as root or platform unsupported
> 
> Yes, I have now gotten to this stage at least, thank you very much! I
> don´t mind having a look at it, it might be simplest thing to write,
> or
> it´s hell, but I´ll have a look!
> 
> Thank you for pointing me in the right direction!
> 
> /K
> 
> > 
> > But passenger-recycler does something very simple - if the amount
> > of
> > "private resident RSS
> > memory" is higher than specified amount in the configuration file,
> > it
> > kills the process.
> > 
> > You might get a much better monitoring on FreeBSD by monitoring the
> > output of
> > 
> > procstat -v 
> > 
> > which will give you details about the memory usage of the process
> > and
> > see how it is growing
> > over time. Maybe you can pinpoint the shared library that causes
> > this, if you are lucky.

How do I interpret the output of 'procstat -v ' though? Can I sum
up all of the RES or PRES numbers to get the total virtual memory that
this process is consuming?

/K

> > 
> > Marcin

signature.asc
Description: This is a digitally signed message part


Re: monitoring ruby app memory usage with passenger-recycler (was: Cannot require library for passenger in ruby)

2018-02-21 Thread Karli Sjöberg via freebsd-ports
On Tue, 2018-02-20 at 21:31 +, Marcin Cieslak wrote:
> On Mon, 19 Feb 2018, Karli Sjöberg wrote:
> 
> > > What is the tool you are trying to deploy? foreman_maintain?
> 
> Sorry, I was too quick. This foreman_main is used to download/update
> foreman
> from RedHat Satellite servers, which is not what you want.

Well, I want the "foreman_maintain" package, which includes "passenger-
recycler", so I guess I do want it :)

> 
> However, the passenger-recycler script is a standalone script which
> could possibly used with this little fix:

Ooh, awesome! Yeah, should´ve figured since it´s only at 0.1.3 :)

> 
> https://github.com/theforeman/foreman_maintain/pull/143
> 
> To apply this, please add files/patch-bin_passenger-recycler in the
> port I've sent before:
> 
> --- bin/passenger-recycler.orig 2018-02-20 21:09:18 UTC
> +++ bin/passenger-recycler
> @@ -41,10 +41,10 @@ def process_status?(pid)
>  end
>  
>  require 'phusion_passenger'
> +PhusionPassenger.locate_directories
>  require 'phusion_passenger/platform_info'
>  require 'phusion_passenger/platform_info/ruby'
>  require 'phusion_passenger/admin_tools/memory_stats'
> -PhusionPassenger.locate_directories
>  stats = PhusionPassenger::AdminTools::MemoryStats.new
>  unless stats.platform_provides_private_dirty_rss_information?
>puts 'Please run as root or platform unsupported'

Yes, this works, thanks!

> 
> 
> But the real problem is that Passenger does think it supports
> getting process private dirty RSS memory information only on Linux:
> 
> https://github.com/phusion/passenger/blob/219ad24159ae4033a342e6ad753
> cfee05d98bae0/src/ruby_supportlib/phusion_passenger/admin_tools/memor
> y_stats.rb#L121
> 
> In file
> src/ruby_supportlib/phusion_passenger/admin_tools/memory_stats.rb:
> 
> 120   def platform_provides_private_dirty_rss_information?
> 121 return os_name_simple == "linux"
> 122   end
> 
> This support probably would need to be written. So, unfortunately,
> passenger-recycler
> as written will exit with:
> 
>   Please run as root or platform unsupported

Yes, I have now gotten to this stage at least, thank you very much! I
don´t mind having a look at it, it might be simplest thing to write, or
it´s hell, but I´ll have a look!

Thank you for pointing me in the right direction!

/K

> 
> But passenger-recycler does something very simple - if the amount of
> "private resident RSS
> memory" is higher than specified amount in the configuration file, it
> kills the process.
> 
> You might get a much better monitoring on FreeBSD by monitoring the
> output of
> 
> procstat -v 
> 
> which will give you details about the memory usage of the process and
> see how it is growing
> over time. Maybe you can pinpoint the shared library that causes
> this, if you are lucky.
> 
> Marcin

signature.asc
Description: This is a digitally signed message part


Re: Cannot require library for passenger in ruby

2018-02-21 Thread Karli Sjöberg via freebsd-ports
On Tue, 2018-02-20 at 20:26 +, Marcin Cieslak wrote:
> On Mon, 19 Feb 2018, Karli Sjöberg wrote:
> 
> > > What is the tool you are trying to deploy? foreman_maintain?
> 
> Can you try the port below? Unfortunately I do not see how
> foreman_maintain may fix your passenger
> installation issues, but here it is:

No, you´re right, it didn´t fix the issue:
# /usr/local/bin/passenger-recycler 
/usr/local/lib/ruby/gems/2.4/gems/foreman_maintain-0.1.3/bin/passenger-recycler:10:
 warning: already initialized constant CONFIG
/usr/local/lib/ruby/gems/2.4/gems/foreman_maintain-0.1.3/bin/passenger-recycler:8:
 warning: previous definition of CONFIG was here
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`require': cannot load such file -- /phusion_passenger/utils/tmpio (LoadError)
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`rescue in require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:39:in 
`require'
from 
/usr/local/lib/ruby/gems/2.4/gems/passenger-5.1.12/src/ruby_supportlib/phusion_passenger.rb:240:in
 `require_passenger_lib'
from 
/usr/local/lib/ruby/gems/2.4/gems/passenger-5.1.12/src/ruby_supportlib/phusion_passenger/platform_info.rb:26:in
 `'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:70:in 
`require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:70:in 
`require'
from 
/usr/local/lib/ruby/gems/2.4/gems/foreman_maintain-0.1.3/bin/passenger-recycler:44:in
 `'
from /usr/local/bin/passenger-recycler:23:in `load'
from /usr/local/bin/passenger-recycler:23:in `'

But the port worked, so good job on that! :)

I get the feeling that the installed binaries are fine, it´s
something else, something more basic with passenger, since it bombs at
just trying to load a library that is included directly in the rubygem-
passenger package.

Does anyone have a clue here?

/K

> 
> # This is a shell archive.  Save it in a file, remove anything before
> # this line, and then unpack it by entering "sh file".  Note, it may
> # create directories; files and directories will be owned by you and
> # have default permissions.
> #
> # This archive contains:
> #
> # rubygem-foreman_maintain
> # rubygem-foreman_maintain/Makefile
> # rubygem-foreman_maintain/distinfo
> # rubygem-foreman_maintain/pkg-descr
> #
> echo c - rubygem-foreman_maintain
> mkdir -p rubygem-foreman_maintain > /dev/null 2>&1
> echo x - rubygem-foreman_maintain/Makefile
> sed 's/^X//' >rubygem-foreman_maintain/Makefile <<
> '15090155e0ad279a3a88902efd75aea3'
> X# $FreeBSD: head/devel/rubygem-foreman/Makefile 448125 2017-08-17
> 15:05:14Z sunpoet $
> X
> XPORTNAME=foreman_maintain
> XPORTVERSION= 0.1.3
> XCATEGORIES=  devel rubygems
> XMASTER_SITES=RG
> X
> XMAINTAINER=  r...@freebsd.org
> XCOMMENT= Facility to keep Foreman/Satellite services running
> X
> XRUN_DEPENDS= rubygem-clamp>0:devel/rubygem-clamp \
> X rubygem-highline>0:devel/rubygem-highline \
> X rubocop:devel/rubygem-rubocop \
> X pry:devel/rubygem-pry
> X
> XNO_ARCH= yes
> XUSES=gem shebangfix
> XUSE_RUBY=yes
> X
> XPLIST_FILES= bin/foreman-maintain bin/passenger-recycler
> X
> XSHEBANG_FILES=   ${PLIST_FILES}
> X
> X.include 
> 15090155e0ad279a3a88902efd75aea3
> echo x - rubygem-foreman_maintain/distinfo
> sed 's/^X//' >rubygem-foreman_maintain/distinfo <<
> 'b2bf4dcb1a0a898485a2b273846fd43e'
> XTIMESTAMP = 1519156673
> XSHA256 (rubygem/foreman_maintain-0.1.3.gem) =
> 35f10c7df685072de50f515bfe5c694791d01f5d2eb2ef02c32b693f7e68f73b
> XSIZE (rubygem/foreman_maintain-0.1.3.gem) = 58880
> b2bf4dcb1a0a898485a2b273846fd43e
> echo x - rubygem-foreman_maintain/pkg-descr
> sed 's/^X//' >rubygem-foreman_maintain/pkg-descr <<
> '9944d73c5ee733bda3fa3a0bea6fbf70'
> XA maintenance tool for Foreman/Satellite Ruby applications
> X
> XWWW: https://github.com/theforeman/foreman_maintain
> 9944d73c5ee733bda3fa3a0bea6fbf70
> exit

signature.asc
Description: This is a digitally signed message part


Re: Cannot require library for passenger in ruby

2018-02-19 Thread Karli Sjöberg via freebsd-ports
On Mon, 2018-02-19 at 07:50 +, Marcin Cieslak wrote:
> On Mon, 19 Feb 2018, Karli Sjöberg wrote:
> 
> > 
> > 
> > Den 18 feb. 2018 23:49 skrev Marcin Cieslak <sa...@saper.info>:
> >   On Sat, 17 Feb 2018, Karli Sjöberg via freebsd-ports wrote:
> >   CONFIG
> >   > /usr/local/lib/ruby/gems/2.4/gems/foreman_maintain-
> > 0.1.3/bin/passenger-recycler:8: warning: previous definition of
> > CONFIG
> >was here
> >   >
> > /usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.
> > rb:135:in `require': cannot load such file --
> >   /phusion_passenger/utils/tmpio (LoadError)
> >   > from
> > /usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.
> > rb:135:in `rescue in require'
> >   > from
> > /usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.
> > rb:39:in `require'
> >   > from /usr/local/lib/ruby/gems/2.4/gems/passenger-
> > 5.2.0/src/ruby_supportlib/phusion_passenger.rb:240:in
> >   `require_passenger_lib'
> >   > from /usr/local/lib/ruby/gems/2.4/gems/passenger-
> > 5.2.0/src/ruby_supportlib/phusion_passenger/platform_info.rb:26:in
> >   `'
> > 
> >   Where did you get passenger 5.2.0?
> > 
> >   Can you try to install passenger 5.1.12 from ports and see if
> > it works better?
> > 
> > 
> > Right, yeah, no, I started with 5.1.12 from ports and when it
> > didn't work, I installed a newer version with 'gem'. I can
> > deinstall it
> > again if you want to see the backtrace?
> 
> Would be good, please. 

irb(main):001:0> require 'phusion_passenger'
=> true
irb(main):002:0> PhusionPassenger.require_passenger_lib 'utils/tmpio'
LoadError: cannot load such file -- /phusion_passenger/utils/tmpio
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`rescue in require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:39:in 
`require'
from 
/usr/local/lib/ruby/gems/2.4/gems/passenger-5.1.12/src/ruby_supportlib/phusion_passenger.rb:240:in
 `require_passenger_lib'
from (irb):2
from /usr/local/bin/irb:11:in `'
irb(main):003:0> require 'phusion_passenger/utils/tmpio'
=> true

> I wonder how many passenger dependencies got installed via rubygems -
> would be good to
> have them restored, too. 

None, that I could see.

> What is the tool you are trying to deploy? foreman_maintain?

Exactly!

/K

> 
> Marcin

signature.asc
Description: This is a digitally signed message part


Re: Cannot require library for passenger in ruby

2018-02-18 Thread Karli Sjöberg via freebsd-ports

___
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"


Cannot require library for passenger in ruby

2018-02-17 Thread Karli Sjöberg via freebsd-ports
Hey all!

My hope for this email is that someone will give me a smack in the
right direction, like 'You´re holding it wrong!'  and that´ll be that,
but you never know...

So the background story of it all is that I have a Foreman server that
is eating all of my RAM, basically no matter how much I give it. I´ve
written to the devs and they say it´s wrong, it shouldn´t be doing
that, it´s not a feature :) So they gave me a ruby script that fires
from cron every 5 mins that checks if there are any passenger processes
that are going bananas and kills them. It´s not a cure, just a
workaround, but it´s going to give some breathing room for diagnosing
the root cause in the mean time. Problem is, I can´t get it running!

/usr/local/lib/ruby/gems/2.4/gems/foreman_maintain-0.1.3/bin/passenger-recycler:10:
 warning: already initialized constant CONFIG
/usr/local/lib/ruby/gems/2.4/gems/foreman_maintain-0.1.3/bin/passenger-recycler:8:
 warning: previous definition of CONFIG was here
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`require': cannot load such file -- /phusion_passenger/utils/tmpio (LoadError)
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`rescue in require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:39:in 
`require'
from 
/usr/local/lib/ruby/gems/2.4/gems/passenger-5.2.0/src/ruby_supportlib/phusion_passenger.rb:240:in
 `require_passenger_lib'
from 
/usr/local/lib/ruby/gems/2.4/gems/passenger-5.2.0/src/ruby_supportlib/phusion_passenger/platform_info.rb:26:in
 `'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:70:in 
`require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:70:in 
`require'
from 
/usr/local/lib/ruby/gems/2.4/gems/foreman_maintain-0.1.3/bin/passenger-recycler:44:in
 `'
from /usr/local/bin/passenger-recycler:23:in `load'
from /usr/local/bin/passenger-recycler:23:in `'

It tries to load standard passenger library in
'phusion_passenger/platform_info.rb' and fails, so it stopped. The line
looks like this:
PhusionPassenger.require_passenger_lib 'utils/tmpio'

The thing is, I can´t 'require' any modules that way, at all:
irb(main):001:0> require 'phusion_passenger'
=> true
irb(main):003:0> PhusionPassenger.require_passenger_lib 'utils/json'
LoadError: cannot load such file -- /phusion_passenger/utils/json
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`rescue in require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:39:in 
`require'
from 
/usr/local/lib/ruby/gems/2.4/gems/passenger-5.2.0/src/ruby_supportlib/phusion_passenger.rb:240:in
 `require_passenger_lib'
from (irb):3
from /usr/local/bin/irb:11:in `'
irb(main):011:0* PhusionPassenger.require_passenger_lib 'utils/lock'
LoadError: cannot load such file -- /phusion_passenger/utils/lock
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`rescue in require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:39:in 
`require'
from 
/usr/local/lib/ruby/gems/2.4/gems/passenger-5.2.0/src/ruby_supportlib/phusion_passenger.rb:240:in
 `require_passenger_lib'
from (irb):11
from /usr/local/bin/irb:11:in `'
irb(main):012:0> PhusionPassenger.require_passenger_lib 'utils/tmpio'
LoadError: cannot load such file -- /phusion_passenger/utils/tmpio
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:135:in 
`rescue in require'
from 
/usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:39:in 
`require'
from 
/usr/local/lib/ruby/gems/2.4/gems/passenger-5.2.0/src/ruby_supportlib/phusion_passenger.rb:240:in
 `require_passenger_lib'
from (irb):12
from /usr/local/bin/irb:11:in `'

Although just requiring it isn´t a problem:
irb(main):014:0> require 'phusion_passenger/utils/tmpio'
=> true

I am at a complete loss as how to diagnose this further, hoping someone
can help me solve this problem.

Thanks in advance!
/K
___
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: libimobiledevice, ssl and "Failed to connect to lockdownd service on the device"

2017-09-22 Thread Karli Sjöberg via freebsd-ports
On ons, 2017-09-20 at 13:53 -0400, Steve wrote:
>  > I'm trying to mount my iPhone (SE) with fuse to copy all photos
>  > and videos to my FreeBSD machine. Installed sysutils/fusefs-ifuse
>  > and started usbmuxd (when the phone is unlocked, as instructed).
> All
>  > daemons run as expected etc., but running "ifuse -o allow_other
>  > /mnt/iphone" results in an error:
>  > "Failed to connect to lockdownd service on the device".
> 
>  > After some searching it seems that libimobiledevice should be
> build
>  > with OpenSSL instead of GnuTLS. But in the ports this is not a
>  > buildoption.
> 
>  > So is it possible to build libimobiledevice with OpenSSL? Or does
>  > anyone know if there is something else going on?

I know a lot of people are hit by this, it even prompted my mom to
switch to a Nexus phone, that´s how disregarded this is :) Not that I´m
complaining.

https://bugs.launchpad.net/ubuntu/+source/libimobiledevice/+bug/1623666

/K

> 
> 
> The version of libimobiledevice in ports (1.2.0) is a couple of
> years old. The upstream project has done a lot of work on it in
> the interim but for some reason has not released a new official
> version. If you want to use it with any recent version of iOS,
> your best bet is probably to grab the development sources from
> github and build it (and its prereqs) from them.
> 
> When I did this a few months ago, it required a bit of tweaking.
> If you're interested, I could collate my notes and send them
> to you.
> 
> I found the new version to be much better behaved than 1.2.0
> although transfers of large numbers of photos would still lock
> up at times. I found that the reliability improved considerably
> if I ran idevicesyslog in another window and let it spew the
> constant stream of syslog noise from the phone. I have no idea
> what the deal is with that but if someone can explain it, I'd
> love to know of a better solution.
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.o
> rg"
___
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: gettextsetup warnings

2017-09-19 Thread Karli Sjöberg via freebsd-ports
On ons, 2017-09-20 at 00:47 +0200, Romain Tartière wrote:
> Hello!
> 
> On Tue, Sep 19, 2017 at 09:09:59AM -0700, Zach wrote:
> > 
> > On Tue 19.Sep.17 17:28, Karli Sjöberg wrote:
> > > 
> > > Recently I've been noticing hundreds of these messages that
> > > SirDice reports in
> > > this thread on ask.puppet.com:
> > > https://ask.puppet.com/question/31933/gettextsetup-warnings/
> > Indeed, I was looking at this about an hour ago.
> > ;/
> I am missing the initial context so please forgive me if this is out
> of
> topic.
> 
> I guess this problem is partly fixed with the update to 5.2.0, not in
> the Ports tree yet (for sysutils/puppet5).  I just found a few more
> problems, I will try to address them tomorrow before leaving to
> EuroBSDcon.  
> 
> There where a few problems:
>   - The locales are installed in a weird location
> (/usr/local/share/locale would be more usual than
> /var/puppet/share/locales);
>   - Some files should not be installed into this directory
> (/var/puppet/share/locales/config.yaml and
> /var/puppet/share/locales/puppet.pot as far as I understand).
> 
> However:
>   1. The locales directory itself has not the usual layout (e.g. no
>  LC_MESSAGES subdirectory);
>   2. The installed files are not the good ones (.po instead of .mo)
>   3. I was not able to switch language by setting LC_ALL / LANG to
>  Japanese (the only locale that is currently installed).
> 
> As I said in the beginning I found a few more problems, and points 2
> and
> 3 seems to be fixed with some efforts.  I'll try to integrated this
> in
> the puppet5 port in the GitHub repo!
> 
> Regards,
> Romain

Thank you both for the awesome response, two people working on this
problem are definitely more than zero :)

@Zach
So it seems to me that if you two just talk this through after Romain
makes his fixes into "sysutils/puppet5", you can grap those and put
them into "sysutils/puppetserver", right?

/K
___
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"

gettextsetup warnings

2017-09-19 Thread Karli Sjöberg via freebsd-ports

___
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: Bug report assistance

2017-05-15 Thread Karli Sjöberg via freebsd-ports
On Mon, 2017-05-15 at 13:16 +0200, Kurt Jaeger wrote:
> Hi!
> 
> > I would like to know what I can do to help progress a bug report
> > further. I have had my eyes on bug 212420 for four months now, and
> > proposed a solution about two months ago but I haven't gotten any
> > responses back so far.
> > 
> > What can I do, more than adding to the bug report (that no one
> > seems to
> > read), to help resolve this bug report?
> 
> Posting here helps. And yes, the changes you propose are complex,
> so the number of committers able to work on that is smaller.
> 
> If I find a quiet hour, I'll have a look but I can not
> promise anything.
> 

Thank you Kurt, I appreciate it!

/K
___
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"


Bug report assistance

2017-05-15 Thread Karli Sjöberg via freebsd-ports
Hey all!

I would like to know what I can do to help progress a bug report
further. I have had my eyes on bug 212420 for four months now, and
proposed a solution about two months ago but I haven´t gotten any
responses back so far.

What can I do, more than adding to the bug report (that no one seems to
read), to help resolve this bug report?

Thanks in advance!
Karli Sjöberg
___
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"

===> $1 depends on executable: $1 - not found

2017-02-02 Thread Karli Sjöberg
Hello!

(Sent this mail out yesterday but saw that our exchange server had
base64 encoded it, so trying again with my gmail account.)

This is concerning PR 212420. I want to test making new ports for
rubygems sinatra, rack-protection and mustermann, where the existing
ports have lower versions, and I´d like to have them with a higher
version number. Kind of like 'ruby22' vs. 'ruby23'.

I have taken copies of the existing ports, modified them to match the
new versions and made sure to edit to size and hash in their 'distinfo'
files.

'rubygem-mustermann1' and 'rubygem-rack-protection2' (as I have called
them) both build OK but 'rubygem-sinatra2' does not, and I can´t figure
out what the problem is. This is what the error looks like building
with poudriere:
===
===>   rubygem-sinatra2-2.0.0.beta2 depends on package: rubygem-
rack>=2.0 - not found
===>   Installing existing package /packages/All/rubygem-rack-
2.0.1,3.txz
[release103amd64-default-job-01] Installing rubygem-rack-2.0.1,3...
[release103amd64-default-job-01] Extracting rubygem-rack-2.0.1,3:
.. done
===>   rubygem-sinatra2-2.0.0.beta2 depends on package: rubygem-
rack>=2.0 - found
===>   Returning to build of rubygem-sinatra2-2.0.0.beta2
===>   rubygem-sinatra2-2.0.0.beta2 depends on executable: rubygem-
rack-protection2 - not found
===>   Installing existing package /packages/All/rubygem-rack-
protection2-2.0.0.beta2.txz
[release103amd64-default-job-01] Installing rubygem-rack-protection2-
2.0.0.beta2...
[release103amd64-default-job-01] Extracting rubygem-rack-protection2-
2.0.0.beta2: .. done
===>   rubygem-sinatra2-2.0.0.beta2 depends on executable: rubygem-
rack-protection2 - not found
*** Error code 1

Stop.

This is what my 'rubygem-sinatra2' Makefile looks like:
##
PORTNAME=   sinatra
PORTVERSION=2.0.0.beta2
CATEGORIES= www rubygems
MASTER_SITES=   RG
PKGNAMESUFFIX=  2

MAINTAINER= r...@freebsd.org
COMMENT=Classy web development framework in ruby

LICENSE=MIT
LICENSE_FILE=   ${WRKSRC}/LICENSE

RUN_DEPENDS=rubygem-rack>=2.0:www/rubygem-rack \
rubygem-rack-protection2:www/rubygem-rack-protection2 \
mustermann:devel/rubygem-mustermann1 \
rubygem-tilt>=2.0:devel/rubygem-tilt

NO_ARCH=yes
USE_RUBY=   yes
USES=   gem

.include 
##

The other ports are made in a similar fashion. This is my first attempt
at making ports so please excuse my ignorance, but I believe I have
studied how other "suffix" packages look like, "rubygem-rack1{4,5,6}
e.g. and it feels like this should work. I have tried several different
formats to it's RUN_DEPENDS, like:
rubygem-rack-protection2:www/rubygem-rack-protection2
rubygem-rack-protection:www/rubygem-rack-protection2
rack-protection2:www/rubygem-rack-protection2
rack-protection:www/rubygem-rack-protection2

The error is always the same.

What am I missing here? Why does it find and install the package I´ve
made, and still won´t accept it´s there?

PS. Please make sure to CC me directly as I´m not registered to this
list.

Best Regards
Karli Sjöberg
___
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"

===> $1 depends on executable: $1 - not found

2017-02-02 Thread Karli Sjöberg
Hello!

This is concerning PR 212420. I want to test making new ports for
rubygems sinatra, rack-protection and mustermann, where the existing
ports have lower versions, and I´d like to have them with a higher
version number. Kind of like 'ruby22' vs. 'ruby23'.

I have taken copies of the existing ports, modified them to match the
new versions and made sure to edit to size and hash in their 'distinfo'
files.

'rubygem-mustermann1' and 'rubygem-rack-protection2' (as I have called
them) both build OK but 'rubygem-sinatra2' does not, and I can´t figure
out what the problem is. This is what the error looks like building
with poudriere:
===
===>   rubygem-sinatra2-2.0.0.beta2 depends on package: rubygem-rack>=2.0 - not 
found
===>   Installing existing package /packages/All/rubygem-rack-2.0.1,3.txz
[release103amd64-default-job-01] Installing rubygem-rack-2.0.1,3...
[release103amd64-default-job-01] Extracting rubygem-rack-2.0.1,3: .. 
done
===>   rubygem-sinatra2-2.0.0.beta2 depends on package: rubygem-rack>=2.0 - 
found
===>   Returning to build of rubygem-sinatra2-2.0.0.beta2
===>   rubygem-sinatra2-2.0.0.beta2 depends on executable: 
rubygem-rack-protection2 - not found
===>   Installing existing package 
/packages/All/rubygem-rack-protection2-2.0.0.beta2.txz
[release103amd64-default-job-01] Installing 
rubygem-rack-protection2-2.0.0.beta2...
[release103amd64-default-job-01] Extracting 
rubygem-rack-protection2-2.0.0.beta2: .. done
===>   rubygem-sinatra2-2.0.0.beta2 depends on executable: 
rubygem-rack-protection2 - not found
*** Error code 1

Stop.

This is what my 'rubygem-sinatra2' Makefile looks like:
##
PORTNAME=   sinatra
PORTVERSION=2.0.0.beta2
CATEGORIES= www rubygems
MASTER_SITES=   RG
PKGNAMESUFFIX=  2

MAINTAINER= r...@freebsd.org
COMMENT=Classy web development framework in ruby

LICENSE=MIT
LICENSE_FILE=   ${WRKSRC}/LICENSE

RUN_DEPENDS=rubygem-rack>=2.0:www/rubygem-rack \
rubygem-rack-protection2:www/rubygem-rack-protection2 \
mustermann:devel/rubygem-mustermann1 \
rubygem-tilt>=2.0:devel/rubygem-tilt

NO_ARCH=yes
USE_RUBY=   yes
USES=   gem

.include 
##

The other ports are made in a similar fashion. This is my first attempt
at making ports so please excuse my ignorance, but I believe I have
studied how other "suffix" packages look like, "rubygem-rack1{4,5,6}
e.g. and it feels like this should work. I have tried several different
formats to it's RUN_DEPENDS, like:
rubygem-rack-protection2:www/rubygem-rack-protection2
rubygem-rack-protection:www/rubygem-rack-protection2
rack-protection2:www/rubygem-rack-protection2
rack-protection:www/rubygem-rack-protection2

The error is always the same.

What am I missing here? Why does it find and install the package I´ve
made, and still won´t accept it´s there?

Best Regards
Karli Sjöberg
___
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 Port: smartmontools-6.2_2

2014-03-20 Thread Karli Sjöberg
Hi,

I´m sending this email to you because you are listed as maintainer of
the 'smartmontools' port.

I´ve been using smart daemon for long time but I´ve never been able to
use 'daily_status_smart_devices=auto' in '/etc/periodic.conf' because
there are USB drives attached and smartctl can´t handle them, at least
not by default:
# camcontrol devlist
ATA ST3000DM001-1CH1 CC24at scbus0 target 0 lun 0 (da0,pass0)
ATA ST3000DM001-1CH1 CC24at scbus0 target 1 lun 0 (da1,pass1)
ATA ST3000DM001-1CH1 CC24at scbus0 target 2 lun 0 (da2,pass2)
ATA ST3000DM001-1CH1 CC24at scbus0 target 3 lun 0 (da3,pass3)
ATA WDC WD30EFRX-68E 0A80at scbus0 target 5 lun 0 (pass4,da4)
Kingston DT Micro 1.00   at scbus6 target 0 lun 0 (da5,pass5)
Kingston DT Micro 1.00   at scbus7 target 0 lun 0 (da6,pass6)
# smartctl -H /dev/da5; echo $?
smartctl 6.2 2014-02-18 r3874 [FreeBSD 9.2-RELEASE amd64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

/dev/da5: Unknown USB bridge [0x0951:0x168a (0x100)]
Please specify device type with the -d option.

Use smartctl -h to get a usage summary

1

So I´ve been looking at '/usr/local/etc/periodic/daily/smart', thinking
about a smart way to sort that out:) So if the script was to loop
through the disks in sysctl -n kern.disks | sed -E 's/[[::]](cd|
ar)[0-9]+//g' and compare with 'camcontrol devlist' for known types of
hard drives like ATA, SAS and SCSI to determine if it´s a real hard
drive or not, that would fix the problem. It could also have support for
recognizing virtual qemu hard drives because they too show up in 'sysctl
-n kern.disks'. Who knows, maybe smartctl will support that as well in
the future:) And then I made a patch that does that.

smart.patch 
--- smart.orig  2014-03-20 09:50:36.495362586 +0100
+++ smart.new   2014-03-20 10:34:49.775232517 +0100
@@ -16,7 +16,19 @@
 case ${daily_status_smart_devices} in
# XXX AUTO mode selects only regular ad/da disks 
[Aa][Uu][Tt][Oo])
-   daily_status_smart_devices=$(sysctl -n kern.disks | sed -E 
's/[[::]](cd|ar)[0-9]+//g')
+# Filter out USB drives as well
+for DISK in $(sysctl -n kern.disks | sed -E 
's/[[::]](cd|ar)[0-9]+//g'); do
+  HDD=$(camcontrol devlist | egrep \(${DISK},|,${DISK}\) | 
egrep '(ATA|SAS|SCSI|QEMU HARDDISK)' | awk 'END{print NR}')
+  if [ ${HDD} -ne 0 ]; then
+HDDS=${HDDS} ${DISK}
+  else
+DEVICE_NUMBER=$(echo ${DISK} | awk '{gsub(/[a-zA-Z]/, ); 
print}')
+if [ $(grep vtblk${DEVICE_NUMBER} /var/run/dmesg.boot | 
awk 'END{print NR}') -ne 0 ]; then
+  HDDS=${HDDS} ${DISK}
+fi
+  fi
+done
+daily_status_smart_devices=$(echo ${HDDS} | sed 's/^ //')
;;
*)  ;;
 esac

If you like it, please consider using it for the port and I would
finally be able to just say auto without having any issues with my USB
drives any more. The patch is also included as an attachment.

TIA
Karli Sjöberg
--- smart.orig	2014-03-20 09:50:36.495362586 +0100
+++ smart.new	2014-03-20 10:34:49.775232517 +0100
@@ -16,7 +16,19 @@
 case ${daily_status_smart_devices} in
 	# XXX AUTO mode selects only regular ad/da disks 
 	[Aa][Uu][Tt][Oo])
-		daily_status_smart_devices=$(sysctl -n kern.disks | sed -E 's/[[::]](cd|ar)[0-9]+//g')
+# Filter out USB drives as well
+for DISK in $(sysctl -n kern.disks | sed -E 's/[[::]](cd|ar)[0-9]+//g'); do
+  HDD=$(camcontrol devlist | egrep \(${DISK},|,${DISK}\) | egrep '(ATA|SAS|SCSI|QEMU HARDDISK)' | awk 'END{print NR}')
+  if [ ${HDD} -ne 0 ]; then
+HDDS=${HDDS} ${DISK}
+  else
+DEVICE_NUMBER=$(echo ${DISK} | awk '{gsub(/[a-zA-Z]/, ); print}')
+if [ $(grep vtblk${DEVICE_NUMBER} /var/run/dmesg.boot | awk 'END{print NR}') -ne 0 ]; then
+  HDDS=${HDDS} ${DISK}
+fi
+  fi
+done
+daily_status_smart_devices=$(echo ${HDDS} | sed 's/^ //')
 		;;
 	*)	;;
 esac
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: RFE - FreeBSD Port: zfs-snapshot-mgmt-20090201_2

2012-06-29 Thread Karli Sjöberg
Thanks, that was fast!

# patch /usr/local/bin/zfs-snapshot-mgmt zfs-snapshot-mgmt.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|--- zfs-snapshot-mgmt 2010-06-02 05:31:28.759931924 +0300
|+++ zfs-snapshot-mgmt 2010-06-01 01:49:46.665034414 +0300
--
Patching file /usr/local/bin/zfs-snapshot-mgmt using Plan A...
patch:  malformed patch at line 12: @name).readlines.collect.select { 
|item| item[0, @name.length + 1] == @name +


OK, so that didn´t go that well. Manually editing the script to what I think 
you ment:

/usr/local/bin/zfs-snapshot-mgmt:
#  def snapshots(prefix)
#path = File.join(@mount_point, '.zfs', 'snapshot')
#Dir.open(path).select do |name|
#  name[0, prefix.length] == prefix
#end.map { |name| SnapshotInfo.new(name, @name, prefix) }
#  end

#path = File.join(@mount_point, '.zfs', 'snapshot')
#Dir.open(path).select do |name|
s = IO.popen('zfs list -r -t snapshot -H -o name 
'@name).readlines.collect.select { |item| item[0, @name.length + 1] == @name 
'@' }.map { |item| item[@name.length + 1 .. -1] }
s.select do |name|
  name[0, prefix.length] == prefix
end.map { |name| SnapshotInfo.new(name, @name, prefix) }
  end


But recieves from cron:
/usr/local/bin/zfs-snapshot-mgmt:138: syntax error, unexpected tIVAR, expecting 
')'
... -t snapshot -H -o name '@name).readlines.collect.select { |...
 ^
/usr/local/bin/zfs-snapshot-mgmt:138: syntax error, unexpected tSTRING_BEG, 
expecting '}'
..., @name.length + 1] == @name '@' }.map { |item| item[@name.l...
 ^
/usr/local/bin/zfs-snapshot-mgmt:188: syntax error, unexpected kEND, expecting 
$end

/Karli

29 jun 2012 kl. 01.20 skrev Andriy Gapon:

on 28/06/2012 11:16 Karli Sjöberg said the following:
Hi!

I am a storage-technician working at the Swedish University of Agriculture and 
we are using zfs-snapshot-mgmt to create scheduled snapshots, but are failing 
on our disaster-recovery machine because of:

/usr/local/bin/zfs-snapshot-mgmt:130:in `join': can't convert nil into String 
(TypeError)
from /usr/local/bin/zfs-snapshot-mgmt:130:in `snapshots'
from /usr/local/bin/zfs-snapshot-mgmt:137:in `snapshots_to_remove'
from /usr/local/bin/zfs-snapshot-mgmt:145:in `remove_snapshots'
from /usr/local/bin/zfs-snapshot-mgmt:213
from /usr/local/bin/zfs-snapshot-mgmt:210:in `each'
from /usr/local/bin/zfs-snapshot-mgmt:210

Now, since this is a disaster-recovery unit, I would rather not have to have 
all filesystems mounted for the script to function as we have many servers with 
many file systems backing up towards this unit, which would result in quite 
alot of mounts that are completely unnecessary to the backup server itself. I 
also consider it a potential security risk having all these file systems, from 
all of these different machines mounted in the same place(server). I mean, if 
someone would like to steal as much valuable data as possible, why crack 
hundreds of servers and steal it piece by piece when you could just crack one 
and have it all, right? That doesn´t really make sense because if someone were 
to crack the backup server they could just mount all filesystems themselves, 
but only if they knew they were there. But also having them mounted feels like 
just handing it to them.

Unfortunately I know nothing about programming so I can´t be of any help, 
besides testing patches, but do you think this can be done? Change the script 
so that it doesn´t require the file systems to be mounted for it to be able to 
take snapshots?

How about this?

--- zfs-snapshot-mgmt 2010-06-02 05:31:28.759931924 +0300
+++ zfs-snapshot-mgmt 2010-06-01 01:49:46.665034414 +0300
@@ -127,8 +127,10 @@
  end

  def snapshots(prefix)
-path = File.join(@mount_point, '.zfs', 'snapshot')
-Dir.open(path).select do |name|
+#path = File.join(@mount_point, '.zfs', 'snapshot')
+#Dir.open(path).select do |name|
+s = IO.popen('zfs list -r -t snapshot -H -o name ' +
@name).readlines.collect.select { |item| item[0, @name.length + 1] == @name +
'@' }.map { |item| item[@name.length + 1 .. -1] }
+s.select do |name|
  name[0, prefix.length] == prefix
end.map { |name| SnapshotInfo.new(name, @name, prefix) }
  end



--
Andriy Gapon




Med Vänliga Hälsningar
---
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone:  +46-(0)18-67 15 66
karli.sjob...@slu.semailto:karli.sjob...@adm.slu.se

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


RFE - FreeBSD Port: zfs-snapshot-mgmt-20090201_2

2012-06-28 Thread Karli Sjöberg
Hi!

I am a storage-technician working at the Swedish University of Agriculture and 
we are using zfs-snapshot-mgmt to create scheduled snapshots, but are failing 
on our disaster-recovery machine because of:

/usr/local/bin/zfs-snapshot-mgmt:130:in `join': can't convert nil into String 
(TypeError)
from /usr/local/bin/zfs-snapshot-mgmt:130:in `snapshots'
from /usr/local/bin/zfs-snapshot-mgmt:137:in `snapshots_to_remove'
from /usr/local/bin/zfs-snapshot-mgmt:145:in `remove_snapshots'
from /usr/local/bin/zfs-snapshot-mgmt:213
from /usr/local/bin/zfs-snapshot-mgmt:210:in `each'
from /usr/local/bin/zfs-snapshot-mgmt:210

Now, since this is a disaster-recovery unit, I would rather not have to have 
all filesystems mounted for the script to function as we have many servers with 
many file systems backing up towards this unit, which would result in quite 
alot of mounts that are completely unnecessary to the backup server itself. I 
also consider it a potential security risk having all these file systems, from 
all of these different machines mounted in the same place(server). I mean, if 
someone would like to steal as much valuable data as possible, why crack 
hundreds of servers and steal it piece by piece when you could just crack one 
and have it all, right? That doesn´t really make sense because if someone were 
to crack the backup server they could just mount all filesystems themselves, 
but only if they knew they were there. But also having them mounted feels like 
just handing it to them.

Unfortunately I know nothing about programming so I can´t be of any help, 
besides testing patches, but do you think this can be done? Change the script 
so that it doesn´t require the file systems to be mounted for it to be able to 
take snapshots?


Med Vänliga Hälsningar
---
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone:  +46-(0)18-67 15 66
karli.sjob...@slu.semailto:karli.sjob...@adm.slu.se

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