[SOLVED] Requests for -current (20151216)

a4z · 06-10-2016, 11:01 AM

is there a reason why the huge kernel does not include the hyper-v features build in but only as modules?

this could be an impediment for Slackware on Azure :-)
no, seriously, it would be nice if huge kernel would just work on hyper-v without making a way around

dijetlo · 06-10-2016, 11:08 AM

Kernels load modules when they determine they are dealing with a workload that require it. That's not true just of the virtualization modules, all the linux kernel modules insert and extract in a dizzying maelstrom of functionality.
Not familiar with Azure (no worries, I'm not familiar with a lot of stuff) but what I'm referencing is widely known and unless it's just a virtualization platform for Microsoft (it's a microsoft product, right?) it will account for this process.

a4z · 06-10-2016, 11:26 AM

Quote:

Originally Posted by dijetlo

Kernels load modules when it determines it's dealing with a workload that requires it. That's not true just of the virtualization modules, all the linux kernel modules insert and extract in a dizzying maelstrom of functionality.

hm, but when you need a module to access the storage (hd), than auto loading on boot does not solve anything
so it would be nice to have at least the storage module in the kernel.

dijetlo · 06-10-2016, 11:28 AM

Which storage module? There are quite a few available to the kernel, and you don't want it to load them all.
That's why it waits for workload and configures in line.

If you know ahead of time you'll need a specific module (like the one that lets you mount a SAN and boot your instance) you build the module into the initramfs and then reference it when you boot the node however as soon as it comes out of initramfs it reverts back to the original system (insert/unload as needed). The module for sata/pata et al hard-drive is included in the initramfs by default so when the kernel detects workload (which can be a request to access a resource) it loads the driver and accesses the resource (the SAN, the Hard drive).

To clearly understand why it needs to be this way consider how many memory registers the kernel would require in it's heap to load every driver it has access to (tens of thousands). It would render processing times on the kernel unmanageable, it would probably end up running kernel code from swap, which isn't going to work no matter how fast your SSD is...

a4z · 06-10-2016, 11:49 AM

Quote:

Originally Posted by dijetlo

Which storage module? There are quite a few available to the kernel, and you don't want it to load them all.
That's why it waits for workload and configures in line.

If you know ahead of time you'll need a specific module (like the one that lets you mount a SAN and boot your instance) you build the module into the initramfs and then reference it when you boot the node however as soon as it comes out of initramfs it reverts back to the original system (insert/unload as needed). The module for sata/pata et al hard-drive is included in the initramfs by default so when the kernel detects workload (which can be a request to access a resource) it loads the driver and accesses the resource (the SAN, the Hard drive).

with 14.1 you can not boot Slackware after an installation, you need to use the Slackware CD, mount the hd, create an initrd, add it to lilo, than you can start to work.
I think this should not be required with the huge kernel.
checking the config of current it seems the required modules are still compiles as modules for the huge, I wounder what the reason for this is. I think it should just work and the 2 or 3 modules should be added to the huge kernel.

edit:
saw your edit to late. obviously you did ont get the question right. so please stop explaining things about memory registsters for the hyperv storage module, thanks

dijetlo · 06-10-2016, 12:10 PM

Quote:

with 14.1 you can not boot Slackware after an installation, you need to use the Slackware CD, mount the hd, create an initrd, add it to lilo, than you can start to work.

I never ran into that, though I generally just roll a platform and a couple of virtual machines along on current. I don't do nightly builds/deployments (by any stretch of the imagination) so I may have missed it.
RE: The contents of Huge:
I was editing my prior post while you were responding, sorry. I referenced memory management in the last paragraph, the only thing I'd add is to the best of my understanding it's not uncommon for a module to be "present" (i.e. in the initrd image) and available to the kernel however it's unloaded, i.e. not currently interacting with the kernel code, and as such producing no memory overhead or doing any work. The modules you want loaded by default, the intel and amd virtualization modules, are included in every linux kernel initrd for x86 architecture I'm familiar with, you just don't see them loaded unless their is a workload they are needed for.

edit:
OK so why don't I just explain this part to you. It's not slackwares kernel, take your issue up with Linus Torvalds.

GazL · 06-10-2016, 12:32 PM

Quote:

Originally Posted by nixi

I have noticed that vsftpd is not compatible with crypt() implementation in glibc 2.17 and newer. Please consider applying the following patch to vsftpd in Slackware to fix this issue.

Code:

--- vsftpd-3.0.2.orig/sysdeputil.c
+++ vsftpd-3.0.2/sysdeputil.c
@@ -285,7 +285,7 @@
         return 0;
       }
       p_crypted = crypt(str_getbuf(p_pass_str), p_spwd->sp_pwdp);
