search for: jmiller

...nd separator = + winbind enum users = yes winbind enum groups = yes template shell = /bin/bash template homedir = /home/SOTS/%U [audio] comment = Audio Files valid users = @"SOTS+Domain Users" path = /tank/media/teachings/Audio write list = SOTS+sound,SOTS+jmiller,@"SOTS+Domain Admins",@"SOTS+Associate Admins" force user = data force group = users And here is the log file: [2007/08/03 12:55:07, 5] auth/auth_util.c:make_user_info_map(161) make_user_info_map: Mapping user [SOTS]\[jmiller] from workstation [MEDIA] [2007/...

...inbind separator = + winbind enum users = yes winbind enum groups = yes template shell = /bin/bash template homedir = /home/SOTS/%U [audio] comment = Audio Files valid users = @"SOTS+Domain Users" path = /tank/media/teachings/Audio write list = SOTS+sound,SOTS+jmiller,@"SOTS+Domain Admins",@"SOTS+Associate Admins" force user = data force group = users And here is the log file: [2007/08/03 12:55:07, 5] auth/auth_util.c:make_user_info_map(161) make_user_info_map: Mapping user [SOTS]\[jmiller] from workstation [MEDIA] [2007/08/...

Greetings all, In beginning my quest into puppet. I came across a situation I would like for puppet to handle in a specific way, but I''m not sure if the ability currently exists. I''ve read about the various workarounds and limits on the ''file'' element, when using it to create directory structures (in regards to parent dirs). With that said, I was thinking

If have a couple patches I found while looking at a panic I was seeing while unloading the nouveau module. Unloading the nouveau module on my optimus notebook machine causes the system to panic. This started occuring when moving from 4.4 to 4.14. These patches make it such that the system does not panic when unloading the module. 4.14 also requires commit 34112bf4935d ("drm/nouveau/fbcon:

...lready, so maybe we don't really need to test. On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul <lyude at redhat.com> wrote: > Remember, ida IDs start at 0, not 1! > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: stable at vger.kernel.org > Cc: Jeffery Miller <jmiller at neverware.com> > Cc: Karol Herbst <kherbst at redhat.com> > --- > drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_bac...

...it today. Will test your patches On Tue, Jul 17, 2018 at 12:46 PM, Karol Herbst <kherbst at redhat.com> wrote: > does this also happen with the newest kernel? I was kind of under the > impression we already fixed such issues. > > On Thu, Jul 5, 2018 at 9:09 PM, Jeffery Miller <jmiller at neverware.com> wrote: >> If have a couple patches I found while looking at a panic >> I was seeing while unloading the nouveau module. >> >> Unloading the nouveau module on my optimus notebook machine causes >> the system to panic. This started occuring when movi...

This series fixes some issues with nouveau's backlight support that were causing kernel panics on module reloads, specifically on systems with nouveau handling the backlight of one of the displays. While we're at it, let's cleanup nouveau_backlight.c as well Lyude Paul (5): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Move backlight device into

I like the Stanford Best Practices guide for puppet. One thing I didn''t see it address was handling of separate environments, for example Dev, Test, Staging, Production. My thoughts on this so far, are: brainstorm #1) Handle environment differences with metadata: node devProductName01 { $env = "dev" include ProductName-webserver } node testProductName01 {

does this also happen with the newest kernel? I was kind of under the impression we already fixed such issues. On Thu, Jul 5, 2018 at 9:09 PM, Jeffery Miller <jmiller at neverware.com> wrote: > If have a couple patches I found while looking at a panic > I was seeing while unloading the nouveau module. > > Unloading the nouveau module on my optimus notebook machine causes > the system to panic. This started occuring when moving from 4.4 > to...

Remember, ida IDs start at 0, not 1! Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: stable at vger.kernel.org Cc: Jeffery Miller <jmiller at neverware.com> Cc: Karol Herbst <kherbst at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c index 408b955e5c39.....

...9 df 5b 5d 41 5c e9 ed c4 ff ff 48 89 df e8 c5 c1 ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 f0 0d 24 82 e8 7f 44 e4 ff <0f> 0b 5b 5d 41 5c c3 0f 1f 84 00 00 00 00 00 48 85 f6 74 3 1 41 [ 202.510845] ---[ end trace acc8d2d94431d002 ]--- On Tue, Jul 17, 2018 at 5:21 PM, Jeffery Miller <jmiller at neverware.com> wrote: > On Tue, Jul 17, 2018 at 9:05 AM Karol Herbst <kherbst at redhat.com> wrote: >> >> nevermind, I just hit it today. Will test your patches >> >> On Tue, Jul 17, 2018 at 12:46 PM, Karol Herbst <kherbst at redhat.com> wrote: >>...

On F7, I get to where I have Postfix and Dovecot installed and configured, postfix check runs fine, but when I try to start Dovecot I'm getting a permission error. Here is the log entry: Dec 29 21:54:06 grp-01-50-90 dovecot: Dovecot v1.0.7 starting up Dec 29 21:54:06 grp-01-50-90 dovecot: Generating Diffie-Hellman parameters for the first time. This may take a while.. Dec 29 21:54:06

Hello, For some reason, I thought little about the "clear" command today.. Let's say a privileged user (root) logs on, edit a sensitive file (e.g, a file containing a password, running vipw, etc) .. then runs clear and logout. Then anyone can press the scroll-lock command, scroll back up and read the sensitive information.. Isn't "clear" ment to clear the

Next version of https://patchwork.freedesktop.org/series/48596/ . Made some important changes to the refactoring patch, but everything else is the same. Lyude Paul (5): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Move backlight device into nouveau_connector drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/ drm/nouveau: Cleanup indenting in

Next version of https://patchwork.freedesktop.org/series/48596/ . Added NV_INFO_ONCE and made "Move backlight device into nouveau_connector" use that instead so we don't print the GMUX warning more then once. Lyude Paul (5): drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau:

Forgot to send 6 patches instead of five since there's one new one now, whoops! No actual changes, next version of https://patchwork.freedesktop.org/series/48596/ Lyude Paul (6): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau:

Refactor for Ben, hopefully this time this should apply to his tree. Next version of https://patchwork.freedesktop.org/series/48596/ No changes otherwise. Lyude Paul (6): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau:

On Tue, Jul 17, 2018 at 9:05 AM Karol Herbst <kherbst at redhat.com> wrote: > > nevermind, I just hit it today. Will test your patches > > On Tue, Jul 17, 2018 at 12:46 PM, Karol Herbst <kherbst at redhat.com> wrote: > > does this also happen with the newest kernel? I was kind of under the > > impression we already fixed such issues. > > I applied those

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm having trouble getting my IVR to produce audio onto my cisco 7940 handset using SIP. I've got CentOS 4.3 running * 1.2.9.1 and the corresponding latest releases of libpri, zaptel, addons and sounds. I'm using two extensions to test that successfully dial each other and can talk back and forth fine. When I dial into the IVR, I get a

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I have an installation where I'll have a site to site data DS1 for use between two corporate offices. We'll have one asterisk server at each office. I'd like to be able to route calls over the 24 channels on that DS1 between the offices, instead of over the voiceT at each location to maximize savings on interoffice calls. An