Re: "no route to host" from pkg_add
Sorry for the double posting. But Just to add to the info, the RFC 3177 did specify assignment to remote site even house being /48 and big site like /47 https://tools.ietf.org/html/rfc3177 Crazy. The revise version of it RFC 6177 correct that crazy assignment and specif that you should do /56. https://tools.ietf.org/html/rfc6177 But that is still even crazy specially when you see users using NAT64 on IPv6... Anyway, back to my rock and I hope it help you address your assignment anyway. Daniel On 8/10/18 10:38 PM, Daniel Ouellet wrote: > Hi, > > I am not sure you got that right. > > If you are an ISP the minimum assignment is /32 and you assigned /48 to > end company and /56 to users. > > If you asked me that's a wasted, but that's what they suggest. > > For end users, a /64 would be plenty if you asked me and /56 for company > would be plenty as well. > > But if you truly follow their policy, then well may be will run out > there too like in IPv4 when it really start to be assigned, but anyway > that's for a different discussion. > > Anyway see ARIN policy for it: > > https://www.arin.net/vault/policy/archive/ipv6_policy.html > > If you are not under ARIN, but RIPE, APNIC, AfriNIC, Lacnic, etc. > > They have similar policy. > > I would encourage you to check that if your problem is really that you > got to small assignment. > > Unless your a very small ISP that got his assignment from your transit > provider oppose to your own and get your own AS number, you will have > plenty to work with. > > I really do not know of ANY ISP that get /56 for real. > > I got my assignment in 2003 and the policy still haven't changed. > > Hope this help you some. > > Daniel. > > > On 8/10/18 9:12 PM, Walt wrote: >> On August 10, 2018 3:57 PM, Henry Bonath he...@thebonaths.com wrote: >> >>> Also could it be that you are using IPv6, not IPv4? (and your IPv6 is >>> missing its gateway) >>> If the IPv6 gateway is bad/missing you'll get that "no route to host" >>> message. >> >> I've encountered that issue before, but it isn't that big a problem with me. >> As an ISP, the /56 we have been allocated is too small to be very useful so >> I'm holding back on working on it much until such time as we get at least a >> /48 if not a /40. I'd like to be able to assign each customer a /56 but >> would settle for a /60 for each. With a /60, I could only handle sixteen >> customers. We have a number of customers for whom a /64 wouldn't cut it at >> all. >> >> I never have figured out the proper way to configure rtadvd.conf. In >> particular, there is an addr and an rtprefix. >> >> addr is, according to the man page, "The address filled into Prefix field" >> while rtprefix is " The prefix filled into the Prefix field of route >> information option". And then there are the proper prefix lengths -- do I >> use 64 or 56? It seems like prefixlen must be 64, but rtplen doesn't seem to >> make much difference. >> >> And then there is the kea side for prefix delegations. >> >> Since I can just put the IPv6 gateway into /etc/mygate, it's not a problem >> from the OpenBSD machines and it will never be a big issue if I can't get a >> properly sized allocation of addresses from AT >> >> Walt >> >> >
Re: "no route to host" from pkg_add
Hi, I am not sure you got that right. If you are an ISP the minimum assignment is /32 and you assigned /48 to end company and /56 to users. If you asked me that's a wasted, but that's what they suggest. For end users, a /64 would be plenty if you asked me and /56 for company would be plenty as well. But if you truly follow their policy, then well may be will run out there too like in IPv4 when it really start to be assigned, but anyway that's for a different discussion. Anyway see ARIN policy for it: https://www.arin.net/vault/policy/archive/ipv6_policy.html If you are not under ARIN, but RIPE, APNIC, AfriNIC, Lacnic, etc. They have similar policy. I would encourage you to check that if your problem is really that you got to small assignment. Unless your a very small ISP that got his assignment from your transit provider oppose to your own and get your own AS number, you will have plenty to work with. I really do not know of ANY ISP that get /56 for real. I got my assignment in 2003 and the policy still haven't changed. Hope this help you some. Daniel. On 8/10/18 9:12 PM, Walt wrote: > On August 10, 2018 3:57 PM, Henry Bonath he...@thebonaths.com wrote: > >> Also could it be that you are using IPv6, not IPv4? (and your IPv6 is >> missing its gateway) >> If the IPv6 gateway is bad/missing you'll get that "no route to host" >> message. > > I've encountered that issue before, but it isn't that big a problem with me. > As an ISP, the /56 we have been allocated is too small to be very useful so > I'm holding back on working on it much until such time as we get at least a > /48 if not a /40. I'd like to be able to assign each customer a /56 but > would settle for a /60 for each. With a /60, I could only handle sixteen > customers. We have a number of customers for whom a /64 wouldn't cut it at > all. > > I never have figured out the proper way to configure rtadvd.conf. In > particular, there is an addr and an rtprefix. > > addr is, according to the man page, "The address filled into Prefix field" > while rtprefix is " The prefix filled into the Prefix field of route > information option". And then there are the proper prefix lengths -- do I use > 64 or 56? It seems like prefixlen must be 64, but rtplen doesn't seem to make > much difference. > > And then there is the kea side for prefix delegations. > > Since I can just put the IPv6 gateway into /etc/mygate, it's not a problem > from the OpenBSD machines and it will never be a big issue if I can't get a > properly sized allocation of addresses from AT > > Walt > >
Re: "no route to host" from pkg_add
On 8/10/18 10:38 PM, Daniel Ouellet wrote: > Hi, > > I am not sure you got that right. > > If you are an ISP the minimum assignment is /32 and you assigned /48 to > end company and /56 to users. > > If you asked me that's a wasted, but that's what they suggest. > > For end users, a /64 would be plenty if you asked me and /56 for company > would be plenty as well. > > But if you truly follow their policy, then well may be will run out > there too like in IPv4 when it really start to be assigned, but anyway > that's for a different discussion. > > Anyway see ARIN policy for it: > > https://www.arin.net/vault/policy/archive/ipv6_policy.html > > If you are not under ARIN, but RIPE, APNIC, AfriNIC, Lacnic, etc. > > They have similar policy. > > I would encourage you to check that if your problem is really that you > got to small assignment. > > Unless your a very small ISP that got his assignment from your transit > provider oppose to your own and get your own AS number, you will have > plenty to work with. > > I really do not know of ANY ISP that get /56 for real. > > I got my assignment in 2003 and the policy still haven't changed. > > Hope this help you some. > > Daniel. > > > On 8/10/18 9:12 PM, Walt wrote: >> On August 10, 2018 3:57 PM, Henry Bonath he...@thebonaths.com wrote: >> >>> Also could it be that you are using IPv6, not IPv4? (and your IPv6 is >>> missing its gateway) >>> If the IPv6 gateway is bad/missing you'll get that "no route to host" >>> message. >> >> I've encountered that issue before, but it isn't that big a problem with me. >> As an ISP, the /56 we have been allocated is too small to be very useful so >> I'm holding back on working on it much until such time as we get at least a >> /48 if not a /40. I'd like to be able to assign each customer a /56 but >> would settle for a /60 for each. With a /60, I could only handle sixteen >> customers. We have a number of customers for whom a /64 wouldn't cut it at >> all. >> >> I never have figured out the proper way to configure rtadvd.conf. In >> particular, there is an addr and an rtprefix. >> >> addr is, according to the man page, "The address filled into Prefix field" >> while rtprefix is " The prefix filled into the Prefix field of route >> information option". And then there are the proper prefix lengths -- do I >> use 64 or 56? It seems like prefixlen must be 64, but rtplen doesn't seem to >> make much difference. >> >> And then there is the kea side for prefix delegations. >> >> Since I can just put the IPv6 gateway into /etc/mygate, it's not a problem >> from the OpenBSD machines and it will never be a big issue if I can't get a >> properly sized allocation of addresses from AT >> >> Walt >> >>
anybody installed angr, eg. pip install angr
It doesn't natively support OpenBSD.
Re: sshfs permission problem
When you run anything that writes something, that something will have your umask. If you run something as root, set root's umask before running it, not afterwards. Write a script that sets the umask and runs sshfs, then run the script using doas. On Fri, Aug 10, 2018 at 15:13, Hiltjo Posthuma wrote: > On Fri, Aug 10, 2018 at 10:38:52AM +0200, Hiltjo Posthuma wrote: >> On Fri, Aug 03, 2018 at 01:44:39PM +0200, Rudolf Sykora wrote: >> > Hello! >> > >> > I run >> > >> > doas sshfs syk...@pc109.fzu.cz: /home/ruda/mnt/fzu -o uid=1000 -o gid=1000 >> > >> > But then the mount point is owned (after the mounting) by root: >> > >> > drwx-- 1 root wheel 512 Aug 3 13:22 fzu >> > >> > Hence I cannot enter the directory as the usual (and wanted) user 'ruda'. >> > >> > 1) doas chmod 777 fzu does not help (does nothing) >> > 2) doas chown ruda:ruda fzu gives permission denied >> > >> > What can I do? >> > >> > Thanks >> > Ruda >> > >> >> Hi, >> >> I have the same issue here. >> >> chmod 777 changes the permisions, but seems to reset them automatically >> after a >> second or so. >> >> The umask suggestion doesn't work either unfortunately. >> >> On 6.3 this problem doesn't occur, but on -current it does. I'll try to >> bisect >> it later. >> >> -- >> Kind regards, >> Hiltjo >> > > I figured it out and it doesn't seem like a bug, just a changed behaviour. The > following commit changed it: > > CVS revision 1.47: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libfuse/fuse.c?rev=1.47=text/x-cvsweb-markup > > or git commit: > > commit 0f4d2db5a50672bad418a08041219503c0deeced > Author: helg > Date: Tue Jun 19 13:01:34 2018 + > > Changes the default mount behaviour so only the user that mounts the > file system can access it unless the allow_other mount options is > specified. The allow_other mount option makes the file system > available to other users just like any other mounted file system. > > ok mpi@ > > So the solution is to use the option: -o allow_other, for example: > sshfs -o allow_other user@host:dir /mnt/mount > > I hope this helps someone. > > -- > Kind regards, > Hiltjo
Re: "no route to host" from pkg_add
On August 10, 2018 3:57 PM, Henry Bonath he...@thebonaths.com wrote: > Also could it be that you are using IPv6, not IPv4? (and your IPv6 is > missing its gateway) > If the IPv6 gateway is bad/missing you'll get that "no route to host" > message. I've encountered that issue before, but it isn't that big a problem with me. As an ISP, the /56 we have been allocated is too small to be very useful so I'm holding back on working on it much until such time as we get at least a /48 if not a /40. I'd like to be able to assign each customer a /56 but would settle for a /60 for each. With a /60, I could only handle sixteen customers. We have a number of customers for whom a /64 wouldn't cut it at all. I never have figured out the proper way to configure rtadvd.conf. In particular, there is an addr and an rtprefix. addr is, according to the man page, "The address filled into Prefix field" while rtprefix is " The prefix filled into the Prefix field of route information option". And then there are the proper prefix lengths -- do I use 64 or 56? It seems like prefixlen must be 64, but rtplen doesn't seem to make much difference. And then there is the kea side for prefix delegations. Since I can just put the IPv6 gateway into /etc/mygate, it's not a problem from the OpenBSD machines and it will never be a big issue if I can't get a properly sized allocation of addresses from AT Walt
Re: "no route to host" from pkg_add
Also could it be that you are using IPv6, not IPv4? (and your IPv6 is missing its gateway) If the IPv6 gateway is bad/missing you'll get that "no route to host" message. On Fri, Aug 10, 2018 at 4:31 PM, Stuart Henderson wrote: > On 2018-08-07, traveller wrote: > > After OpenBSD, one too many “/“ > > That won't cause this. > > > > > On Aug 7, 2018, 11:16 AM -0700, Benjamin Walkenhorst < > walkenhorst.benja...@gmail.com>, wrote: > >> Hello everyone, > >> > >> I recently installed OpenBSD 6.3 in a VPS. > >> > >> In the last few days, I get an error message when running pkg_add, "no > route to host". > >> I have tried setting various hosts in /etc/installurl, but the problem > remains. > >> > >> When I run pkg_add, this is the output I get I get: > >> [20:02|root@myhost:~]# pkg_add nmap > >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages-stable/amd64/: > ftp: connect: No route to host > >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages/amd64/: ftp: > connect: No route to host > >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages/amd64/: empty > >> Can't find nmap > >> > >> When I try to ping the host specified in /etc/installurl or call > traceroute, everything seems to work as expected. > > How about "ftp -o- https://fastly.cdn.openbsd.org/pub/OpenBSD/;, > does that fail too? > > >
Re: "no route to host" from pkg_add
On 2018-08-07, traveller wrote: > After OpenBSD, one too many “/“ That won't cause this. > On Aug 7, 2018, 11:16 AM -0700, Benjamin Walkenhorst > , wrote: >> Hello everyone, >> >> I recently installed OpenBSD 6.3 in a VPS. >> >> In the last few days, I get an error message when running pkg_add, "no route >> to host". >> I have tried setting various hosts in /etc/installurl, but the problem >> remains. >> >> When I run pkg_add, this is the output I get I get: >> [20:02|root@myhost:~]# pkg_add nmap >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages-stable/amd64/: ftp: >> connect: No route to host >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages/amd64/: ftp: >> connect: No route to host >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages/amd64/: empty >> Can't find nmap >> >> When I try to ping the host specified in /etc/installurl or call traceroute, >> everything seems to work as expected. How about "ftp -o- https://fastly.cdn.openbsd.org/pub/OpenBSD/;, does that fail too?
Re: IPQoS values in sshd
On 2018-08-08, Mik J wrote: > Hello Daren, > Thank you for your answer, I didn't see it earlier today. > This change in current makes sense to me. > Regards > > > Le mercredi 8 août 2018 à 06:07:10 UTC+2, Darren Tucker > a écrit : > > On 8 August 2018 at 05:29, Mik J wrote: >> Does anyone knows what means lowdelay and thoughput for IPQoS parameter ? >> To what DSCP correspond these words > > From https://www.openssh.com/specs.html, which documents the most > recent release: they're the values specified in RFC1349, the first of > the dozen or so attempts to specify the meaning of those few bits > (RFCs 2474, 2597, 2598, 3168, 3246, 3260, 3662, 4301, 4594, 5865 and > 8325). > >> I did a capture when writing ls in my terminal and I see DSCP=cs0. >> I would have expected something else. > > The default values have been changed in -current but that change has > not yet made it to a release. From > https://man.openbsd.org/ssh_config.5: "The default is af21 > (Low-Latency Data) for interactive sessions and cs1 (Lower Effort) for > non-interactive sessions." > The old implementation using TOS pre-dates common use of DSCP and held on for quite some time, I think there may have been earlier concerns about network equipment not passing DSCP-marked packets properly. People using PF queues might like to note that "set queue" used with 2 queue names (e.g. "set queue (bulk, interactive)") only prioritises TOS=lowdelay, not DSCP. So people using this for prioritisation of interactive SSH traffic might want to consider either replacing the queues with "flow queues" (interactive packets are usually smaller and likely to below the "quantum" size and so have priority), or using "IPQoS lowdelay throughput" in ssh config.
vmctl / vmd
Dear readers, I just installed / syspatch a fresh 6.3 and i was not able to get the network working inside the alpine-virt-3.8.0-x86_64.iso kernel . I tried -L ( witch create a TAP with 100.64.id network :S ), and -n and -i with manual bridge setup. I see packets going through and arp replies but no reply inside the VM. (pf disabled and forwarding possible) is there any recent regression with the setup of alpine linux inside vmd ? Cheers -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
NSD update
I saw a week ago this commit from florian: https://marc.info/?l=openbsd-cvs=153294104203261 Shouldn't this apply also to 6.3 ? Just a doubt not a complain. Elias.
Re: sshfs permission problem
On Fri, Aug 10, 2018 at 10:38:52AM +0200, Hiltjo Posthuma wrote: > On Fri, Aug 03, 2018 at 01:44:39PM +0200, Rudolf Sykora wrote: > > Hello! > > > > I run > > > > doas sshfs syk...@pc109.fzu.cz: /home/ruda/mnt/fzu -o uid=1000 -o gid=1000 > > > > But then the mount point is owned (after the mounting) by root: > > > > drwx-- 1 root wheel512 Aug 3 13:22 fzu > > > > Hence I cannot enter the directory as the usual (and wanted) user 'ruda'. > > > > 1) doas chmod 777 fzu does not help (does nothing) > > 2) doas chown ruda:ruda fzu gives permission denied > > > > What can I do? > > > > Thanks > > Ruda > > > > Hi, > > I have the same issue here. > > chmod 777 changes the permisions, but seems to reset them automatically after > a > second or so. > > The umask suggestion doesn't work either unfortunately. > > On 6.3 this problem doesn't occur, but on -current it does. I'll try to bisect > it later. > > -- > Kind regards, > Hiltjo > I figured it out and it doesn't seem like a bug, just a changed behaviour. The following commit changed it: CVS revision 1.47: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libfuse/fuse.c?rev=1.47=text/x-cvsweb-markup or git commit: commit 0f4d2db5a50672bad418a08041219503c0deeced Author: helg Date: Tue Jun 19 13:01:34 2018 + Changes the default mount behaviour so only the user that mounts the file system can access it unless the allow_other mount options is specified. The allow_other mount option makes the file system available to other users just like any other mounted file system. ok mpi@ So the solution is to use the option: -o allow_other, for example: sshfs -o allow_other user@host:dir /mnt/mount I hope this helps someone. -- Kind regards, Hiltjo
Re: Probelm when building QGIS
Mark Prins-2 wrote
> On 27-07-18 14:03, tao wrote:
>> Rashad Kanavath wrote
>>> On Thu, Jul 26, 2018 at 12:36 AM tao
>>
>>> uponmyword@
>>
>>> wrote:
>>>
Hello,
I am in OpenBSD6.3. QGIS 2.18.17 in packages can not render style just
like
things in
http://openbsd-archive.7691.n7.nabble.com/qgis-bug-since-last-security-update-under-stable-td339707.html
So, I am trying to build QGIS 2.18.17 from source.
Succeeded to ccmake the source. But get error when make.
Here is the message:
tao$ make
[ 0%] Built target version
make: don't know how to make
/home/tao/Software/qgis/qgis-2.18.22/resources/function_help/json/rea
(prerequisite of: src/core/qgsexpression_texts.cpp)
Stop in .
*** Error 2 in . (CMakeFiles/Makefile2:1165
'src/core/CMakeFiles/qgis_core.dir/all')
*** Error 1 in /home/tao/Software/qgis/build-2.18.22 (Makefile:163
'all')
Tried to find the file mentioned above
"/home/tao/Software/qgis/qgis-2.18.22/resources/function_help/json/rea
",
but could not find anything.
Anyone has an idea?
>>>
>>> could you try gmake instead of make?
>>> make != gmake (unless you simlink or alias it)
>>
>> Could not find gmake. And also could not use cmake to build it.
>> I think make is the right one.
>>
>> I have to give up ^ \^
>
> snapshots already have qgis 3, so you can upgrade to current to get all
> the latest.
>
> since there is a port, you should start from there (eg. upgrade the qgis
> source version and start with that)
> -m
Thanks for your advice.
I have a a lot program which are build from source, so it is hard to upgrade
to current.
So I continued trying to build from source for several weeks.
FINDING:
Cmake can not treat file names with '(', ')', ' ', '$', so I replace them to
'_'.
And that made the build continued.
3 trials were made during the several weeks.
Trial 1. Build qgis from ports
Trial 2. Build qgis 2.18.22 from source file
Trial 3. Build qgis 3.2 from source file
All these trials failed with the same error:
[ 37%] Built target mdalprovider
/bin/sh: ../../output/bin/crssync: Permission denied
*** Error 1 in . (src/crssync/CMakeFiles/synccrsdb.dir/build.make:57
'src/crssync/CMakeFiles/synccrsdb': cd /home/tao/Software/qgis/build-3)
*** Error 2 in . (CMakeFiles/Makefile2:2841
'src/crssync/CMakeFiles/synccrsdb.dir/all')
*** Error 2 in /home/tao/Software/qgis/build-3.2.1 (Makefile:163 'all')
I totally did this under user mode, and permission right is okay like:
tao$ ./crssync
ksh: ./crssync: Permission denied
tao$ ls -l ./crssync
-rwxr-xr-x 1 tao tao 23149 Aug 9 14:18 ./crssync
This really beat me.
I also post in QGIS forum
http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Build-error-output-bin-crssync-Permission-denied-td5373914.html
Anyone can help?
Thanks god!
--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: lsof alternative for listing open files?
Ingo, Thank you for the detailed explanation. I wasn't thinking about atomically handling both at the same time. I also see why lsof in Linux can be deceiving. @marc Yes I think it is of pretty poor design. With Ingo's explanation and the fact they both read /proc and/or use lsof. And the learning continues. On Thursday, August 9, 2018, Ingo Schwarze wrote: > Hi Edward, > > Edward Lopez-Acosta wrote on Thu, Aug 09, 2018 at 06:29:04PM -0500: > >> I was looking to port bleachbit, system cleanup tool, to OpenBSD >> and one function is to make sure certain files are not in use before >> it proceeds. > > Strictly speaking, that is impossible due to a TOCTOU race condition. > You cannot do the check and the removal atomically in one step. > If you do the check and find that no process has it open, then by > the time you proceed to removing it, another process may have opened > it. Or even worse, someone may have deleted the old file or moved > it to a different name and a third person may have created a > completely new file for a completely different purpose with the old > name. None of that is OpenBSD-specific, by the way, the same > arguments hold on Linux. > > If you are willing to ignore the dangers posed by such race conditions, > then both fuser(1) and fstat(1) can be used: both take "file" > arguments. > > By the way, i just confirmed that the /proc/PID/fd/FDNUM filename > feature is indeed broken on Linux: > >$ uname -a > Linux donnerwolke.asta-kit.de 4.9.0-0.bpo.3-686 #1 SMP Debian > 4.9.30-2+deb9u5~bpo8+1 (2017-09-28) i686 GNU/Linux >$ cd /tmp >$ touch old.txt >$ tail -f old.txt > > In another terminal: > >$ cd /tmp >$ ln old.txt new.txt >$ rm old.txt >$ pgrep tail > 24052 >$ readlink /proc/24052/fd/3 > /tmp/old.txt (deleted) >$ lsof | grep new.txt >$ lsof | grep tail | grep 3r > /tmp/old.txt (deleted) > > So the kernel claims that "new.txt" is not open by any process, > and it also claims that the file open by tail(1) can no longer > be accessed via the file system. However, typing > >$ echo test >> new.txt > > in the second terminal makes "test" appear on the first terminal, > so it is a totally normal, fully functional file. > > So the description > > "Obsolete package: lsof (ancient software that doesn't work)" > > is indeed accurate. If lsof says a file isn't open, it may well > be open anyway. If lsof says a file was deleted, that may be an > outright lie. If lsof reports that a given process has a file open > with some name, then that name may be neither the name the process > used for opening the file nor any of the names the file has now, > though it usually is one of the names that the file may have had > at some undefined time in between. You cannot rely on any of those > statements from lsof because making such statements is just impossible > by the basic way how UNIX (including Linux) works, even without any > race conditions. And then you get the race conditions on top of > all that. Enjoy the mix! > > Yours, > Ingo >
Re: lsof alternative for listing open files?
On Thu, Aug 09, 2018 at 06:29:04PM -0500, Edward Lopez-Acosta wrote: > Hi Ingo, > > I was looking to port bleachbit, system cleanup tool, to OpenBSD and one > function is to make sure certain files are not in use before it proceeds. An > example would be cache files by a browser which would need closed. > > Beyond that though it was more of an educational exercise on my part as I > continue becoming familiar with OpenBSD and its workings. > > Edward Lopez-Acosta > > On 8/9/18 6:17 PM, Ingo Schwarze wrote: > >Hi Edward, > > > >Edward Lopez-Acosta wrote on Thu, Aug 09, 2018 at 05:41:04PM -0500: > > > >>I am aware of fuser and fstat but these seem to only give me inodes. > >>Is there an equivalent to the Linux application `lsof`? So, how is this actually a problem for the case at hand ? Is bleachbit so badly designed that it can't be made to work with fstat output ? If I understand your problem correctly, bleachbit is going to build a list of files it wants to remove, then try its best to check whether these files are actually in use by the system. There, inode/devno information is exactly what you need. You just need to coerce bleachbit into pairing that information correctly.
Re: sshfs permission problem
On Fri, Aug 03, 2018 at 01:44:39PM +0200, Rudolf Sykora wrote: > Hello! > > I run > > doas sshfs syk...@pc109.fzu.cz: /home/ruda/mnt/fzu -o uid=1000 -o gid=1000 > > But then the mount point is owned (after the mounting) by root: > > drwx-- 1 root wheel512 Aug 3 13:22 fzu > > Hence I cannot enter the directory as the usual (and wanted) user 'ruda'. > > 1) doas chmod 777 fzu does not help (does nothing) > 2) doas chown ruda:ruda fzu gives permission denied > > What can I do? > > Thanks > Ruda > Hi, I have the same issue here. chmod 777 changes the permisions, but seems to reset them automatically after a second or so. The umask suggestion doesn't work either unfortunately. On 6.3 this problem doesn't occur, but on -current it does. I'll try to bisect it later. -- Kind regards, Hiltjo
