Re: standard FAQ procedure ... in chroot
I don't think there is a word for chroot back. Once you limit yourself
into a chroot, you are stuck in it and get special treatment until you
exit. Apart from why mknod wants to fail inside chroots, having a simple
syscall being able to take you out of it would defeat the whole purpose, no?
2014-06-08 4:36 GMT+02:00 Andres Perera andre...@zoho.com:
The description of EINVAL in mknod(2) is wrong:
[EINVAL] The process is running within an alternate root
directory, as created by chroot(2).
Even if a process chroot()s back to /, it can't create a device node.
The program below exits with EINVAL:
#include sys/stat.h
#include unistd.h
int main() {
chroot(/);
if (mknod(/t, 0x21b6, 0x1600) == -1) /* stdin amd64 */
err(1, mknod);
}
On Sat, Jun 7, 2014 at 2:42 PM, Miod Vallat m...@online.fr wrote:
Is this some kind of security protection ?
of course... see mknod(2).
i read it and still does not understand.
Check the description of EINVAL.
--
May the most significant bit of your life be positive.
Re: standard FAQ procedure ... in chroot
On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson icepic...@gmail.com wrote:
I don't think there is a word for chroot back.
I don't think you read, understood, and executed the sample.
After chroot(/), or chroot(FOO), you can't mknod(2), therefore the
description is wrong.
Once you limit yourself
into a chroot, you are stuck in it and get special treatment until you
exit. Apart from why mknod wants to fail inside chroots, having a simple
syscall being able to take you out of it would defeat the whole purpose, no?
2014-06-08 4:36 GMT+02:00 Andres Perera andre...@zoho.com:
The description of EINVAL in mknod(2) is wrong:
[EINVAL] The process is running within an alternate root
directory, as created by chroot(2).
Even if a process chroot()s back to /, it can't create a device node.
The program below exits with EINVAL:
#include sys/stat.h
#include unistd.h
int main() {
chroot(/);
if (mknod(/t, 0x21b6, 0x1600) == -1) /* stdin amd64 */
err(1, mknod);
}
On Sat, Jun 7, 2014 at 2:42 PM, Miod Vallat m...@online.fr wrote:
Is this some kind of security protection ?
of course... see mknod(2).
i read it and still does not understand.
Check the description of EINVAL.
--
May the most significant bit of your life be positive.
Re: standard FAQ procedure ... in chroot
On Sun, Jun 08, 2014 at 02:59:08AM -0430, Andres Perera wrote: On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson icepic...@gmail.com wrote: I don't think there is a word for chroot back. I don't think you read, understood, and executed the sample. After chroot(/), or chroot(FOO), you can't mknod(2), therefore the description is wrong. What part is wrong? alternate directory might happen to be / itself. While that's silly to do it's still an alternate to an unchrooted /. -Otto
Re: new OpenSSL flaws
On Sat, 7 Jun 2014 14:19:33 +0400 Solar Designer so...@openwall.com wrote: On Sat, Jun 07, 2014 at 09:13:36AM +0200, Francois Ambrosini wrote: On Sat, 7 Jun 2014 07:04:47 +0400 Solar Designer so...@openwall.com wrote: Being on the distros list is not mandatory to receive advance notification of security issues. The list is just a tool. People reporting security issues to the distros list are encouraged to also notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects. You and others may want to know that ??? since yesterday ??? the OpenSSL wiki says otherwise. Quoting: If you would like advanced notice of vulnerabilities before they are released to the general public, then please join [http://oss-security.openwall.org/wiki/mailing-lists/distros Operating system distribution security contact lists] at OpenWall's OSS Security http://wiki.openssl.org/index.php?title=Security_Advisoriesdiff=1700oldid=1697 Thanks for letting me know. I wasn't aware of this. I don't know whether this wiki edit is authoritative for the OpenSSL project, but if it is it means that there's greater assurance those on distros list will continue to receive advance notification, and indeed it's simpler for the OpenSSL project to be able to notify more distro vendors at once. I don't see it as contradictory to what I wrote (quoted above): it doesn't say that those who haven't joined will definitely not be notified. I guess OpenSSL will maintain an additional list of who to notify, besides the distros list. As I said before, I can't speak for the OpenSSL project, though - so these are just guesses. My personal opinion is that if OpenBSD doesn't join the distros list, yet wants LibreSSL to be notified of OpenSSL security issues, OpenSSL should be notifying LibreSSL directly. I think it'd be helpful if LibreSSL nominates specific contact persons for that, along with PGP keys to use, and informs the OpenSSL project of that. (Use of PGP was mandatory in the recent advance notification offered to distros list.) Once that has been done, you'd have (more) reason to complain if you're not notified next time (but I hope you will be). Alexander I am a mere user who happened to spot an inconsistency and wanted to inform all parties. I will not comment on your guesses and opinions with information I do not have. I'll just state that I find your interpretation of the quote from the OpenSSL wiki rather optimistic, and give you the additional hint that a public statement from Mark Cox on Google+ goes against it (check the timeline post). I humbly think it was (and is) not the right time for guesses and I must confess my surprise at your response. I would have thought that, with the new responsibility given to the distro list, you would want to check with the OpenSSL people first.
Re: new OpenSSL flaws
On Sun, Jun 08, 2014 at 10:38:50AM +0200, Francois Ambrosini wrote: I am a mere user who happened to spot an inconsistency and wanted to inform all parties. I appreciate the constructive nature of your messages. I will not comment on your guesses and opinions with information I do not have. I'll just state that I find your interpretation of the quote from the OpenSSL wiki rather optimistic, It's not interpretation of the quote from their wiki. It's what I think they may and should do next time, given the circumstances, and an observation that the specific wording on the wiki technically does not contradict that. and give you the additional hint that a public statement from Mark Cox on Google+ goes against it (check the timeline post). On the contrary, the timeline shows that distros wasn't the only place OpenSSL sent a notification to. It also lists CERT/CC, ops-trust, and selected OpenSSL Foundation contracts. So OpenSSL did have an additional list of who to notify at that time. I think they may have such a list next time as well, and they may include LibreSSL on it. I humbly think it was (and is) not the right time for guesses and I must confess my surprise at your response. I would have thought that, with the new responsibility given to the distro list, you would want to check with the OpenSSL people first. I think I am in a better position to politely put light pressure on OpenSSL by stating my opinion publicly - namely, suggesting that they notify LibreSSL next time - regardless of how exclusive or not their planned use of the distros list might have been. I especially don't want to end up receiving any non-public information on their decision-making on who and how to notify, at which point I'd have to choose between two evils: reveal something they might disclose to me as (implied or stated) confidential or not informing you and the general public of that something if it's relevant to this discussion. As you can see, I've CC'ed this and the message you replied to, to Mark Cox, who managed OpenSSL's recent notification to distros list. I don't expect Mark to comment, but I'd like him to be aware. Mark - I hope you understand and agree with my position on this, as well as my reasoning for not coordinating this with OpenSSL in private first. Alexander
Re: new OpenSSL flaws
On Fri, Jun 06, 2014 at 10:26:48AM +0400, Solar Designer wrote: On Thu, Jun 05, 2014 at 04:38:24PM -0600, Theo de Raadt wrote: Kurt and Solar -- You are the primary contacts for the oss-security email list. Kurt is not. Sorry for going slightly off-topic, since this is not an OpenBSD thing, but I think it's appropriate to post the below in here. I think I need to clarify Kurt's exact role on oss-security and distros, given how suspicious people are and for the sake of transparency, even though I find this otherwise irrelevant to the issue at hand. BTW, I am not CC'ing this to Kurt because we managed to offend him so much that he doesn't want to receive these e-mails anymore. I'll post the main content of this message to oss-security as well, crediting Theo for the indirect reminder that more transparency is needed. On the linux-distros lists, Kurt is one of the members from Red Hat. He has no special privileges there. Kurt happens to be assigning CVE IDs from Red Hat's pool when people (those reporting vulnerabilities externally and/or other list members) ask for those. Kurt used to be assigning CVE IDs from Red Hat's pool on the public oss-security list as well. He was doing this for a long while, and I think is well recognized for that. Now MITRE takes care of this. Kurt currently has co-moderator privileges on oss-security, for the sole purpose of approving obviously on-topic messages from new addresses (not yet pre-approved), especially when I am not around (but usually I am). This minimizes delivery delays. This does not make Kurt a primary contact for the list - it's a rather limited and technical role, and an unpleasant one (since most messages in the moderation queue are spam), that Kurt at some point agreed to help with (but may resign from it anytime). Another current co-moderator on oss-security is Josh Bressers. Both Kurt and Josh are from Red Hat. The set of co-moderators is occasionally changing as people volunteer or resign. I think I should adopt a practice to announce such changes on oss-security itself right away, for the sake of transparency, even though the additional co-moderators (everyone besides me) only approve obvious on-topic messages and don't reject anything, so the responsibility for the list's policies remains mine (and I am the only one to blame). Conspiracy theorists may now say that this is a privilege that provides (a few hours of?) advance notification, and that messages may be deliberately delayed. I've heard such claims about Bugtraq (they might or might not be right). On oss-security, most messages are from pre-approved senders (so they get posted right away, with no ability for a co-moderator to even see them before they're sent to everyone), and the few that get into the moderation queue are approved quickly (from minutes to hours, but not days - whenever I or a co-moderator gets a chance to check our e-mail and confirm that the message is not spam and is on-topic). Such concerns could apply to Bugtraq (and do apply, as we've seen from some public criticism of Bugtraq) and to FD as well. I think they apply to oss-security to a smaller extent, because a lot of people (who post to oss-security) actually know that delays are usually non-existent or, when they do occur, are much smaller than those on Bugtraq (and likely smaller than those on FD as well, but I'd need to actually analyze the data to make sure). (I do think Bugtraq's delays are often unacceptable, regardless of why they occur.) As far as I'm aware, no oss-security posting was ever abusively delayed. There are some rare occasions where a posting is questionable (neither obviously on-topic nor obviously off-topic) and a moderation decision takes time to make - e.g., sometimes I contact the sender to have them clarify why their posting would be appropriate for oss-security. In those cases, as well as even for obviously off-topic messages, the co-moderators do nothing, and I handle these (almost always same day). IIRC, none of these were vulnerability reports in open source software. I do recall some that were vulnerability reports in closed source software (and this needed to be clarified before they got rejected as off-topic). When such misdirected reports happen, we don't make use of the information in the rejected postings (and the sender typically posts to FD or/and Bugtraq). Alexander
Re: OpenBSD 5.5 on mSATA SSD unit in PC Engines APU.1C - bad dir ino 2 at offset 0: mangled entry kernel panic
On 7 Jun 2014, at 23:35, Mattieu Baptiste mattie...@gmail.com wrote: On Sat, Jun 7, 2014 at 8:51 PM, JB M jbm.li...@gmail.com wrote: I'm having troubles installing OpenBSD 5.5 (amd64) on a mSATA SSD card ( http://pcengines.ch/msata16a.htm) PC Engines APU.1C device ( http://pcengines.ch/apu.htm) with the most recent BIOS version. I've made several attempts, using install55.fs copied to an SD card, with both 5.5-release and 5.5-current (June 6th snapshot). Most attempts have failed, either during the install (filesystem creation phase or during the sets extraction phase) or during the first boot after the initial install (case reported in this message). Same thing for me with : sd0 at scsibus1 targ 0 lun 0: ATA, SuperSSpeed mSAT, V462 SCSI3 0/direct fixed t10.ATA_SuperSSpeed_mSATA_SSD_16GB_YTAF140500376_ sd0: 15258MB, 512 bytes/sector, 31248704 sectors Installing on a USB drive solved the problem. I know it’s no consolation to you but using a Kingston 30 GB mSATA from amazon works perfectly. The APU is on the May bios and I’ve had no issues. Didn’t the PCEngines mSATA drive have problems in general? There’s a mention on here about issues with the a version - is that yours? http://pcengines.ch/msata16b.htm Regards - Nick OpenBSD 5.5-current (GENERIC.MP) #150: Mon May 26 11:50:31 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2098520064 (2001MB) avail mem = 2033942528 (1939MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (6 entries) bios0: vendor coreboot version SageBios_PCEngines_APU-45 date 04/05/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2 (PBR5) acpiprt4 at acpi0: bus 3 (PBR6) acpiprt5 at acpi0: bus -1 (PBR7) acpiprt6 at acpi0: bus 5 (PE20) acpiprt7 at acpi0: bus -1 (PE21) acpiprt8 at acpi0: bus -1 (PE22) acpiprt9 at acpi0: bus -1 (PE23) acpiprt10 at acpi0: bus 0 (PCI0) acpiprt11 at acpi0: bus 4 (PIBR) acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpibtn0 at acpi0: PWRB cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00 ppb0 at pci0 dev 4 function 0 AMD AMD64 14h PCIE rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:33:06:c8 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4 ppb1 at pci0 dev 5 function 0 AMD AMD64 14h PCIE rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:33:06:c9 rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 4 ppb2 at pci0 dev 6 function 0 AMD AMD64 14h PCIE rev 0x00: msi pci3 at ppb2 bus 3 re2 at pci3 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:33:06:ca rgephy2 at re2 phy 7: RTL8169S/8110S PHY, rev. 4 ahci0 at pci0 dev 17 function 0 ATI SBx00 SATA rev 0x40: apic 2 int 19, AHCI 1.2 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: ATA, KINGSTON SMS200S, 524A SCSI3 0/direct fixed naa.50026b724116179f sd0: 28626MB, 512 bytes/sector, 58626288
y2k38 question
Hi, While updating an older system (5.4) today to current I wasn't sure if I've already passed the bump to 64bit time_t. While searching for it I got into this: http://daemonforums.org/showthread.php?t=7021 which has a simple script to check. # date -r 2147483648 Tue Jan 19 05:14:08 EET 2038 which is fine and # touch -t 203801201234 y2k38-test # ls -ld y2k38-test -rw-r--r-- 1 root wheel 0 Dec 14 1901 y2k38-test # stat y2k38-test 1024 51995 -rw-r--r-- 1 root wheel 0 0 Dec 14 17:06:36 1901 Dec 14 17:06:36 1901 Jun 8 14:37:13 2014 16384 0 0 y2k38-test which is not so fine. What am I missing here? G ps. these are on a current OpenBSD 5.5-current (GENERIC.MP) #173: Sat Jun 7 11:02:46 MDT 2014
Radeondrm on OpenBSD 5.5 stable
Is there a known problem with the Radeon driver on OpenBSD 5.5 AMD64 stable? I noticed the text on the console was scrolling very slow while src.tar.gz was extracting. I didn't time it, but it seem to take 2 to 3 times as long to return to the command line compared to extracting the same file on a slower i386 machine. Syslog output is below. Jun 7 22:47:09 gateway /bsd: radeondrm0: VRAM: 128M 0xD000 - 0xD7FF (128M used) Jun 7 22:47:09 gateway /bsd: radeondrm0: GTT: 512M 0xA000 - 0xBFFF Jun 7 22:47:09 gateway /bsd: drm: PCIE GART of 512M enabled (table at 0x0891F000). Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_cp_init] *ERROR* radeon: cp isn't working (-22). Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:rs690_startup] *ERROR* failed initializing CP (-22). Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:rs690_init] *ERROR* Disabling GPU acceleration Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_gui_wait_for_idle] *ERROR* radeon: wait for empty RBBM fifo failed ! Bad things might happen. Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_cp_disable] *ERROR* Failed to wait GUI idle while programming pipes. Bad things might happen. Jun 7 22:47:09 gateway /bsd: drm: radeon: cp finalized Jun 7 22:47:09 gateway /bsd: radeondrm0: 1600x900 Jun 7 22:47:09 gateway /bsd: wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 Jun 7 22:47:09 gateway /bsd: wsdisplay0: screen 1-5 added (std, vt100 emulation)Jun 7 22:47:09 gateway /bsd: radeondrm0: VRAM: 128M 0xD000 - 0xD7FF (128M used) Jun 7 22:47:09 gateway /bsd: radeondrm0: GTT: 512M 0xA000 - 0xBFFF Jun 7 22:47:09 gateway /bsd: drm: PCIE GART of 512M enabled (table at 0x0891F000). Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_cp_init] *ERROR* radeon: cp isn't working (-22). Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:rs690_startup] *ERROR* failed initializing CP (-22). Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:rs690_init] *ERROR* Disabling GPU acceleration Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_gui_wait_for_idle] *ERROR* radeon: wait for empty RBBM fifo failed ! Bad things might happen. Jun 7 22:47:09 gateway /bsd: error: [drm:pid0:r100_cp_disable] *ERROR* Failed to wait GUI idle while programming pipes. Bad things might happen. Jun 7 22:47:09 gateway /bsd: drm: radeon: cp finalized Jun 7 22:47:09 gateway /bsd: radeondrm0: 1600x900 Jun 7 22:47:09 gateway /bsd: wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 Jun 7 22:47:09 gateway /bsd: wsdisplay0: screen 1-5 added (std, vt100 emulation)
Re: standard FAQ procedure ... in chroot
On Sun, Jun 8, 2014 at 4:21 AM, Otto Moerbeek o...@drijf.net wrote: On Sun, Jun 08, 2014 at 02:59:08AM -0430, Andres Perera wrote: On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson icepic...@gmail.com wrote: I don't think there is a word for chroot back. I don't think you read, understood, and executed the sample. After chroot(/), or chroot(FOO), you can't mknod(2), therefore the description is wrong. What part is wrong? alternate directory might happen to be / itself. While that's silly to do it's still an alternate to an unchrooted /. -Otto AS a victim, the only documentation improve would to point this into the mknod(8) man page, the alternate root explanation was ok, even if in a chrooted environnement mknod return einval would thwart the sillly(?) chroot / case. Creation of /dev/wd* or /dev/sd* could defeat the chroot, but creating /dev/stdin ... does that mean vnconfig is also not possible ? -- - () ascii ribbon campaign - against html e-mail /\
Re: y2k38 question
On Sun, Jun 08, 2014 at 02:41:50PM +0300, Kapetanakis Giannis wrote: Hi, While updating an older system (5.4) today to current I wasn't sure if I've already passed the bump to 64bit time_t. While searching for it I got into this: http://daemonforums.org/showthread.php?t=7021 which has a simple script to check. # date -r 2147483648 Tue Jan 19 05:14:08 EET 2038 which is fine and # touch -t 203801201234 y2k38-test # ls -ld y2k38-test -rw-r--r-- 1 root wheel 0 Dec 14 1901 y2k38-test # stat y2k38-test 1024 51995 -rw-r--r-- 1 root wheel 0 0 Dec 14 17:06:36 1901 Dec 14 17:06:36 1901 Jun 8 14:37:13 2014 16384 0 0 y2k38-test which is not so fine. What am I missing here? ffs1 is not capable of storing 64 bit timestamps. ffs2 is. -Otto
Re: y2k38 question
On 08/06/14 17:02, Otto Moerbeek wrote: On Sun, Jun 08, 2014 at 02:41:50PM +0300, Kapetanakis Giannis wrote: # touch -t 203801201234 y2k38-test # ls -ld y2k38-test -rw-r--r-- 1 root wheel 0 Dec 14 1901 y2k38-test # stat y2k38-test 1024 51995 -rw-r--r-- 1 root wheel 0 0 Dec 14 17:06:36 1901 Dec 14 17:06:36 1901 Jun 8 14:37:13 2014 16384 0 0 y2k38-test which is not so fine. What am I missing here? ffs1 is not capable of storing 64 bit timestamps. ffs2 is. -Otto That makes sense. Thanks G
Re: standard FAQ procedure ... in chroot
On Sun, Jun 8, 2014 at 3:51 AM, Otto Moerbeek o...@drijf.net wrote:
On Sun, Jun 08, 2014 at 02:59:08AM -0430, Andres Perera wrote:
On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson icepic...@gmail.com wrote:
I don't think there is a word for chroot back.
I don't think you read, understood, and executed the sample.
After chroot(/), or chroot(FOO), you can't mknod(2), therefore the
description is wrong.
What part is wrong?
alternate directory might happen to be / itself.
Even though it's the same directory as the previous root directory?
How is it alternate, then?
What's alternating, other than the root directory, which is *the same*?
Either make this fd_rdir check a string comparison in addition to a
null-pointer check or change the docs instead of being confusing:
int
domknodat(struct proc *p, int fd, const char *path, mode_t mode, dev_t dev)
{
struct vnode *vp;
struct vattr vattr;
int error;
struct nameidata nd;
if ((error = suser(p, 0)) != 0)
return (error);
if (p-p_fd-fd_rdir)
return (EINVAL);
While that's silly
to do it's still an alternate to an unchrooted /.
-Otto
Adding RPKI/ROA support to OpenBGPd
Hello all,
I am in the process of adding RPKI/ROA (RFC 6810/RFC 6811) support to
OpenBGPd. I have an almost working PoC but I'd like to hear your opinion
and discuss implementation details with misc@ before going further.
First of all, here is what RPKI-enabled bgpd.conf looks like :
8--
AS 65530
router-id 10.0.0.102
fib-update yes
Transitv4=10.0.0.1
validator 2001:db8::102 {
port 8282
poll-interval 300
}
neighbor $Transitv4 {
descr ROA Lab
remote-as 65531
announce none
}
#match from any rpki-invalid set localpref 80
deny from any rpki-invalid
match from any rpki-valid set localpref 120
match from any rpki-not-found set localpref 99
8--
Then what bgpctl show rib looks like :
(with match from any rpki-invalid set localpref 80)
8--
# bgpctl sho rib
flags: * = Valid, = Selected, I = via IBGP, A = Announced, S = Stale,
v = RPKI valid, i = RPKI invalid, u = RPKI unknown
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
u*10.0.0.0/20 10.0.0.199 0 65530 i
u*10.0.0.0/24 10.0.0.199 0 65530 i
i*93.187.228.0/24 10.0.0.180 0 65530 i
v*185.22.128.0/22 10.0.0.1 120 0 65530 i
8--
(with deny from any rpki-invalid)
8--
# bgpctl sho rib
flags: * = Valid, = Selected, I = via IBGP, A = Announced, S = Stale,
v = RPKI valid, i = RPKI invalid, u = RPKI unknown
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
u*10.0.0.0/20 10.0.0.199 0 65530 i
u*10.0.0.0/24 10.0.0.199 0 65530 i
v*185.22.128.0/22 10.0.0.1 120 0 65530 i
8--
So, we have a new keyword (validator) that is used to define a
validation server. Inside that, we have 3 parameters :
- port (defaults to 323 - between 1-65535) : tcp port of the validator
- poll-interval (defaults to 3600 - between 60-3600) : number of seconds
before polling the validator for changes.
That's for the visible part :)
Now, let's look under the hood.
OpenBGPd has now a rpki-client, which connects to a validator, get
validated objects from the validator and put them in a list of validated
ROA (VRP). It then compares every prefix with the content of the VRP and
filters accordingly.
The validator connection is handled by session.c, it is close to
neighbor connection process. It has 4 states :
- init : the beginning
- connecting : validator was contacted and is processing the 3-way handshake
- syncing : the rpki-client is receiving ROAs.
- synced : the rpki-client is now waiting for updates from the validator
(or until poll-interval expires).
While syncing the rpki-client sends each objects to rde.c. rde.c stores
the objects in a RB-list (one for IPv4 prefixes, one for IPv6 prefixes)
and removes if it is a withdrawal. when the rpki-client receives a End
of Data PDU, it sends a command to rde.c to start validation of known
peer prefixes (from rib[0]).
The VRP size is ~12k, the RIB size is ~530k so that's a lot to check.
If you have any implementation advice, I'm all hear :)
The major difficulty is to no put too much load on the router when
comparing between VRP and RIB and how to update FIB when VRP changes.
Regards,
Denis
New install
Hi all, I just installed OpenBSD 5.5 on a sparc64 $ uname -a OpenBSD test.home 5.5 GENERIC.MP#173 sparc64 I then issued the following commands: cd /usr/ export CVSROOT=anon...@anoncvs.openbsd.org:/cvs cvs -d$CVSROOT up -rOPENBSD_5_5 -Pd Couple of hours later: cvs server: Updating libexec U libexec/Makefile U libexec/Makefile.inc cvs server: Updating libexec/atrun cvs [update aborted]: could not chdir to libexec/comsat: Not a directory cd /usr/libexec ls -la $ ls -la total 5416 drwxr-xr-x 10 root wheel1536 Jun 8 11:48 . drwxr-xr-x 24 root wheel 512 Jun 8 12:33 .. drwxr-xr-x 2 root wheel 512 Jun 8 11:48 CVS -rw-r--r-- 1 root wheel 598 Dec 4 2013 Makefile -rw-r--r-- 1 root wheel 87 Jan 28 2001 Makefile.inc drwxr-xr-x 3 root wheel 512 Jun 8 11:48 atrun drwxr-x--- 2 root auth 512 Mar 4 16:03 auth -r-xr-xr-x 1 root bin 16824 Mar 4 16:03 comsat -r-xr-xr-x 1 root bin217864 Mar 4 16:05 cpp drwxr-xr-x 3 root wheel 512 Mar 4 16:05 cvs Thanks
Re: standard FAQ procedure ... in chroot
It feels like you are trying to convince someone that
chroot(/);
equals not being chrooted at all.
In my view several things happen when a pid is started in a chroot,
including
1. the dir used as a parameter for the chroot will always be its own parent
dir so that you may never again go above it. You may (haven't checked)
chroot yourself lower again, but not stop the chroot.
2. You may not create device nodes since that would make it easy to defeat
the chroot if root.
This list may be far longer, but I don't think the docs need fixing for the
chroot(/); case when mknod:ing.
2014-06-08 17:44 GMT+02:00 Andres Perera andre...@zoho.com:
On Sun, Jun 8, 2014 at 3:51 AM, Otto Moerbeek o...@drijf.net wrote:
On Sun, Jun 08, 2014 at 02:59:08AM -0430, Andres Perera wrote:
On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson icepic...@gmail.com
wrote:
I don't think there is a word for chroot back.
I don't think you read, understood, and executed the sample.
After chroot(/), or chroot(FOO), you can't mknod(2), therefore the
description is wrong.
What part is wrong?
alternate directory might happen to be / itself.
Even though it's the same directory as the previous root directory?
How is it alternate, then?
What's alternating, other than the root directory, which is *the same*?
Either make this fd_rdir check a string comparison in addition to a
null-pointer check or change the docs instead of being confusing:
int
domknodat(struct proc *p, int fd, const char *path, mode_t mode, dev_t dev)
{
struct vnode *vp;
struct vattr vattr;
int error;
struct nameidata nd;
if ((error = suser(p, 0)) != 0)
return (error);
if (p-p_fd-fd_rdir)
return (EINVAL);
While that's silly
to do it's still an alternate to an unchrooted /.
-Otto
--
May the most significant bit of your life be positive.
Re: New install
cd /usr/ export CVSROOT=anon...@anoncvs.openbsd.org:/cvs cvs -d$CVSROOT up -rOPENBSD_5_5 -Pd You should run this in /usr/src, not /usr. And you should not run this command as root either.
Re: standard FAQ procedure ... in chroot
On Sun, Jun 8, 2014 at 12:16 PM, Janne Johansson icepic...@gmail.com wrote:
It feels like you are trying to convince someone that
chroot(/);
equals not being chrooted at all.
Not at all. I'm trying to convince someone to explain what chrooted
means, preferably without changing current semantics.
chroot(2), for instance, doesn't mention the term alternate root
directory as a well-defined state that includes--but does not limit
itself to--the invoking process' root directory, nor does chroot(2)
reference or allude to the creation of an alternate root
directory.
Am I supposed to consider mknod(2)'s wording authoritative over chroot(2)'s?
Maybe the first step is recognizing that the documentation is unclear
on the subject.
In my view several things happen when a pid is started in a chroot,
including
1. the dir used as a parameter for the chroot will always be its own parent
dir so that you may never again go above it. You may (haven't checked)
chroot yourself lower again, but not stop the chroot.
2. You may not create device nodes since that would make it easy to defeat
the chroot if root.
This list may be far longer, but I don't think the docs need fixing for the
chroot(/); case when mknod:ing.
2014-06-08 17:44 GMT+02:00 Andres Perera andre...@zoho.com:
On Sun, Jun 8, 2014 at 3:51 AM, Otto Moerbeek o...@drijf.net wrote:
On Sun, Jun 08, 2014 at 02:59:08AM -0430, Andres Perera wrote:
On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson icepic...@gmail.com
wrote:
I don't think there is a word for chroot back.
I don't think you read, understood, and executed the sample.
After chroot(/), or chroot(FOO), you can't mknod(2), therefore the
description is wrong.
What part is wrong?
alternate directory might happen to be / itself.
Even though it's the same directory as the previous root directory?
How is it alternate, then?
What's alternating, other than the root directory, which is *the same*?
Either make this fd_rdir check a string comparison in addition to a
null-pointer check or change the docs instead of being confusing:
int
domknodat(struct proc *p, int fd, const char *path, mode_t mode, dev_t dev)
{
struct vnode *vp;
struct vattr vattr;
int error;
struct nameidata nd;
if ((error = suser(p, 0)) != 0)
return (error);
if (p-p_fd-fd_rdir)
return (EINVAL);
While that's silly
to do it's still an alternate to an unchrooted /.
-Otto
--
May the most significant bit of your life be positive.
Re: Weird disk problem
On 2014-06-05, David Vasek va...@fido.cz wrote: Did you try smartctl from smartmontools for a more detailed report? I assume there is a 1000-page SMART spec somewhere that would come in handy for interpreting the responses? My favourite are: smartctl -a /dev/sd1c smartctl -l scttemp /dev/sd1c Temperature is fine, never exceeded the limits. smartctl -t short /dev/sd1c Not supported, it seems. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Weird disk problem
On 2014-06-05, STeve Andre' and...@msu.edu wrote: I think you are relying on the smart system too much. Not at all, but I knew people would immediately direct me to it. Certainly try what David said, but it's obvious that the disk is sick despite what the smart system may say. I got a replacement disk and I'm now trying to get the data off the old one. (Nothing really important.) That is proceeding fitfully. There are spurts of 65 MB/s and then there are stretches of XXX kB/s, XX kB/s, down to 5 kB/s. At the current average rate it will be going for five or six days, assuming the disk survives that long. Whatever's wrong with it, it's a tenacious little bugger. There still hasn't been a single hard read error. Anyway, I guess we can close the topic. -- Christian naddy Weisgerber na...@mips.inka.de
hplip
I bought a new, cheap HP Deskjet 2540 printer (usb and wireless). The wireless setup was a touch button WPS first on the printer and then on the Virgin Superhub2 (some netgear job that I don't like - ought to have stayed with my old ISP). That worked but the router webpage did not show the printer at all. sudo nmap -T4 192/168/0.0/28 showed it up as 192.168.0.3 So then I installed hplip and ran sudo hp-setup -i CN43O3F1CS that being the serial number of the printer. It failed to connect on the net interface but reported it as installed when I tried usb. However hp-testpage failed to connect to the printer. GOS reported a similar problem on 25 April # Apr 25 13:44:29 stable-8 hp[22206]: prnt/backend/hp.c 745: ERROR: open device failed stat=12: hp:/usb/psc_1200_series?serial=HU44HGQ7JPT0 So I hunted around for answers for several days. hplip website was no use. hp-check -t produced a 12.9k hp-check.log The interesting bit was given by $ grep libusb hp-check.log libusb01-build=no info: libusb USB-Lib REQUIRED - 1.0 OK - Am I interpreting this correctly that to get usb support I need to recompile the port and build libusb01? This is not urgent as the printer works on socket://192.168.0.3:9100 because of HP Jetdirect. ipp may work also but I've not tested. The printer webserver is also accessible by putting 192.168.0.3 into a browser. This means I can also scan using the webscan facility. So it is just nice to have, for me anyhow. Thanks Moss
issues with amd64 on Apple MacPro
I've been using amd64 snapshots on an early MacPro and had mixed results. The base itself is solid. Many packages less so. Browsers in particular (I mostly use xombrero with firefox as a fallback) are prone to crashing w/core files. In the snapshot I tried last night (dmesg below) a new behavior is that the browser will lock up, run away with 3 of the 4 CPUs, and even kill -9 doesn't work. I've seen this with both xombrero and firefox today. As I'm trying to use this as a desktop workstation this gets to be annoying. Is there any reason to think that this system might do better with i386 snapshots? Allan OpenBSD 5.5-current (GENERIC.MP) #173: Sat Jun 7 11:02:46 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 10715041792 (10218MB) avail mem = 10421030912 (9938MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe00f0 (73 entries) bios0: vendor Apple Computer, Inc. version MP11.88Z.005C.B08.0707021221 date 07/02/07 bios0: Apple Computer, Inc. MacPro1,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT ECDT FACP HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices P2P5(S4) P2P3(S4) ARPT(S4) RP04(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AC9M(S4) EC__(S3) NRP4(S4) SRP1(S4) SRP3(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.35 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 7 (application processor) cpu2: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF cpu2: 4MB 64b/line 16-way L2 cache cpu2: smt 0, core 1, package 3 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF cpu3: 4MB 64b/line 16-way L2 cache cpu3: smt 0, core 0, package 3 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xd000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 2 (P1P2) acpiprt3 at acpi0: bus 5 (P2P5) acpiprt4 at acpi0: bus 3 (P2P3) acpiprt5 at acpi0: bus 15 (RP04) acpiprt6 at acpi0: bus 16 (PCIB) acpiprt7 at acpi0: bus 8 (NRP4) acpiprt8 at acpi0: bus 12 (SRP1) acpiprt9 at acpi0: bus 14 (SRP3) acpicpu0 at acpi0: C1 acpicpu1 at acpi0: C1 acpicpu2 at acpi0: C1 acpicpu3 at acpi0: C1 acpibtn0 at acpi0: PWRB memory map conflict 0xfff9/0x3 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 5000X Host rev 0x30 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE x8 rev 0x30 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01: msi pci3 at ppb2 bus 3 ppb3 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01: msi pci4 at ppb3 bus 4 ppb4 at pci2 dev 2 function 0 Intel 6321ESB PCIE rev 0x01 pci5 at ppb4 bus 5 em0 at pci5 dev 0 function 0 Intel 80003ES2 rev 0x01: msi, address 00:17:f2:03:41:94 em1 at pci5 dev 0 function 1 Intel 80003ES2 rev 0x01: msi, address 00:17:f2:03:41:95 Intel 6321ESB IOxAPIC rev 0x01 at pci1 dev 0 function 1 not configured ppb5 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci6 at ppb5 bus 6 pchb1 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0x30 ppb6 at pci0 dev 4 function 0 Intel 5000 PCIE x16 rev 0x30: msi pci7 at ppb6 bus 8 radeondrm0 at pci7 dev 0 function 0 ATI Radeon HD 4670 rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci7 dev 0 function 1 ATI Radeon HD 4000 HD Audio rev 0x00: msi azalia0: no supported codecs pchb2 at pci0 dev 5 function 0 Intel 5000 PCIE rev 0x30
Problem compiling kde4/libs
Trying to compile kde4's libs I get the below error. I see it's related to the recent ssl changes, but I don't see what I need to do to get around this. The system is 5.5-current, compiled on June 4th. I love the GNU messasge, too. ;-) What am I missing here? I haven't found anything about this. Thanks, STeve Andre' /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/qt4/libQtCore.so.9.0: warning: rand_r() isn't random; consider using arc4random() /usr/local/lib/qt4/libQtCore.so.9.0: warning: rand() isn't random; consider using arc4random() /usr/local/lib/qt4/libQtCore.so.9.0: warning: srand() seed choices are invariably poor /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: strcat() is almost always misused, please use strlcat() /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: sprintf() is often misused, please use snprintf() /usr/local/lib/libglib-2.0.so.4000.0: warning: stpcpy() is dangerous GNU crap; don't use it /usr/local/lib/libglib-2.0.so.4000.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/lib/libkrb5.so.20.0: undefined reference to `RAND_egd_bytes' collect2: ld returned 1 exit status ninja: build stopped: subcommand failed. *** Error 1 in . (/usr/ports/devel/cmake/cmake.port.mk:31 'do-build': @cd /usr/ports/pobj/kdelibs-4.11.5/build-amd64 exec /usr/bin/env -i...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2691 '/usr/ports/pobj/kdelibs-4.11.5/build-amd64/.build_done') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1890 '/usr/ports/packages/amd64/all/kdelibs-4.11.5p8.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2443 '_internal-package') *** Error 1 in /usr/ports/x11/kde4/libs (/usr/ports/infrastructure/mk/bsd.port.mk:2423 'package')
OpenBSD GSoC 2014 accepted projects status
Hello everyone, For a few weeks i was wondering what happened to the projects that have been accepted for this year's Google Summer of Code. I have run a quick search but haven't found anything meaningful (whether there are any reports of progress, where the in-progress code is hosted etc). I am highly interested in the accepted projects and would like to be able to witness how stuff progress (esp. if they really are to be adopted by the end of GSoC). -- Regards, Alex-P. Natsios (a.k.a Drakevr)
Re: OpenBSD GSoC 2014 accepted projects status
On Mon, Jun 9, 2014, at 2:22, Alex-P. Natsios wrote: Hello everyone, For a few weeks i was wondering what happened to the projects that have been accepted for this year's Google Summer of Code. I have run a quick search but haven't found anything meaningful (whether there are any reports of progress, where the in-progress code is hosted etc). I am highly interested in the accepted projects and would like to be able to witness how stuff progress (esp. if they really are to be adopted by the end of GSoC). -- Regards, Alex-P. Natsios (a.k.a Drakevr) Sure. Hi! I'm Greg, currently working on the DHCP configuration parsing code, migrating it from a manual parser to a yacc(1) one. I am mostly talking to krw@ and matthieu@ right now but hopefully I can talk on tech@ about my work soon. If you have any questions, please ask away! -- gregoire
Re: Problem compiling kde4/libs
On 06/09/14 01:16, STeve Andre' wrote: Trying to compile kde4's libs I get the below error. I see it's related to the recent ssl changes, but I don't see what I need to do to get around this. The system is 5.5-current, compiled on June 4th. I love the GNU messasge, too. ;-) What am I missing here? I haven't found anything about this. Thanks, STeve Andre' /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/qt4/libQtCore.so.9.0: warning: rand_r() isn't random; consider using arc4random() /usr/local/lib/qt4/libQtCore.so.9.0: warning: rand() isn't random; consider using arc4random() /usr/local/lib/qt4/libQtCore.so.9.0: warning: srand() seed choices are invariably poor /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: strcat() is almost always misused, please use strlcat() /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: sprintf() is often misused, please use snprintf() /usr/local/lib/libglib-2.0.so.4000.0: warning: stpcpy() is dangerous GNU crap; don't use it /usr/local/lib/libglib-2.0.so.4000.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/lib/libkrb5.so.20.0: undefined reference to `RAND_egd_bytes' collect2: ld returned 1 exit status ninja: build stopped: subcommand failed. *** Error 1 in . (/usr/ports/devel/cmake/cmake.port.mk:31 'do-build': @cd /usr/ports/pobj/kdelibs-4.11.5/build-amd64 exec /usr/bin/env -i...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2691 '/usr/ports/pobj/kdelibs-4.11.5/build-amd64/.build_done') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1890 '/usr/ports/packages/amd64/all/kdelibs-4.11.5p8.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2443 '_internal-package') *** Error 1 in /usr/ports/x11/kde4/libs (/usr/ports/infrastructure/mk/bsd.port.mk:2423 'package') See current 2014/04/22 - kerberosV removed libkrb5 should have been removed
Re: Problem compiling kde4/libs
On 06/08/14 20:45, Nigel Taylor wrote: On 06/09/14 01:16, STeve Andre' wrote: Trying to compile kde4's libs I get the below error. I see it's related to the recent ssl changes, but I don't see what I need to do to get around this. The system is 5.5-current, compiled on June 4th. I love the GNU messasge, too. ;-) What am I missing here? I haven't found anything about this. Thanks, STeve Andre' /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/qt4/libQtCore.so.9.0: warning: rand_r() isn't random; consider using arc4random() /usr/local/lib/qt4/libQtCore.so.9.0: warning: rand() isn't random; consider using arc4random() /usr/local/lib/qt4/libQtCore.so.9.0: warning: srand() seed choices are invariably poor /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: strcat() is almost always misused, please use strlcat() /usr/ports/pobj/kdelibs-4.11.5/build-amd64/lib/libkdecore.so.50.1: warning: sprintf() is often misused, please use snprintf() /usr/local/lib/libglib-2.0.so.4000.0: warning: stpcpy() is dangerous GNU crap; don't use it /usr/local/lib/libglib-2.0.so.4000.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/lib/libkrb5.so.20.0: undefined reference to `RAND_egd_bytes' collect2: ld returned 1 exit status ninja: build stopped: subcommand failed. *** Error 1 in . (/usr/ports/devel/cmake/cmake.port.mk:31 'do-build': @cd /usr/ports/pobj/kdelibs-4.11.5/build-amd64 exec /usr/bin/env -i...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2691 '/usr/ports/pobj/kdelibs-4.11.5/build-amd64/.build_done') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1890 '/usr/ports/packages/amd64/all/kdelibs-4.11.5p8.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2443 '_internal-package') *** Error 1 in /usr/ports/x11/kde4/libs (/usr/ports/infrastructure/mk/bsd.port.mk:2423 'package') See current 2014/04/22 - kerberosV removed libkrb5 should have been removed ha! of course! I will do that. Thank you, Nigel. --STeve Andre'
Re: issues with amd64 on Apple MacPro
I've been using one (early 2008 model?) for several weeks now. Suspend works, hw.setperf works, radeondrm works for X, internal audio doesn't seem to work, but I can't say I've spent a long time trying to make it work. There are a few minor issues, like the console framebuffer doesn't take up the whole screen [1] (although it does expand to more than 80x24), and sometimes in the consoles, all keyboard entry is garbled, and an (obviously incorrect, although possibly what it would be if I held alt) keypress is registered on both keyup and kendown, which makes it impossible to login or even switch back to X. [2] But overall, it's pretty nice. It builds the kernel from scratch in just over 5 minutes, and hardware support is good enough for what I need. [1] https://i.imgur.com/BAoPCKM.jpg [2] https://i.imgur.com/O4XE8Gp.jpg OpenBSD 5.5-current (CAPSICUM.MP) #16: Sun Jun 8 20:01:35 EDT 2014 r...@macpro.home:/usr/src/sys/arch/amd64/compile/CAPSICUM.MP real mem = 8563191808 (8166MB) avail mem = 8326459392 (7940MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0e60 (94 entries) bios0: vendor Apple Inc. version MP31.88Z.006C.B05.0802291410 date 02/29/08 bios0: Apple Inc. MacPro3,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR SSDT SSDT acpi0: wakeup devices P2P5(S4) P2P3(S4) ARPT(S4) RP04(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AC9M(S4) EC__(S3) NRP5(S4) NRP1(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz, 2793.40 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 398MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz, 2793.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz, 2793.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF cpu2: 6MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz, 2793.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF cpu3: 6MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 5 (application processor) cpu4: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz, 2793.00 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF cpu4: 6MB 64b/line 16-way L2 cache cpu4: smt 0, core 1, package 1 cpu5 at mainbus0: apid 4 (application processor) cpu5: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz, 2793.00 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF cpu5: 6MB 64b/line 16-way L2 cache cpu5: smt 0, core 0, package 1 cpu6 at mainbus0: apid 6 (application processor) cpu6: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz, 2793.00 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF cpu6: 6MB 64b/line 16-way L2 cache cpu6: smt 0, core 2, package 1 cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Xeon(R) CPU E5462 @ 2.80GHz, 2793.00 MHz cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF cpu7: 6MB 64b/line 16-way L2 cache cpu7: smt 0, core 3, package 1 ioapic0 at mainbus0: apid 8
Re: issues with amd64 on Apple MacPro
On 08.06.2014 22:55, Allan Streib wrote: I've been using amd64 snapshots on an early MacPro and had mixed results. The base itself is solid. Many packages less so. Browsers in particular (I mostly use xombrero with firefox as a fallback) are prone to crashing w/core files. In the snapshot I tried last night (dmesg below) a new behavior is that the browser will lock up, run away with 3 of the 4 CPUs, and even kill -9 doesn't work. I've seen this with both xombrero and firefox today. As I'm trying to use this as a desktop workstation this gets to be annoying. Is your user in staff in /etc/login.conf ? What's your ulimit -a output? Is there any reason to think that this system might do better with i386 snapshots? Allan OpenBSD 5.5-current (GENERIC.MP) #173: Sat Jun 7 11:02:46 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 10715041792 (10218MB) avail mem = 10421030912 (9938MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe00f0 (73 entries) bios0: vendor Apple Computer, Inc. version MP11.88Z.005C.B08.0707021221 date 07/02/07 bios0: Apple Computer, Inc. MacPro1,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT ECDT FACP HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices P2P5(S4) P2P3(S4) ARPT(S4) RP04(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AC9M(S4) EC__(S3) NRP4(S4) SRP1(S4) SRP3(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.35 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 7 (application processor) cpu2: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF cpu2: 4MB 64b/line 16-way L2 cache cpu2: smt 0, core 1, package 3 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF cpu3: 4MB 64b/line 16-way L2 cache cpu3: smt 0, core 0, package 3 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xd000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 2 (P1P2) acpiprt3 at acpi0: bus 5 (P2P5) acpiprt4 at acpi0: bus 3 (P2P3) acpiprt5 at acpi0: bus 15 (RP04) acpiprt6 at acpi0: bus 16 (PCIB) acpiprt7 at acpi0: bus 8 (NRP4) acpiprt8 at acpi0: bus 12 (SRP1) acpiprt9 at acpi0: bus 14 (SRP3) acpicpu0 at acpi0: C1 acpicpu1 at acpi0: C1 acpicpu2 at acpi0: C1 acpicpu3 at acpi0: C1 acpibtn0 at acpi0: PWRB memory map conflict 0xfff9/0x3 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 5000X Host rev 0x30 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE x8 rev 0x30 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01: msi pci3 at ppb2 bus 3 ppb3 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01: msi pci4 at ppb3 bus 4 ppb4 at pci2 dev 2 function 0 Intel 6321ESB PCIE rev 0x01 pci5 at ppb4 bus 5 em0 at pci5 dev 0 function 0 Intel 80003ES2 rev 0x01: msi, address 00:17:f2:03:41:94 em1 at pci5 dev 0 function 1 Intel 80003ES2 rev 0x01: msi, address 00:17:f2:03:41:95 Intel 6321ESB IOxAPIC rev 0x01 at pci1 dev 0 function 1 not configured ppb5 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci6 at ppb5 bus 6 pchb1 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0x30 ppb6 at pci0 dev 4 function 0 Intel 5000 PCIE x16 rev 0x30: msi pci7 at ppb6 bus 8 radeondrm0 at pci7 dev 0 function 0 ATI Radeon HD 4670 rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci7 dev 0 function 1