-      if (!vsf_sysutil_strcmp(p_crypted, p_spwd->sp_pwdp))
+      if (p_crypted && !vsf_sysutil_strcmp(p_crypted, p_spwd->sp_pwdp))
       {
         return 1;
       }
@@ -293,7 +293,7 @@
   }
   #endif /* VSF_SYSDEP_HAVE_SHADOW */
   p_crypted = crypt(str_getbuf(p_pass_str), p_pwd->pw_passwd);
-  if (!vsf_sysutil_strcmp(p_crypted, p_pwd->pw_passwd))
+  if (p_crypted && !vsf_sysutil_strcmp(p_crypted, p_pwd->pw_passwd))
   {
     return 1;
   }

Wouldn't the following be a better solution as the above still has the ability to fall-through to later code should crypt() return NULL:

Code:

p_crypted = crypt(str_getbuf(p_pass_str), p_spwd->sp_pwdp);
if ( !p_crypted )
  return 0;

if (!vsf_sysutil_strcmp(p_crypted, p_spwd->sp_pwdp))
  return 1;

Anyway, looks like this ought to be fixed upstream and not at the distro level.

volkerdi · 06-10-2016, 01:08 PM

Quote:

Originally Posted by GazL

Anyway, looks like this ought to be fixed upstream and not at the distro level.

Apparently it was nearly two years ago, but since it doesn't affect systems running PAM it hasn't been given much priority there.

https://forums.gentoo.org/viewtopic-...8-start-0.html

DarkVision · 06-11-2016, 01:04 AM

Question: The -current hplip package includes a /usr/lib/systemd directory. Is this directory required even if we do not use systemd? Same for the gvfs package.

ReaperX7 · 06-11-2016, 01:09 AM

DarkVision · 06-11-2016, 01:33 AM

Quote:

Originally Posted by ReaperX7

No.

Thanks. I'm already testing gvfs-1.28.2 for myself and while using "--disable-libsystemd-login" i do not get those systemd-files. Might be worth testing for the gvfs-1.26-package in -current. For hplib i could not find such an option. Will do some more testing...

kjhambrick · 06-11-2016, 02:24 AM

Quote:

Originally Posted by DarkVision

Question: The -current hplip package includes a /usr/lib/systemd directory. Is this directory required even if we do not use systemd? Same for the gvfs package.

Good question DarkVision.

I wondered the same thing but it can't hurt having them around, especially since they're all isolated in /usr/lib/systemd/{system,user}/ {?}

It's also interesting to see which apps run as background daemons ...

I still run wicd from /extra/ and it also has a /systemd/system/ entry.

I understand why wicd needs to run as a daemon.

OTOH, I installed evince as a dependency for some other SBo.

Why does a freakin' document viewer need to run as a daemon ?

This isn't Windows and evince isn't acrobat -- processes start quickly on Linux and I've never directly run evince !

Anyhow, this is on my reading list ... someday ...

-- kjh

kjhambrick · 06-11-2016, 03:01 AM

Quote:

Originally Posted by GazL

Wouldn't the following be a better solution as the above still has the ability to fall-through to later code should crypt() return NULL:

Code:

p_crypted = crypt(str_getbuf(p_pass_str), p_spwd->sp_pwdp);
if ( !p_crypted )
  return 0;

if (!vsf_sysutil_strcmp(p_crypted, p_spwd->sp_pwdp))
  return 1;

Anyway, looks like this ought to be fixed upstream and not at the distro level.

GazL --

You're right, the patch should be applied by the vsftpd maintainers.

Looking at the patch submitted by nixi in context, the code is isolated to function vsf_sysdep_check_auth( ) which is within an #ifndef VSF_SYSDEP_HAVE_PAM block.

See below.

Function vsf_sysdep_check_auth( ) checks for an entry in /etc/shadow and if that does not exist it looks in /etc/passwd

Your suggestion would bypass the existing /etc/passwd test if there's no valid entry in /etc/shadow changing the existing functionality:

