mo...@rodents-montreal.org (Mouse) writes:
>> mount does a realpath() to resolve relative mount paths, not sure
>> since when..
>You're talking about mount(8), not mount(2), right? Arguably mount_mfs
>should do the same, for consistency if nothing else.
mount(8) and the various mount_xxx progra
mo...@rodents-montreal.org (Mouse) writes:
>Perhaps, but that's equally true of every other mount operation
>(except, to a partial extent, union mounts). Why would mount_mfs get
>special treatment? I don't see any chdir call in, for example,
>mount_ffs.
mount_ffs applies the mount system call a
dholland-t...@netbsd.org (David Holland) writes:
>But that's a backwards argument anyway. The point is that a vnd is a
>shim whose purpose is to work around a weakness in the system
>interfaces. (Namely, that you can't mount a fs image in a regular
>file.) It has no state, and no semantics of its
e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes:
>> No idea why it segfaults, but the status information is kept in
>> /var/db/statd.status. That's a db1 file and might be corrupt.
>Any way to check the integrity?
Maybe with the db command. But as long as there are no NFS file locks,
y
e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes:
>> so you're seeing not "continued to run" but "is running again"?
>No. ps u shows the start time as 04Mar.
rpc.statd runs on its own and doesn't get restarted automatically.
It does fork() to notify clients about NFS server restarts.
N
mo...@rodents-montreal.org (Mouse) writes:
>For what it's worth, it appears this behaviour is very longstanding. I
>find that 1.4T and 5.2 behave identically in this respect and are
>consistent with the "programmatic consumption versus human consumption"
>interpretation.
The change seems to be m
rein...@dropje.13thmonkey.org (Reinoud Zandijk) writes:
>> We have 'fsck' which resolves the device name and 'fsck_*' that gets passed
>> the resolved name.
>If they were never intended to be used separately then shouldn't they be in
>libexec?
Well, that's history for you :)
>> We also have 'd
rein...@netbsd.org (Reinoud Zandijk) writes:
>that returns a canonical raw device name when passed a device name in one of
>the following ways:
> /dev/ld0
> name="UUID"
> name="ROOT.x"
> /dev/dk1
> /some/mountpoint
> some/file/name
That looks like many distinc
rein...@netbsd.org (Reinoud Zandijk) writes:
> int getdiskinfo(const char *s, int fd, const char *dt, struct disk_geom *geo,
> struct dkwedge_info *dkw);
> int getdisksize(const char *name, u_int *secsize, off_t *mediasize);
There are kernel functions of the same name:
int getdiskinfo(s
t...@panix.com (Thor Lancelot Simon) writes:
>Probably not a good idea to start with lseek() because if you _do_
>encounter a tape device, seeking to SEEK_END could take you an extremely
>long time.
lseek() doesn't move the tape. But the open() or close() may trigger
tape operations like loading
mlel...@serpens.de (Michael van Elst) writes:
>But it also does not work for wedges or device mapper volumes
>(zfs vol probably fail too) as these don't implement the
>used internal ioctl for disk devices. At least that part
>would be easy to fix, but of questionable value.
cryintotheblue...@gmail.com (Sad Clouds) writes:
>Hello, for most operating systems determining the size of a block
>device can be done with:
>lseek(fd, 0, SEEK_END);
>However, on NetBSD this does not seem to work.
The disk size is only retrieved at open time and stored in the
cached vnode. st
mo...@rodents-montreal.org (Mouse) writes:
>> Way more interesting than useless tech demo sizes would size
>> inflation of a real world minimal program, when linked statically.
>Why? If I'm looking at overhead size, I am most interested in just the
>overhead size, which is exactly what a no-op p
thor...@me.com (Jason Thorpe) writes:
>Obviously this is not feasible to do with static binaries
In the world of go, you skip libc and static binaries are the norm.
mo...@rodents-montreal.org (Mouse) writes:
> amd64, 9.0_STABLE (ftp.n.o):
>textdata bss dec hex filename
> 562318 29064 2176416 2767798 2a3bb6 main
>> amd64, 9.0_STABLE:
>>data bss dec hex filename
>>2873 186 723131 c3b a.o
mo...@rodents-montreal.org (Mouse) writes:
>>> amd64, 9.0_STABLE (ftp.n.o):
>>>textdata bss dec hex filename
>>> 562318 29064 2176416 2767798 2a3bb6 main
amd64, 9.0_STABLE:
data bss dec hex filename
2873 186 723131 c3b a.out
crt0 pull
ed or
logged somewhere, but you could augment the helper script.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
blocked by npf vs 53.
blocklistctl dumps the policy database.
npf doesn't implement that policy, but only specfic
blocking rules. blocklistd adds npf rules when the
policy is violated (e.g. the 3rd login failure)
and removes rules when a timeout is reached.
Greetings,
--
ignat...@cs.uni-bonn.de writes:
>Hello,
>is there a minimal example how to configure bl*cklistd and npf to
>block attacks on sshd?
/etc/bl*cklistd.conf:
# Bl*cklist rule
# adr/mask:port typeproto owner namenfail disable
[local]
ssh stream tcp *
tlaro...@polynum.com writes:
>If inetd is not running, if the administrator doesn't look at the logs,
That's why people monitor services and logs and use manual or
automated procedures to validate and deploy configuration changes.
>At least, wouldn't it be worth to add a flag simply to parse and
tlaro...@polynum.com writes:
>It seems to me, since these are services, that the failure to load a
>config is critical enough (since the server may be then servicing what
>was not intended to be serviced; the reverse is less problematic)
>to exit at least on this error.
inetd will service what is
jo...@bec.de (Joerg Sonnenberger) writes:
>Which compiler from this century doesn't allocate stack space
>independent from the source order?
gcc with -O0 and -O1 allocates variables in source order.
With our notoriously broken gdb, that can be helpful.
mo...@rodents-montreal.org (Mouse) writes:
>>> I'd tend to assume it is the code.
>Well, then, there never can be any such thing as a bug in jot.
The original code (see rev 1.1) seems to be more clear on how
the parameters should be evaluated.
n...@netbsd.org (nia) writes:
>There are a few remaining cases where the sh(1) defaults are Bad:
It's not "Bad" but just does not fit your personal expectations.
>1. We can't assume XDM. Lots of desktop environments have their own
> preferred login manager which may have inconsistent behaviou
On Thu, May 26, 2022 at 12:34:49AM +, David Holland wrote:
> On Tue, May 24, 2022 at 06:57:23AM -0000, Michael van Elst wrote:
> > Also consider that people believe their data is safe in the current
> > virtualized world, just because someone calls "encryption&quo
dholland-t...@netbsd.org (David Holland) writes:
>(1) having an unencrypted option at all is one of the ways spooks like
>to weaken cryptosystems; it creates ways to force/cause people to use
>it when they didn't mean to.
People have to be very clear in making that choice and they actually
use it
jnem...@cue.bc.ca (John Nemeth) writes:
> I would say it is something that should be available as an
>option (likely a command line option). ssh/scp has pretty much
>completely replaced rsh/rcp (other than for people that go out of
>their way to use those); however, there are many things that
g...@lexort.com (Greg Troxel) writes:
>I would say that doesn't really fit with what we want either, certainly
>without somebody really trying. It breaks the rule that using ssh can
>count on confidentiality and integrity and makes systems with ssh as a
>component harder to reason about.
Still,
g...@lexort.com (Greg Troxel) writes:
>I view HPN as not the standard approach; it hasn't been merged upstream
>and PSC's agenda does not even seem to include merging any of it
>upstream -- which I see as a huge clue.
Looks more like upstream was never interested and PSC gave up.
Part of the HPN
0 in /dev. For ucom
that's easy but for ugen that's more difficult.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
blocksize of the fake disklabel made up by vnd and thus 512. Maybe the
>disc label creation code could be enhanced to detect this situation?
The label always returns the sector size of the device, i.e. whatever
you told vndconfig to present.
--
--
Michael va
metry and the medium size.
A ncylinders value of _zero_ means, it is deduced from the
medium size. So "2048/1/1/0" would work better, but there
is a bug in vnd(4) when doing that calculation :-/
--
--
Michael van Elst
Inter
# (Cyl. 0 -483*)
d:990512 0 unused 0 0# (Cyl. 0 -483*)
but things also work if I change the (in-core) label to 4.2BSD instead
of ISO9660.
--
--
Michael van Elst
Internet: mlel...@serpens.de
On Wed, Dec 23, 2020 at 07:36:10AM +, RVP wrote:
> On Wed, 23 Dec 2020, Michael van Elst wrote:
>
> > If you had multiple wsdisplay* instances, there would be some
> > corresponding ttyE* that you could send the ioctl to.
>
> Hmm: wsdisplay0 at intelfb0; wsdisplay
ions where X is not running/can't run and xrandr unavailable.
The console only handles one display and that gets queried with
WSDISPLAYIO_GET_EDID.
If you had multiple wsdisplay* instances, there would be some
corresponding ttyE* that you could send the ioctl to.
--
--
progress) {
to enable a 1 Hz "timeout" that effectively disables the quit_time feature.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
.4T had per-service rate
>limiting, in the form of a per-service maximum number of requests per
>minute.
Yes. The project milestone is a bit confusing, the rate-limit feature
is pretty ancient and was always per-service.
In any case, the suggested features will be more intrusive than a
changed
dholland-t...@netbsd.org (David Holland) writes:
>Also, if we do have a platform where it's too slow and anyone actually
>cares,
We spend more for HTML pages without a viewer in base.
--
--
Michael van Elst
Internet: mlel...
on small hardware (less than 32MB RAM).
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
with wsconsctl (also
in wscons.conf). E.g.
wsconsctl -k -w map+="keycode 49 = asterisk mu"
Greetings,
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
that tags success and error paths differently or uses
exceptions instead of error paths which have their very own problems.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
tion to tell.
Sadly everything is an emulated 20 year old computer nowadays.
On the other side it can provide a virtiornd device to an emulation
of a 25 year old OS which feels perfectly safe.
--
--
Michael van Elst
Internet: mlel...@serpens.de
riastr...@netbsd.org (Taylor R Campbell) writes:
>> Date: Mon, 11 May 2020 16:16:12 - (UTC)
>> From: mlel...@serpens.de (Michael van Elst)
>>
>> Previously we could trust in random processes, whether the entropy
>> estimation was scientific or not. We could also
e just gave up and say, without a HWRNG (which we believe is perfect),
it's the users problem to provide randomness.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
should be the basis for an API
decision, it should be thought about.
Otherwise we just need the API that helps in running foreign (aka Linux)
software and we don't have to talk about the quality.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
sible for getting the details right.)
Like installing a system from read-only media or a system that crashed
and starts again with the same seed.
I'm wondering, how you can trust a god-sent file from persistent storage
but not an unspecified random process?
--
--
it's neither the whole world
nor a contradiction. Even such systems split their data between
different filesystems, for a reason.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
(with LOG_CONS). We could just treat this output
like kernel messages and solve the "syslogd restart gap problem" with it too.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
If you only run throwaway VMs, your angle might be different. No
problem to put everything into a single partition there because
you just create a new VM from scratch.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
n be overridden from the command line.
So the check should happen a bit later until the final value is known
that will be passed to configure_params(), probably after checking
all the parameters.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
n't attached.
Why? Whether you rely on magic (== non-standard interfaces with
unspecified semantics) to skip the configuration or the configuration
just fails silently shouldn't make a difference.
Greetings,
--
Michael van Elst
Intern
ufficient to just ignore ENXIO failures when trying
to configure ?
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
with a special flag, so
details don't have to be spread over client programs.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
ms, open too. :)
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
output may come handy.
There's nothing against an option making mount or df print wedge names
and people can just use aliases in their profile.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
nd expect a device path.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
rs TMPDIR.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
rty has compat functions that should not be used.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
in this scenario.
> Anyway I gave a tool, if someone is interested in experimenting and
> feedbacking patches, feel free to do so. I will keep using them for
> catching kernel stability problems of the ptrace(2) APIs.
No question. Thanks for that.
--
Michae
t misleading,
a modern system does 100k gettimeofday calls in about a millisecond.
I'm not sure whether the additional complexity would be justified.
Another argument against this optimization is that tracing these
non-syscalls is even more complex.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
>current time.
That's only a symptom. The real question is why it doesn't sleep.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
", "wsmouse", "wskbd", "wsmux", "wsbell" };
static void
usage(void)
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
On Thu, Mar 28, 2019 at 04:33:00PM +, Emmanuel Dreyfus wrote:
> On Thu, Mar 28, 2019 at 02:41:08PM -0000, Michael van Elst wrote:
> > Maybe /dev/wsmux1 ? wsmux0 is mouse input.
>
> Same fate. Is it expect behavior that muxctl -f $i -l lists nothing
> for any $i ?
% sud
ee the input.
Maybe /dev/wsmux1 ? wsmux0 is mouse input.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
come a default for other tools.
Nobody can live without a console that has themes.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Next time it's not about colorized output but some other feature of
"program found somewhere else". According to some we already have to
replace 30% of NetBSD to make it usuable, a measly colorized ls won't
be enough.
--
--
web site.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
unset
for the lifetime of the shell?
N.B. that would also be my preferred handling of all such variables.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
(10e-1..10e-10 Pa) or graphite pressed into diamonds (6*10e+9 Pa)
it looks sufficient.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
e than 13 years ago
(with proper CVEs), both require careful preparation by the user to
be triggered.
Isn't that far from 'remote exploit' and 'everyone who can MITM can do that'?
--
Michael van Elst
Internet: mlel...@serpens.de
co...@sdf.org writes:
>You know I'm writing this as telnet on netbsd is vulnerable to remote
>exploits, and everyone that can MITM you can do that to you whenever you
>'telnet to see if ports are open'?
Obviously wrong.
--
--
Michael
campbell+netbsd-tech-userle...@mumble.net (Taylor R Campbell) writes:
>If the telnet client is remotely exploitable
Is it?
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
On Tue, Oct 02, 2018 at 11:05:56PM +0700, Robert Elz wrote:
> Date:Tue, 2 Oct 2018 11:28:59 - (UTC)
> From:mlel...@serpens.de (Michael van Elst)
> Message-ID:
>
> | Can you please check, you are misquoting, reversing the sense what I
> wrote.
k...@munnari.oz.au (Robert Elz) writes:
>Date:Tue, 2 Oct 2018 05:13:13 - (UTC)
>From:mlel...@serpens.de (Michael van Elst)
>Message-ID:
> | >Yes, that is what we need - but without knowing what the drive name is, as
> | >that can vary.
e need - but without knowing what the drive name is, as
>that can vary.
But you are not asking for that.
>The facility as designed seems like it does exactly what is needed,
Indeed. Add an "intermediate" feature.
--
--
Michael van Elst
onality needs to be added.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
ice name it doesn't help in this
case.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
or not. Unlike with regular installations (sysinst...) the
user has no means to configure this and apparently should not have to
do it.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
not, that will always find the correct
device.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
ystem).
With wedges you would just reference them by name.
N.B. resizing a wedge in use isn't impossible. A device mapper unit
(aka LVM logical volume) is something similar. The functionality
just needs to be implemented in the wedge driver.
--
--
Michael va
rom kern_subr.c) also needs to be exposed
a bit more.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
ant privileges.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes:
>> Pages are only removed from swap when they are freed or accessed.
>Ah, I see, thanks!
>Can I find out which processes own pages that are paged out?
Unfortunately not.
--
--
Mich
0%0
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
oting but not a '*'. It
also doesn't understand quotes on input:
$ rm foo\
Display all 411 possibilities? (y or n)
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
font is done in
two stages (taken from the vcons commit message), e.g.:
wsfontload -N foo /usr/share/wscons/fonts/flori.816
wsconsctl -dw font=foo
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
On Sat, Jan 20, 2018 at 01:33:32AM +0100, Kamil Rytarowski wrote:
> On 19.01.2018 21:24, Michael van Elst wrote:
> > net...@precedence.co.uk (Stephen Borrill) writes:
> >
> >> 1) Revert above and always use p_comm (and note in man page)
> >> 2) Use p_comm only i
ly be
to use argv[0], except for -x where you want p_comm.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
ry/presentations/yuuki/2017_AsiaBSDCon/basepkg.pdf
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
't provide anything beyond rand(),
as you said, it does neither provide crypto strength nor does't it guarantee
any statistical properties.
If you don't want to use an obsolete interface, use random() instead.
--
--
Michael van
lf and offset disk accesses accordingly.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
errno to 0.
> Success: it is not an error to call strerror with 0.
Means that strerror(0) should not set errno=EINVAL. Doesn't
say anything about the returned string.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
tionable. It should return a phrase that is easily
identified as the errno==0 value.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
r...@marples.name (Roy Marples) writes:
>If it doesn't work on NFS and you care so much, please spend your time
>fixing NFS
If you want to change things you should not try to pass your responsibility
to someone else.
--
--
Michael van Elst
Int
r...@marples.name (Roy Marples) writes:
>See here:
>http://mail-index.netbsd.org/tech-userlevel/2016/03/21/msg009799.html
... handling crashing programs reliably
isn't a worthwhile goal to me.
--
--
Michael van Elst
Internet: mlel...
r
isn't reliable. But I've seen this used, e.g. by HA cluster frameworks.
Anything else shouldn't use a pidfile at all but run some kind of
monitor process that just waits for the daemon process to exit.
--
--
Michael van El
r...@marples.name (Roy Marples) writes:
>Saying that, I'm not really bothered about any remote lock on a remote fs,
>just as long as it can lock correctly on the host.
Why would you think NFS root to be not on the host?
--
--
Michael van Elst
Int
r...@marples.name (Roy Marples) writes:
>So I've created pidfile_lock (patch attached) to address these problems.
Does it work on NFS root?
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may
mum limit
of -273.15C should be equivalent to no limit.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
99 matches
Mail list logo
