IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Python idioms for iterating over a line and closing it have improved,
and we should keep up.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Noel Power <npower@samba.org>
The only caller of this was `samba-tool domain demote` which stopped
using it in 2015 with commit f121173cbf.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Noel Power <npower@samba.org>
Other tools use identical functions, and they too can use common.py
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Noel Power <npower@samba.org>
F_SETLEASE/F_SETSIG were all included in the kernel
and glibc in 2002, there's no need to have fallbacks 18 years later.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Dec 7 20:07:18 UTC 2020 on sn-devel-184
F_GETLEASE/F_SETLEASE/F_SETSIG were all included in the kernel
and glibc in 2002, there's no need to have fallbacks 18 years later.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
F_GETLEASE/F_SETLEASE are available (at least) since Linux 2.4.0 from
2002.
We also should not have the configure check depend on the filesystem
we find at build time. It's very common that the build-environment is
much more restricted than the runtime-environment will be.
As a history we had this check on Samba 3.6:
AC_CACHE_CHECK([for Linux kernel oplocks],samba_cv_HAVE_KERNEL_OPLOCKS_LINUX,[
AC_TRY_RUN([
#include <sys/types.h>
#include <fcntl.h>
#ifndef F_GETLEASE
#define F_GETLEASE 1025
#endif
main() {
int fd = open("/dev/null", O_RDONLY);
return fcntl(fd, F_GETLEASE, 0) == -1;
}
],
samba_cv_HAVE_KERNEL_OPLOCKS_LINUX=yes,samba_cv_HAVE_KERNEL_OPLOCKS_LINUX=no,samba_cv_HAVE_KERNEL_OPLOCKS_LINUX=cross)])
if test x"$samba_cv_HAVE_KERNEL_OPLOCKS_LINUX" = x"yes"; then
AC_DEFINE(HAVE_KERNEL_OPLOCKS_LINUX,1,[Whether to use linux kernel oplocks])
fi
which didn't depend on the filesystem.
Then we got a broken check introduced in Samba 4.0 (a copy of the
F_NOTIFY check):
# Check for Linux kernel oplocks
conf.CHECK_CODE('''
#include <sys/types.h>
#include <fcntl.h>
#include <signal.h>
#ifndef F_NOTIFY
#define F_NOTIFY 1026
#endif
main() {
exit(fcntl(open("/tmp", O_RDONLY), F_NOTIFY, 0) == -1 ? 1 : 0);
}''', 'HAVE_KERNEL_OPLOCKS_LINUX', addmain=False, execute=True,
msg="Checking for Linux kernel oplocks")
this got "fixed" in Samba 4.7 (and backports to 4.6, 4.5 and 4.4) into
# Check for Linux kernel oplocks
conf.CHECK_CODE('''
#include <sys/types.h>
#include <fcntl.h>
#include <signal.h>
#ifndef F_GETLEASE
#define F_GETLEASE 1025
#endif
main() {
exit(fcntl(open("/tmp", O_RDONLY), F_GETLEASE, 0) == -1 ? 1 : 0);
}''', 'HAVE_KERNEL_OPLOCKS_LINUX', addmain=False, execute=True,
msg="Checking for Linux kernel oplocks")
Lately it became dependend on the filesystem in the build-environment:
# Check for Linux kernel oplocks
conf.CHECK_CODE('''
#include <sys/types.h>
#include <fcntl.h>
#include <signal.h>
#ifndef F_GETLEASE
#define F_GETLEASE 1025
#endif
main() {
const char *fname="/tmp/oplock-test.txt";
int fd = open(fname, O_RDWR|O_CREAT, 0644);
int ret = fcntl(fd, F_SETLEASE, F_WRLCK);
unlink(fname);
return (ret == -1) ? 1 : 0;
}''', 'HAVE_KERNEL_OPLOCKS_LINUX', addmain=False, execute=True,
msg="Checking for Linux kernel oplocks")
Now we just check for F_SETLEASE being available in linux/fcntl.h.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
There're no references to F_NOTIFY nor HAVE_KERNEL_CHANGE_NOTIFY in the
code, so the configure check is not needed at all.
We only use the inotify or fam abstractions.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14248
RN: samba process does not honor max log size
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Mon Dec 7 18:54:29 UTC 2020 on sn-devel-184
With debug_schedule_reopen_logs() the actual reopen only takes place at some
point in the future when a DEBUG message is processed.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14248
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Replace the low-level signal handler for SIGHUP with a nice tevent signal
handler. The low-level handler sig_hup() installed by setup_signals() remains
being used during early startup before a tevent context is available.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14248
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Pass a pointer to the struct instead of all struct members individually. No
change in behaviour.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14248
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Pass a pointer to the struct instead of all struct members individually. No
change in behaviour.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14248
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Sat Dec 5 22:35:04 UTC 2020 on sn-devel-184
Nobody in share_mode_lock.c looked at that value anymore, so we don't
need to manually maintain it.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Dec 4 22:32:38 UTC 2020 on sn-devel-184
Rely on the truth in locking.tdb wrt existence of share entries
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Rely on the truth in the database whether we found share modes or
not, share_mode_data_store() has that information for free.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The call to share_mode_have_entries() was put in before
fresh_share_mode_lock() initialized d->flags to be completely
permissive. With that correct initialization the call to
share_conflict() a few lines down will also make open_mode_check()
pass for any share_access/access_mask.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Take a struct file_id instead of a locking.tdb key,
share_mode_memcache_store() also operates on the implicit fid in
struct share_mode_data.
To do this, parse_share_modes() also needs to take file_id.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
In a pure docker environment with overlayfs F_GETLEASE works on /tmp,
but F_SETLEASE does not. This test now correctly detects that.
The effect is that the samba-fileserver environment would run fine in
a shared gitlab runner, at the price of not testing kernel oplocks. We
could move the kernel oplock tests to another environment that for
other reasons can't run on shared gitlab runners.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
No need to log missing shares/sharenames at debug level zero.
Keep the debug level zero for all other usershare problems.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14590
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Rowland penny <rpenny@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Dec 4 20:54:06 UTC 2020 on sn-devel-184
This was an omission in the fixes for bug 14470.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14587
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Dec 1 20:29:34 UTC 2020 on sn-devel-184
smb_client behaviour is to die if there is an error. This is
a little heavy handed and make it impossible for example to
use smb_client to run a command that might fail (where such
a failure isn't really an error) E.G. Calling deltree and
the directory doesn't exist
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14581
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
LOCALPATH is actually the local path to the share, we should
not need to create the share path (it should already exist)
Note: When we remove the tree located at LOCALPATH we keep the root
so the share path should always be there
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14581
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
samba3.blackbox.smbclient_tar is marked as flapping so it
seems we have missed that it has stopped working. The local path
passed to script/tests/test_smbclient_tarmode.pl must point to a
valid share
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14581
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Make sure samba3.blackbox.smbclient_tarmode removes data files
not just before running the test but also after
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14581
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Replace rm -rf of local dir (that is hosted remotely)
with smbclient deltree
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14581
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
After this change both samba3.blackbox.smbclient_tar &
samba3.blackbox.smbclient_tarmode now use the same dedicated share
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14581
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
The other tarmode torture test samba3.blackbox.smbclient_tar now uses a share
'tarmode' which uses the same source path as samba3.blackbox.smbclient_tarmode
Avoid conflicting paths and use a new subdir (of the test share) called
'smbclient_tarmode'
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14581
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Jeremy Allison <jra@samba.org>