The patch that nixi sent is the same Gentoo patch that Pat referenced ( https://forums.gentoo.org/viewtopic-...8-start-0.html )

This patch should definitely be applied.

But when sysdeputil.c changes, the patch may break if applied by Pat's team to the vsftpd.SlackBuild.

It's a dellimma ...

-- kjh

This is function vsf_sysdep_check_auth( ) for systems that DO NOT have PAM:

Code:

#ifndef VSF_SYSDEP_HAVE_PAM
int
vsf_sysdep_check_auth(struct mystr* p_user_str,
                      const struct mystr* p_pass_str,
                      const struct mystr* p_remote_host)
{
  const char* p_crypted;
  const struct passwd* p_pwd = getpwnam(str_getbuf(p_user_str));
  (void) p_remote_host;
  if (p_pwd == NULL)
  {
    return 0;
  }
  #ifdef VSF_SYSDEP_HAVE_USERSHELL
  if (tunable_check_shell)
  {
    const char* p_shell;
    while ((p_shell = getusershell()) != NULL)
    {
      if (!vsf_sysutil_strcmp(p_shell, p_pwd->pw_shell))
      {
        break;
      }
    }
    endusershell();
    if (p_shell == NULL)
    {
      return 0;
    }
  }
  #endif
  #ifdef VSF_SYSDEP_HAVE_SHADOW
  {
    const struct spwd* p_spwd = getspnam(str_getbuf(p_user_str));
    if (p_spwd != NULL)
    {
      long curr_time = vsf_sysutil_get_time_sec();
      int days;
      days = curr_time / (60 * 60 * 24);
      if (p_spwd->sp_expire > 0 && p_spwd->sp_expire < days)
      {
        return 0;
      }
      if (p_spwd->sp_lstchg > 0 && p_spwd->sp_max > 0 &&
          p_spwd->sp_lstchg + p_spwd->sp_max < days)
      {
        return 0;
      }
      p_crypted = crypt(str_getbuf(p_pass_str), p_spwd->sp_pwdp);
      if (!vsf_sysutil_strcmp(p_crypted, p_spwd->sp_pwdp))
      {
        return 1;
      }
    }
  }
  #endif /* VSF_SYSDEP_HAVE_SHADOW */
  p_crypted = crypt(str_getbuf(p_pass_str), p_pwd->pw_passwd);
  if (!vsf_sysutil_strcmp(p_crypted, p_pwd->pw_passwd))
  {
    return 1;
  }
  return 0;
}

#else /* VSF_SYSDEP_HAVE_PAM */

GazL · 06-11-2016, 03:38 AM

Quote:

Originally Posted by kjhambrick

GazL --

Function vsf_sysdep_check_auth( ) checks for an entry in /etc/shadow and if that does not exist it looks in /etc/passwd

Your suggestion would bypass the existing /etc/passwd test if there's no valid entry in /etc/shadow changing the existing functionality:

Yes, that was what I was getting at. On a system with SHADOW, if crypt() returns NULL then it will most likely be because the password entry in /etc/shadow is an invalid or unsupported format. As the password field in /etc/passwd will be the character 'x' on a shadow enabled box I can see absolutely no point in falling-through to the non-shadow code, only to let it run crypt() again against /etc/passwd only to have it return NULL again and then eventually fall-through to the return 0 at the end of the function. IMO, if crypt can't decode the shadow password field, then access should be denied and it should not go on to check against the field in /etc/passwd. But that's just my take on it. YMMV.

kjhambrick · 06-11-2016, 04:21 AM

Gotcha GazL.

Good point !

I agree completely !

And after I started looking at vsftp code (

I couldn't help myself

), maybe the best way to fix this issue and more would be to patch vsf_sysutil_strcmp( ) in sysutil.c so that it detects NULL pointers and returns 'not equal' ...

Function vsf_sysutil_strcmp( ) is simply a wrapper around strcmp( ) so there is an opportunity for a sanity-check there ( otherwise what's the point of vsf_sysutil_strcmp( ) ? )

That would fix the issue at hand and possibly others as well.

Anyhow ... vsftp won't even build as-is on a Current 64 + multilib system !

This is because shell function vsf_findlibs.sh locates 32-bit libraries in /usr/lib/ rather than native 64-bit libraries in /usr/lib64/

The strings /lib/ and /usr/lib/ are hard-coded in the vsf_findlibs.sh script ...( sigh )...

I've got a deadline looming and I've got no time to fix vsf_findlibs.sh right now

-- kjh

Patch that could fix NULL pointers in vsf_sysdep_check_auth( ) and elsewhere too:

Code:

diff -Naur vsftpd-3.0.3-orig/sysutil.c vsftpd-3.0.3/sysutil.c
--- vsftpd-3.0.3-orig/sysutil.c 2012-09-16 02:07:38.000000000 -0500
+++ vsftpd-3.0.3/sysutil.c      2016-06-11 04:13:32.942385706 -0500
@@ -1087,6 +1087,14 @@
 int
 vsf_sysutil_strcmp(const char* p_src1, const char* p_src2)
 {
+  if ( p_src1 == NULL )
+  {
+    return -1 ;  // first string is NULL ???
+  }
+  if ( p_src2 == NULL )
+  {
+    return  1 ;  // second string is NULL ???
+  }
   return strcmp(p_src1, p_src2);
 }

Note that there are A LOT of functions in sysutil.c that could use similar sanity checking.