Portada
mis comunidades
otras secciones
#2:
#1 Para aquellos que usan ksmbd, existe una solución diferente a cambiar a Samba: actualizar a la versión 5.15.61 del kernel de Linux, lanzada en agosto, o una versión más reciente.
Por lo que veo se solventa actualizando el kernel a versiones "modernas", la mayoría de distros que conozco van por delante hace ya bastante tiempo.
Por lo que veo se solventa actualizando el kernel a versiones "modernas", la mayoría de distros que conozco van por delante hace ya bastante tiempo.
#9:
#4 Esa es la idea:
"ksmbd" is a new Linux kernel module which implements an SMB server. It's aimed at being low overhead, low footprint, performant fileserver covering many basic usecases, running on smaller devices with limited resources being the most apparent one: OpenWRT, the Linux distribution for embedded devices, adopted ksmbd already 18 months ago while ksmbd was still being developed."
Las negritas son mias.
"ksmbd" is a new Linux kernel module which implements an SMB server. It's aimed at being low overhead, low footprint, performant fileserver covering many basic usecases, running on smaller devices with limited resources being the most apparent one: OpenWRT, the Linux distribution for embedded devices, adopted ksmbd already 18 months ago while ksmbd was still being developed."
Las negritas son mias.
#15:
#3 por lo menos en el kernel de Linux tienes a gente auditando este tipo de cosas, en sistema propietarios, no.
Supongo que toda la Infraestructura de Internet, todas las grandes empresas incluyendo bancos, telecos, energéticas, ciencia, etc, van con Linux por casualidad.
Espero que la proxima vez hablen contigo para que les des tu una idea buena, buena.
Supongo que toda la Infraestructura de Internet, todas las grandes empresas incluyendo bancos, telecos, energéticas, ciencia, etc, van con Linux por casualidad.
Espero que la proxima vez hablen contigo para que les des tu una idea buena, buena.
#7:
Casi nadie utiliza ksmbd, todo el mundo utiliza samba
Comentarios
Casi nadie utiliza ksmbd, todo el mundo utiliza samba
#40 depende que es lo que tienes en tus sistemas, a poco que pueda ser comprometido, usa una distro orientada a servidores y parchea, ya sabes, primero en preproduccion, después en producción y a la semana en el centro de respaldo.
Te garantizo que se puede hacer incluso con sistemas realmente críticos de cientos de millones.
#34 ah, claro, nvidia. Es una faena que el fabricante no haya querido colaborar con el núcleo de línux para darle un soporte adecuado. No sé si ya habían cambiado de idea. Yo cogí una amd para evitarme problemas.
#39 Yo siempre los cojo nvidia porque se supone que son más fiables con Linux, pero en el nuevo ordenador me lo pensaré.
#39 #58 Se supone que los drivers AMD abiertos son buenos, pero para una Vega 8 me funciona mejor el driver propietario.
Es el año de linux en el escritorio…remoto
#6 No, sin importancia. Nadie usará el protocolo smb a día de hoy en ningún sistema medianamente importante o cuidado. Hay cosas mucho mejores.
#32 you también soy un lego (city, en mi caso), ¿qué otros protocolos (mejores) hay para un cliente Windows?
#36 por suerte en windows se puede instalar ya mucho software libre. Pero vamos, no conozco mucho windows. No me parece que sea algo muy usado en sistemas serios y lo poco que se usa da más dolores de cabeza que otra cosa.
“atacantes remotos ejecutar código arbitrario en instalaciones afectadas de Linux Kernel. No se requiere autenticación para explotar esta vulnerabilidad, pero solo los sistemas con ksmbd habilitado son vulnerables” es decir, un montón
#1 Para aquellos que usan ksmbd, existe una solución diferente a cambiar a Samba: actualizar a la versión 5.15.61 del kernel de Linux, lanzada en agosto, o una versión más reciente.
Por lo que veo se solventa actualizando el kernel a versiones "modernas", la mayoría de distros que conozco van por delante hace ya bastante tiempo.
#2 hay muchos sistemas que, por dependencias, no pueden actualizarse a la última versión de su distro. Por tanto tampoco tienen el último kernel
#2 Por ejemplo yo. Para esas versiones no encuentro driver para mi tarjeta gráfica, y que no me digan que use el Wayland, que menudos cuelgues que se pega. Tengo que usar el software privativo y para los núcleos superiores a la 5.4.0 no funciona. El Samba uso el SMB2 aún, que no depende del kernel nada más que para lo necesario.
#25 ¿ Cuál es tu tarjeta gráfica ?
#28 una GeForce 210, de 1 Gb, sí, ya sé que es antigua, pero ya no me molesto en cambiarla
#2 Es un error de Julio y en una versión antigua. Desde entonces ha habdo más de diez versiones de linux. ES lo que me pasa siempre con las noticias de bugs de software libre, que cuando llegan a mnm están más que parcheadas en mi sistema sin que yo siquiera me haya enterado.
#29 #2 Yo he visto servidores críticos en CPD críticos haciendo tareas críticas con Red Hat 7 (Sí, la del año 2000).
No la tienen expuesta a Internet al menos, pero vamos...
#37 por principio de prudencia si es crítico mejor tocarlo poco o nada, no sea que se estropee por haberlo tocado
#1 Supongo que este ksmbd tendrá su caso de uso, no digo que no, pero sí que no diría que hay "un montón" de sistemas corriendo ksmbd.
#1 A mi aun me falta ver un servidor con esto activado por defecto.
Que tengan un kernel con el modulo, si, que el modulo este cargado y listo para ser usado como tal es otra cosa.
Y las versiones del kernel desde agosto estarán mas que parcheadas.
Así que menos montón.
#1 Servidores corporativos pocos.
#26 y el propietario tampoco es garantía de nada.
Si no sale a cuenta que salga la información de un problema de seguridad, se entierra y punto.
Con open source pueden haber cagadas pero estas están a la vista. Inherentemente es más seguro y confiable.
Del sistema propietario te tienes que fiar, es un acto más de fe. En el OpenSource és facil saber si algo lo es o no lo es.
#26 a parte de lo que ha dicho #33 en codigo propietario te pueden meter puertas traseras sin que el usuario sea consciente. En open source cualquiera puede revisar que no sea asi.
#44 Normalmente la k es de kernel y la d de deamon.
#45 Sabía lo de la d pero no lo de la k
Siempre habia asociado la k a proyecto kde (Aunque en este caso no tiene nada que ver)
#46 Hubo un tiempo en el que el kernel incluía un servidor HTTP llamado khttpd
#23 Mac usa kernel BSD
#51 no es relevante en este caso. Mi opinión se enfoca en el conjunto del software, no solo el núcleo.
#68 Así debe ser. Será que la mía es un versión obsoleta o algo. Ya decía yo que no cargaba bien
#73
Espera me voy a empezar a poner con el mismo tonito que tu
"Y si obviamos VMWARE..."
Primero, lo obviamos por tus huevos morenos
Dos, vmware no tiene nada ni medio parecido a ceph... VSAN (by vmware) es un SDS bloque, ni objeto ni fichero (para eso ya tiene VMFS_X)
Sobre lacp, en serio, tienes que leer un poco sobre los algoritmos de balanceo... Mucha gente cree que se agregan los puertos físicos y lacp obra la magia... Pues no, se necesita un hash para la secuencia y una ip o mac para establecer origenes y destinos... Puedes leer ieee 802.3ad que buena falta te hace...
Y sobre el resto no voy a perder el tiempo tu soberbia es infinita... Vamos, un tio que nos explica a todos, incluidos todos los ingenieros de microsoft que se metan smb3 por donde les quepa que para entornos de azure o azure stack ya hay cosas mejores y que smb3 en storafmge spaces direct es una putísima mierda.
En serio, los talibanes tecnológicos sois tóxicos... ni te molestes en responder que no he sido yo el que ha ido increpando...
#54 Vaya, que manipulador... Te has dejado lo más importante, la coletilla...
... en un clúster
Para microsoft si es un avance teniendo en cuenta que SMB era (y en parte sigue siendo) una verdadera basura.
#59 En un clúster hace mucho que se puede hacer eso. Y smb es innecesario para hacerlo
#60 ¿De que cluster me hablas? ¿De uno en azure, azure stack, hyper-v pelado?
Smb3 ha supuesto que microsoft no necesite tecnologías de terceros.¿Tiene lógica verdad?
#61 Ya usa Hyper-v Microsoft en su nube ?
#61 Ya en serio. Entiendo que smb3 sea útila para los sistemas Windows.
Pero ya. Nada más.
#63 Azure no es windows y smb3 tiene implicaciones que veo que no entiendes... Oye mejor déjalo ya.
Un saludo
#66 Que implicaciones que no pueda solucionar mejor por ejemplo Ceph, iSCSI o mismo NFS ?
Azure es un nombre que se le da a una estructura de virtualización como tantas otras.
#67 Ceph es un hiperescalar de ficheros, nada más... ISCSI es solo servir bloque... Por cierto un protocolo que es como es por su herencia con SCSI y que aunque ahora tiene una interesante función, es mucho más lento, inseguro y problemático que por ejemplo Fiber Channel.
NFS hace bien su cometido en la gestión de bloqueos pero es malísimo para paralelizar en múltiples canales hacia un solo origen. Casi es mejor hacerlo a nivel "IP" haciendo agregación de puertos.
SMB3 a parte de proveer de un nuevo servicio SaaS para gente que quiera un servidor seguro SMB en azure sin VPNs, es un repositorio que supera en rendimiento a NFS gracias a su nueva paralelización de conexiones y la gestión del bloqueo del nodo del cluster que tenga activo uno de los recursos del share. És útil en hyper-v, en azure y muy rápido... Realmente microsoft ha matado dos pájaros de un tiro. No me gusta nada microsoft pero ahí ha acertado. Por cierto SMB lo inventó IBM un año antes que NFS.
No seamos talibanes... Microsoft hoy es uno de los mayores donantes de proyectos open source y casi seguro que windows va a ser un GNU-linux más más pronto de lo que nos imaginamos (lo del linux subkernel system no es por azar, es para converger)
#69 Ceph es un hiperescalar de ficheros,
Qué quieres decir con "un hiperescalar" ?
Ceph es un sistema de almacenamiento en cluster con balanceo de carga y alta disponibilidad. Cuando Smb de la mitad de características esenciales para un sistema de clustering de virtualización avisa.
Recuerda que sobre CEPH puedes montar FiberChannel o iSCSI entre otras cosas.
iSCSI es para servir dispositivos de almacenamiento en red. ¿ Para qué quieres compartir archivos en un sistema de virtualización?.... entre sistemas virtualizados, aún. Pero para un sistema de de virtualización como hyper-v.....
es mucho más lento, inseguro y problemático que por ejemplo Fiber Channel.
Claro. Pero mucho más barato.
En los CPD potentes se usa FiberChannel.... ¿ Pero SMB3 para qué exactamente ?
NFS hace bien su cometido en la gestión de bloqueos pero es malísimo para paralelizar en múltiples canales hacia un solo origen. Casi es mejor hacerlo a nivel "IP" haciendo agregación de puertos.
Es infinitamente más eficiente en su trabajo que SMB. Por eso lleva décadas usándose en sistemas de virtualización, mientras que SMB solo parece que va a ser "usable" ahora.
Y no veo el problema de utilizar port-trunking/LACP para lo que está pensado el port-trunking/LACP. Por cierto, LACP no funciona a nivel de IP.
SMB3 a parte de proveer de un nuevo servicio SaaS para gente que quiera un servidor seguro SMB en azure sin VPNs...
Parece un copia-pega del departamento de márketing.
¿ Quieres decir "a parte de permitir compartir carpetas sin VPN" ?
es un repositorio que supera en rendimiento a NFS...
Je. Ardo en ver los benchmark. Por supuesto con una correcta configuración de ambos. LACP incluido.
gracias a su nueva paralelización de conexiones y la gestión del bloqueo del nodo del cluster que tenga activo uno de los recursos del share
Benchmark son amores. Los copia-pega de la página de venta del producto, no.
És útil en hyper-v...
Para hacer qué exactamente. Es un simple sistema de compartición de archivos. No es más útil que NFS.
Útil es iSCSI, Fiber Channel o Ceph.
Realmente microsoft ha matado dos pájaros de un tiro.
Qué dos pájaros?
Qué puede hacer aparte de compartir archivos ?
Por cierto SMB lo inventó IBM un año antes que NFS.
Ni, idea. ¿ importa ?. Por cierto, NFS nació en el año 1984.
No seamos talibanes... Microsoft hoy es uno de los mayores donantes de proyectos open source y casi seguro que windows va a ser un GNU-linux más más pronto de lo que nos imaginamos (lo del linux subkernel system no es por azar, es para converger)
Ciertamente, me importa un huevo.
En serio: ¿ Para qué sirve smb3 aparte de para compartir archivos ?. Si puede ser en palabras comprensibles, que los corta-pegas de márketing se me hacen difíciles.
#70 "corta-pegas"
Encuentra de donde he cortado y pegado anda... Menudo Ad-hominem te has marcado.
"LACP no funciona a nivel de IP"
Pues claro que no, yo no he dicho eso, pero si tu repositorio NFS está en una IP, una de las variables del balanceo puede ser esa (ip, hash, mac...). El que seguro que no usa "ip" para nada es fiber channel
Es simple, NFS necesita de switchs para paralelizar,SMB3 no
Sobre Ceph pues es un SDS de tantos (muy popular, eso es todo)... Para mi gusto mejor en fichero y objeto y lento y malo para bloque. Y es hiperescalar debido a su arquitectura (pst, eso es bueno, no te enfades con me importa un huevo y cosas por el estilo)
"""En serio, para que sirve smb3 aparte de para compartir archivos?"""
Pues te lo he dicho es un muy buen repositorio para almacenar discos de máquinas virtuales vhdx y vhd onprem y en azure stack (y que los nodos del cluster lean y escriban coordinadamente sin romper nada) y pst... Integrado con storage spaces direct que es el SDS también hiperescalar de microsoft.
Precisamente por ser microsoft el peor player han ido dando pasos muy interesantes y económicos. Antes comentabas que iscsi es una solución coste efectiva... Pues SMB3 también y tiene algunas ventajas sobre iscsi (aunque para algunos escenarios siempre va a ser mejor un protocolo bloque nativo).
Ei, que no soy tu enemigo...
#71 Pues claro que no, yo no he dicho eso, pero si tu repositorio NFS está en una IP, una de las variables del balanceo puede ser esa
No. Usas LACP. O bonding simple. Nada que ver con IP.
Es simple, NFS necesita de switchs para paralelizar,SMB3 no
Es simple. NFS tampoco. Para eso está el bonding
Pues te lo he dicho es un muy buen repositorio para almacenar discos de máquinas virtuales vhdx y vhd
Eso es compartir archivos. Así de simple. No lo hace mejor que NFS y es una mierda pinchada en un palo para una infraestructura de virtualización.
Sobre Ceph pues es un SDS de tantos
Cita 3 con características similares. Y si obviamos VMWARE...
(y que los nodos del cluster lean y escriban coordinadamente sin romper nada)
Eso lo lleva haciendo décadas NFS
No has dicho aún que hace smb3 aparte de compartir archivos
#53 Rara es la red que no acaba teniendo un windows por algún lado
Lo importante de Ceph es la alta disponibilidad y el almacenamiento distribuido. No has citado ninguna alternativa
https://thelinuxcluster.com/2010/01/08/linux-bonding-modes/
NO se hace a nivel IP. Se usa la Mac. Son capas OSI distintas.
Sobre el resto no pierdes el tiempo porque no tienes nada que decir
Qué aporta smb3 más allá de la compartición de ficheros? Que hace que no haga NFS más allá de la autenticación y autorización? ( Que se puede lograr con kerberos)
Yo no he dicho que se metan smb3 por ningún lado. He dicho que no es nada "importante".
Otra cosa es que Azure esté organizado de modo que smb sea "algo importante".
Respecto al tono, lamento que no te guste. Solo he expresado y fundamentado mi opinión. Y el explicar cosas como si fuera un panfleto de Marketing no ayuda.
Soy un lego, y quizá sea una pregunta estúpida, pero me gustaría un poco de luz... ¿Cuál es la necesidad de integrar un servidor equivalente a Samba en el kernel? ¿Reducir el overhead en sistemas embebidos?
#4 Yo soy un tente.
#5 y no solo eso. Aventuro que tiene Usted mas de cuarenta años.
#12 Tengo 60 y cuando tenía 14 ya jugaba con Tente.
#12 Aventura usted bien. ¿En el barco de los piratas? Aún lo tengo por ahí, aunque las velas están casi quebradizas, me da no sé qué dejárselo a los sobrinos (ya tienen bastante con los mmaster del universo y los vehículos de los madelman).
#4 Yo no tenía ni idea de que esto existía, la verdad, pero según el github del proyecto, el objetivo es conseguir mejor rendimiento e implementar ciertas características avanzadas de SMB que son mucho más fáciles de implementar dentro del kernel.
#4 Esa es la idea:
"ksmbd" is a new Linux kernel module which implements an SMB server. It's aimed at being low overhead, low footprint, performant fileserver covering many basic usecases, running on smaller devices with limited resources being the most apparent one: OpenWRT, the Linux distribution for embedded devices, adopted ksmbd already 18 months ago while ksmbd was still being developed."
Las negritas son mias.
#9 ¿Y las chinitas?
#9 A ver, las negritas son universales, no te las puedes apropiar
#9 Teniendo ssh smb es una inutilidad....
Salvo que los Windows están muy limitados, y si tienes sistemas Windows en la.red...
#4 No tengo ni idea de si samba soporta smb3 pero si no es así la seguridad es importante dejando a un lado el rendimiento y paralelización. Con SMB3 el repositorio se puede usar para ejecutar VMs desde un cluster
de hipervisores y gestionar correctamente los bloqueos de forma similar a NFS.
Yo también veo que meter esto en el kernel es un pelin peligroso pero en contrapartida el rendimiento debe ser espectacular.
#10 Con SMB3 el repositorio se puede usar para ejecutar VMs ..
Vaya, que avance....
#4 ... pregunta y desde el desconocimiento, ¿quién deja "expuesto" un servidor de ficheros?... me refiero, que la vulnerabilidad - si en el hilo se ha explicado bien, es cuando expones el servidor con ksmbd. Ese servidor podrá estar dentro de una red "local" ... por lo que no termino de ver eso de "atacante remoto no autenticado".. en cualquier caso tendría (creo) que ser a través de la red
(disculpen mi ignorancia)
#30 en ese contexto que dibujas, los potenciales atacantes son (en efecto) las demas maquinas de la red.
#30 en la vida real hay servidores en producción con servicios abiertos publicados (algo aberrante si no hay un WAF o muy buena seguridad). Si se puede dejar expuesto, alguien lo dejará expuesto. Y los movimientos laterales dentro de una LAN son el primer ataque que se realiza una vez se ataca exitosamente una red.
Qué manía en Linux de nombrar las cosas cogiendo letras al azar y después eliminar las vocales.
#24 Starting pdrsnchz daemon ...............
#41 systemctl restart pdrsnchzd
#41 Hay que añadirle además una k y una d al final por lo visto.
Kpdrsnchzd sería un buen nombre.
#24 Yo no veo ninguna letra al azar. El protocolo original de Microsoft se llamaba smb
Luego un tio hizo una implementación libre de smb y lo llamo samba.
#43 y la k y la d?
Pasate a Linux dicen, es super seguro dicen
#3 por lo menos en el kernel de Linux tienes a gente auditando este tipo de cosas, en sistema propietarios, no.
Supongo que toda la Infraestructura de Internet, todas las grandes empresas incluyendo bancos, telecos, energéticas, ciencia, etc, van con Linux por casualidad.
Espero que la proxima vez hablen contigo para que les des tu una idea buena, buena.
#15 si y no. En un sistema propietario tienes a gente contratada auditando, o por lo menos debería ser así. Y que sea open source no es garantía de nada. A la vista estuvieron las famosas cagadas de OpenSSL y gcc durante años y ni dios se dio cuenta
#26
En un sistema propietario tienes a gente contratada auditando, o por lo menos debería ser así
Seguro que tienen a gente auditando código, pero tú como usuario no puedes ver lo que hace ese código, así que te toca fiarte...
#3 no hay sistema seguro, sino poco conocido
#3 vaya por delante que carezco de conocimientos informáticos, pero yo diría que a dia de hoy (reitero que lo digo alegremente y sin conocimientos) linux me parece mas seguro que Windows. No puedo valorar Mac.
#20 OpenBSD > Linux >>>> Windows > Mac
#23 tambien confieso que no puedo valorar OpenBSD porque no le usado. Pero prometo asomarme a curiosearlo.
#3 Imagínate la de agujeros de seguridad que tienen Windows o Mac y que nunca sabrás ni que existen.
#3 "Yo le hago caso a giliwoke" no dicen.
#3 Como se ve que desconoces el mundillo, te cuento las bases: en ingeniería no hay ningún sistema perfecto. Ninguno. El software no es una excepción. Uno de los ciclos de ingeniería es detectar errores, reportarlos y corregirlos. Cuando veas errores es que el sistema está funcionando. Este error en octubre estaba resuelto.
Cuando veas un sistema del que no se anuncia ningún error, es que no stá siendo mantenido y los errores se mantienen ahí indefinidamente.
#3 Pues si. Fíjate hasta que punto que una vulnerabilidad crítica como está puede no afectar prácticamente a nadie.