[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Trond Norbye wrote: > Hi, > > The webrev thread for upgrading memcached 1.2.5 to 1.4.1 turned into a > discussion if we should use "-u" on the command line or > method_credentials in the SMF in order to specify the user to run as. > > I agree that using method_credentials (username and privileges

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Hi, The webrev thread for upgrading memcached 1.2.5 to 1.4.1 turned into a discussion if we should use "-u" on the command line or method_credentials in the SMF in order to specify the user to run as. I agree that using method_credentials (username and privileges) is the most secure way to do

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Chris Josephes wrote: >> The method we use here is the same method you'll find on pretty much all >> of the linux variants out there, so it really can't be that bad. And as >> I also said in another message: memcached is by design insecure and you >> should therefore _only_ run it in your private a

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

for the benefit of every one, I have filed CR: 6887577 to track this issue within memcached. Chris - thanks for taking time and reporting this issue. - sriram Trond Norbye wrote: > Hi, > > The webrev thread for upgrading memcached 1.2.5 to 1.4.1 turned into a > discussion if we should use "-u"

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Chris Josephes wrote: >> *I think this is a question of fully utilizing SMF security features, >> along with potentially maintaining patches to some of the open source >> code to bypass their own cross-platform security implementation, and >> needing to help users understand why our delivery of a f

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

>If this is a really big problem for you I suggest that you create a bug >report on the issue and use your support contract to escalate it. If you're the maintainer of the code, what's the point? You've made it pretty obvious that you have no intention of making any changes. -- This message poste

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

>The method we use here is the same method you'll find on pretty much all >of the linux variants out there, so it really can't be that bad. And as >I also said in another message: memcached is by design insecure and you >should therefore _only_ run it in your private and secure network. Consider

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Chris Josephes wrote: >> *I think this is a question of fully utilizing SMF security features, >> along with potentially maintaining patches to some of the open source >> code to bypass their own cross-platform security implementation, and >> needing to help users understand why our delivery of a f

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

>Exactly what is the _problem_ ? What are you not able to do with the >suggested approach? Your approach works. All I did was recommend a suggestion on how other SMF implementers would have done it, and I offered to contribute work. You're working from the angle of a memcache expert that isn't

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

>*I think this is a question of fully utilizing SMF security features, >along with potentially maintaining patches to some of the open source >code to bypass their own cross-platform security implementation, and >needing to help users understand why our delivery of a familiar server >is supposed to

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

On 30. sep.. 2009, at 17.24, Chris Josephes wrote: >> If Sun had developed new applications that ignored/violated >> conventions, >> that would indeed be a matter for concern. But importing third-party >> applications NOT developed to those guidelines seems to me a >> different >> matter. You

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

On 29. sep.. 2009, at 23.33, Chris Josephes wrote: >> To be serious, yes things could be done a bit differently but this >> solution requires the least architectural review and meets user needs >> without being too complicated. > > How does this change affect or add time to the architectural >

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Chris Josephes wrote: > And if Memcache does not properly fit into the guidelines of SMF, why did you > create a manifest in the first place? Why not just use a script in > /etc/rc3.d? > This same question* could apply to just about any of the Web Stack features. It should be obvious why S

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

[repost - it bounced yesterday] Chris Josephes wrote: >> To be serious, yes things could be done a bit differently but this >> solution requires the least architectural review and meets user needs >> without being too complicated. > > How does this change affect or add time to the architectur

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

>If Sun had developed new applications that ignored/violated conventions, >that would indeed be a matter for concern. But importing third-party >applications NOT developed to those guidelines seems to me a different >matter. You're asking for a retro-fit! I'm not asking for a retro-fit. I am aski

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Chris Josephes wrote: > Most people don't run memcached on a privileged port, but even if they wanted > to, the following method_context block in the manifest would accommodate that. > > > privileges='basic,!proc_session,!proc_info,!file_link

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Matt Ingenthron wrote: > Trond Norbye wrote: >> See: >> >> http://cr.opensolaris.org/~trond/webrev/ > > From the peanut gallery > > It generally looks good. I like the change to the default user of > noaccess. > > Having said that, I'd highly recommend adding some default options, > say "-L

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Chris Josephes wrote: > Actually, I don't understand why you're setting up memcache to run as a user > through the "-u" flag to the daemon. > > If you use a block, you accomplish the same thing, > only more securely. Also it's easier for an administrator to change which > user

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

>To be serious, yes things could be done a bit differently but this >solution requires the least architectural review and meets user needs >without being too complicated. How does this change affect or add time to the architectural review? Would it make sense for me to submit a proposal for a fu

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Most people don't run memcached on a privileged port, but even if they wanted to, the following method_context block in the manifest would accommodate that.

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Actually, I don't understand why you're setting up memcache to run as a user through the "-u" flag to the daemon. If you use a block, you accomplish the same thing, only more securely. Also it's easier for an administrator to change which user account they would prefer to run

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

See: http://cr.opensolaris.org/~trond/webrev/ Cheers, Trond

[webstack-discuss] webrev needed for upgrading memcached 1.2.5 to 1.4.1

Trond Norbye wrote: > See: > > http://cr.opensolaris.org/~trond/webrev/ From the peanut gallery It generally looks good. I like the change to the default user of noaccess. Having said that, I'd highly recommend adding some default options, say "-L -m 64". Why? On popular Linux distros t