Forum Debian Users Gang

Nie zapominaj że, G było zawzorowane (portage) na fbsd.
Dziwno bo wielu , którzy siedzieli na g , a spróbowali fbsd już nie chcą wracać  8[]
Ja  próbowałem  i  nie chce g próbować.

Jak?  To proste. Gdybyś ściągnął 1 cd możliwość instalacji src byłaby z cd ( pierwszy cd) . To dlatego mówiłem,że nie opłaca się ściągać bootonly.

Tworzysz pliczek z zawartością

*default host=cvsup.pl.freebsd.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_9_0
#*default release=cvs tag=RELENG_9_1
*default delete use-rel-suffix
*default compress
#src-sys
 src-all

potem w konsoli 

csup pliczek_ktory_stworzyłeś

i cieszysz się systemikiem w żródełkach. Po chwilach kilku  :P

Jak się będzie ściągło czytasz http://www.freebsd.org/doc/en_US.ISO8859-1/books/ha … elconfig.html

Wiesz że był włam na  sieć fbsd.... To dlatego. Dopóki nie zrobią auditu i wsjo nie będzie dobrze nie uruchomią infrastruktury.
Tak src są na pierwszym cd i kolejną metodą jest ich skopiowamnie i rozpakowanie.

yampress# kldstat
Id Refs Address            Size     Name
1   16 0xffffffff80100000 c9fe20   kernel
2    1 0xffffffff80da0000 21068    geom_mirror.ko
3    1 0xffffffff80dc2000 ffb0     ahci.ko
5    1 0xffffffff8102d000 1fde     nullfs.ko
yampress#

CPUTYPE=rodzaj-klocka w /etc/make.conf załatwia wszystkie flagi optymalizacji  kodu pod procesor.
ja mam
CPUTYPE=athlon64

For the tcsh shell:
# setenv PACKAGESITEftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/All

For the sh and bash shells:
# PACKAGESITE=ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/All ; export PACKAGESITE

FreeBSD 10 To Use Clang Compiler, Deprecate GCC
Posted by Michael Larabel on May 12, 2012

As indicated by the Q1-2012 FreeBSD Status Report, LLVM's Clang compiler is quickly replacing GCC for this popular BSD operating system. The developers are also making much progress in a GNU-free C++11 stack. For FreeBSD 10 they're aiming for Clang as the default C/C++ compiler, deprecate GCC, and to have a BSD-licensed C++ stack.

While the Q1-2012 FreeBSD Status Report was just talked about in the afore-linked article, the Clang and C++ items warranted their own more detailed article.

Going back to 2009, FreeBSD developers have worked to replace GCC with LLVM/Clang. Over time, there's been numerous improvements especially with the FreeBSD 9.0 release. The FreeBSD developers are interested in doing away with the GPL-licensed GNU Compiler Collection and instead use the Apple-sponsored LLVM/Clang work that's under a BSD-like license.

Powoli odchodzą od gcc, więc nie będą  się nim bawić,  a raczej dążą aby wstawić Clang.

PS
fbsd jest łatwiejszy od linuxa. Prościej się wiele rzeczy   konfiguruje. Wszystko jest na swoim jmiejscu/uporządkowane ze swoja logiką.

w pf możesz ustawiać limit na wejściu i wyjściu  interfejsu. 

pkg_add  ftp.freebsd.org/sciezka/nazwa-paki

to tak pojedyńczą pake.


Po instalacji fbsd nie trzeba normalnie nic eksportować / i nie trzeba instalować pkg_add  jest w base systemie.

Odnośnie G. Kompilacja jaja na poziomie instalatora jest bezsensem. Tak wiem można podlepić tego z instalatora. Ale dla mnie to beznadzieja takie rozwiazanie. A tu aby zainstalowaźć nic nie musisz kompilować.


Ustawienie flag dla kompilatora GCC jak w Gentoo
http://www.bsdguru.org/dyskusja/viewtopic.php?f=12&t=19889

/etc/make.conf
To make, or compile, a program is to build it from source code into machine
language. We’ll discuss building software in detail in Chapter 11. /etc/make.conf
controls how that building process works, letting you set options that directly
affect software builds. Remember, anything you add to make.conf affects all
software built on the system, including system upgrades. This may cause
upgrade failures.1 Many of the options from make.conf are only useful for
developers.
If you’re interested in setting options that affect only system upgrades,
use /etc/src.conf instead.
Here are some common features set in make.conf. Any values set here
require the same syntax used by make(1). For the most part, following the
examples is best.
CFLAGS
This option specifies optimization settings for building nonkernel programs.
Many other Unix-like operating systems suggest compiling software with
particular compiler flags, or CFLAGS . This practice is actively discouraged on
FreeBSD. System components that require compiler flags already have that
specified in the software configuration, and add-on software has that con-
figuration set for it separately. While people might recommend other settings
for CFLAGS, custom options are not supported by the FreeBSD Project.
In general, FreeBSD code is expected to compile most correctly out of
the box. The only thing that adding compiler options can do is impair
your performance. If you build FreeBSD with nonstandard flags and have
problems, remove those flags and build it again.
COPTFLAGS
The COPTFLAGS optimizations are used only for building the kernel. Again,
settings other than the defaults can build a non-working kernel.
CXXFLAGS
CXXFLAGS tells the compiler what optimizations to use when building C++
code. Be sure to use the += syntax when using CXXFLAGS, so that you add your
instructions to those specified in the software. Everything that I said above
about CFLAGS applies equally well to CXXFLAGS.
CPUTYPE=i686
Certain software can be optimized for different CPU types. By identify-
ing your CPU type in /etc/make.conf you tell the compiler to optimize for
your CPU.
This is most effective if you upgrade your system from source
FreeBSD will not only optimize everything in the base system
for your processor, but any third-party software you build afterwards will
also have the same optimizations.
On a standalone machine, always set CPUTYPE to match your CPU. If you
build FreeBSD on one machine and then NFS export /usr/obj and /usr/src
to other machines so they can upgrade without building, set CPUTYPE to the
lowest common denominator of CPUs on your systems.

i to http://www.bsdguru.org/dyskusja/viewtopic.php?f=9&t=21430

allbsd to ja bym nie brał do ustawienia w packagesite. Jest jeszcze inna zmienna packageroot

http://www.freebsd.org/doc/en_US.ISO8859-1/books/ha … rors-ftp.html


allbsd to ja tylko używam do tego.
https://pub.allbsd.org/FreeBSD-snapshots/
Do snapszotów  fbsd stable

PACKAGEROOT
By default, pkg_add -r attempts to download every requested package from
ftp://ftp.freebsd.org. This probably isn’t the best choice for you. The primary
FreeBSD mirror is very heavily used and can suffer from congestion. It might
also be further away from your computer. You can frequently get better
performance by choosing a less heavily used mirror. The PACKAGEROOT
environment variable tells pkg_add(1) to use a different FTP server. Set
PACKAGEROOT to a protocol and server name, not a full path. For example,
to use ftp5.us.freebsd.org as your source for packages, set:
# setenv PACKAGEROOT ftp://ftp5.us.freebsd.org
PACKAGESITE
This lists an exact path to check for a package repository. You might use this
if you wish to install only packages from a particular release, or if you have a
local package repository. (We’ll discuss a local package repository later in
this chapter.) Set PACKAGESITE as an absolute URL, as in this example for a
legacy, unsupported FreeBSD release:
# setenv PACKAGESITE ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/o … /packages/All

A w jaki sposób instalowałeś porty. Bo to zależy jak je aktualizować.  Aktualnie pod 9.0 wszystko zablokowane...
http://www.freebsd.org/doc/en_US.ISO8859-1/books/ha … ts-using.html
]:->

Na 8.x w tamtym tygodniu tak było.

ja wczoraj aktualizowałem 8.3 i przedwczoraj  9.0 i wszystko było ok

Nie wiem, co za jaj są z siecią mojego ISP - ale właśnie pobieram OpenBSD po ssl z allbsd.

Myślalem, ze to w gentusiu cos nie gra w końcu jajo z grsec i opcja IP-blackhole, kolejki, na interfejsach ifb*, ma co rozrabiać jednym słowem.

Włączam z drugiej partycji czystego jak psi kichol Wheezy 32 bit., bez żadnych podobnych udziwnień, dystrybucyjne jajo, najprostszy możliwy firewall.

I tam te same objawy, cd52.iso kończy się na 77% i ani chu* dalej.
Ściągnął się dopiero po ssl.
To samo na Fbsd  - na wirtualce  kvm
Na wszelki wypadek teraz leci większa sprawa, install52.iso - 241 mega.

Oczywiście admin i obsługa u ISP ma standardową odp -  SOA#1.
Ale ja, nawet jakbym coś spieprzył w Getusiu (może się zdażyć), to raczej w Wheezym już nie, bo tam nic we flakach nie majstrowałem, prawda?
Do majstrowania mam Gentusia, na Debianie czasem oglądam, co nowego w Gnome, KDE, Xfce  czy Mate, bo nie chce mi się czegoś kompilować, żeby używać przez 15 minut. ;)

Jeszcze raz dzięki za sznurka na allbsd. :)


I przy okazji jedno pytanko:
które foldery wrzucić do tmpfs (poza /tmp), żeby nie było efektu mielenia dyskiem, kiedy Portsnap czy pkg_add coś ściągają i rozpakowują?
Bo przy portsnap fetch update  na kvm dysk przeżywa ciężkie chwile, moje uszy też, a wolałbym częściowo ten proces wyciszyć, przy pomocy tmpfs.
Zwłaszcza dyzio się ucieszy, podobnie, jak przy wywaleniu Gentusiowego /var/tmp do tmpfs.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-12-04 08:09:37)

To właśnie przy extract jest największy i najdłuższy hałas.


CO do ISP, jak wprowadzili pppoe i i cudownego Junipera, to już chyba z 5 razy zgłaszałem, jak cała rurka była zatkana przez jakiegoś pacjenta pakietami UDP/ICMP.
Podejrzewam, że mają jakieś arcyślitaśne dziwactwa w filtrach na tym Juniperze, albo gdzieś dużo wyżej.

Najdziwniejsze, że do tego serwera mam naprawdę niedaleko:

lft ftp.icm.edu.pl
Tracing .....T
TTL LFT trace to SunSITE.icm.edu.pl (193.219.28.2):21/tcp
 1  XXXX (mój-ISP) 1.6ms
 2  out-mój-ISP  (Moj-ISP-router-BGP) 0.7ms
 3  ge-kix-kat.ip4.e-poludnie.pl (195.191.171.185) 1.8ms
 4  icm.tpix.pl (195.149.232.29) 6.2ms
 5  [target open] SunSITE.icm.edu.pl (193.219.28.2):21 6.7ms

Zwłaszcza, ze problem występuję na protokole nieszyfrowanym, a nie występuje po ssl, co mogłoby wskazywać na jakieś dziwaczne proxy, coś podobnego do l7, i podobne kfiatki..
Gdybym ja coś popieprzył, to nie byłoby żadnej różnicy, co ściaga.
Żeby Debian pociągnął 5,8 MB z 7,1, i przy następnych wznowieniach wget wsiąkał raptem 30 bajtów na 5 prób , to nie jest normalne zachowanie, to samo dotyczy axela, firefoxów (3 szt), opery i chrome.
Choć większość użytkowników sieci na swoich XP i Vistach z wiecznie włączonymi torrentami i trojanami, to też ciekawa sprawa.

Pozdrawiam
;-)

Coś przekombinowałem:

cat /etc/fstab
# Device    Mountpoint    FStype    Options    Dump    Pass#
/dev/ada0p2    /        ufs    rw    1    1
/dev/ada0p3    none        swap    sw    0    0

linproc /compat/linux/proc linprocfs rw 0 0
tmpfs /tmp   tmpfs rw,mode=1777  0 0
tmpfs /var/db/portsnap/files   tmpfs rw  0 0
tmpfs /var/tmp tmpfs   rw,mode=17777 0 0

cat /compat/linux/proc/meminfo
         total:    used:    free:  shared: buffers:     cached:
Mem:  1058234368 59326464 998907904 9953280 0 94208
Swap: 536870912 0 536870912
MemTotal:   1033432 kB
MemFree:     975496 kB
MemShared:     9720 kB
Buffers:          0 kB
Cached:          92 kB
SwapTotal:   524288 kB
SwapFree:    524288 kB

[root@localhost ~]# mount -a
mount: tmpfs : Operation not supported by device
[root@localhost ~]# kldload tmpfs
kldload: can't load tmpfs: Operation not permitted
[root@localhost ~]#

Teoretycznie za wysoki security level (1), ale przy uruchomieniu też nie montuje tmpfsów.

Edyta:
[ZROBIONE]

[root@localhost ~]# grep tmp  /boot/loader.conf 
tmpfs_load="YES"

[/ZROBIONE]

Przy okazji, czy *BSD dorobiło się odpowiednika Linuxowego cgroups?
Bo ten ostatni mam i używam, działa idealnie.
Nawet w domu sobie obciąłem uprawnienia wszystkich programów, które kiedykolwiek powodowały jakieś kłopoty, jak np wycieki pamięci, czy próbowały zająć cały procek.
Ostatnio nawet  portage i maszynki kvm dostały limity w dostępie do dysku przez moduł blkio, i wszystko chodzi bardzo grzecznie. ;)
Konfiguracja cgroup też jest banalnie prosta. :)

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-12-04 19:46:48)

Bez linuxproc nie dało się htopa odpalić.
A jego akurat używam zawsze.

Fakt, ze nie ma natywnej wersji htopa na *BSD, uczczę minutą ciszy. :D
Oczywiście, jakby się trafił jakiś serwer, to tam nie zamierzam takich rzeczy montować, ale u siebie takich problemów nie mam.

Na bezpieczeństwo /proc ja mam:

root ~> zgrep CONFIG_GRKERNSEC_PROC /proc/config.gz 
CONFIG_GRKERNSEC_PROC_GID=527
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_PROC=y
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_PROC_IPADDR=y

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-12-04 19:55:17)

Należy jednak pamiętać, że całe opowiastki o bezpieczeństwie /proc czy sysctl brzmią w jednym punkcie bardzo pociesznie.

Nie dlatego, ze jeden jest lepszy a drugi gorszy, ale dlatego, że w każdym systemie co jakiś czas pojawia się dziura, która pozwala wbić się na roota.
Jak jakiś skrypciarz czy prawdziwy haker wbije się na roota, to czy to Linux czy BSD, i tak ma pełną kontrolę nad całym systemem.

Znam 2 drogi ograniczenia ryzyka związanego z intruzem na koncie root na serwerze:
Pół dnia pieprzenia się z Grsecurity ACL i Gradm (w którym root jest traktowany jak zwykły durny pacjent), albo pół roku pieprzyć się z SELINUX strict, do którego i tak trzeba dokomponować PAXa, bo sam Selinux, to tylko diabelnie skomplikowany ACL, takich "bzdur" jak np pax_mprotect  w nim nie dodali, bo "po co".
Ciekawe, czy w *BSD da się roota łatwiej obciąć do niezbędnego minimum, niż w SELINUXIE.

MAC ACL we FreeBSD jest podobna, i na oko trochę łatwiejsza od Selinuxa, natomiast wyraźnie trudniejsza w konfiguracji od Grsecurity ACL.


Edyta:

tmpfs nigdy na fbsd nie robiłem dla kilku lokalizacji. Nie wiem czy pozwala  montować kilka miejsc.

mount
/dev/ada0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
linprocfs on /compat/linux/proc (linprocfs, local)
tmpfs on /tmp (tmpfs, local)
tmpfs on /var/db/portsnap/files (tmpfs, local)
tmpfs on /var/tmp (tmpfs, local)

Edyta:
Pieprzę portspapa.
Właśnie ciągnę cale drzewko przez svn, aktualizacja też będzie przez svn.
Portsnap strasznie mieli dyskiem zapisując do folderu /var/db/portsnap/snap, który i tak usuwa przy każdej aktualizacji.
Jak go zamontowałem jako tmpfs to portsap w ogóle nie chce działać, bo nie może wykonać komendy 

rm snap/

Nie wiem, czy twórcy portsnapa wiedzą, co to jest /tmp i do czego to jest,
ale jak nie wiedzą, to polecam maila w tej sprawie do developerów portage. :D
SVN robię wg tego: http://wiki.freebsd.org/PortsSubversionPrimer

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2016-04-18 18:39:00)

vermaden napisał(-a):

Jacekalex napisał(-a):

Przy okazji, czy *BSD dorobiło się odpowiednika Linuxowego cgroups?

http://wiki.freebsd.org/SummerOfCode2012/CPULimits
http://wiki.freebsd.org/Hierarchical_Resource_Limits

Jacekalex napisał(-a):

Fakt, ze nie ma natywnej wersji htopa na *BSD, uczczę minutą ciszy. :D

Widocznie tworcy HTOP napisali go myslac tylko o dzialaniu na Linux, a ze FreeBSD moze byc Linuxem a nie odwrotnie, to moga to wykrozystac, moze zupelnie nie oplaca im sie tego portowac, skoro dziala przez LINUX_COMPAT. Moze tworcy HTOP wrzucili za duzo Linuxism'ow i tyle, zawsze mozesz sam przeportowac, zeby bylo natywne. Inna sprawa, ze LINUX_COMPAT to nie emulacja, tylko implementacja Linux API, wiec to tez jest natywna implementacja, a nie emulacja. Z reszta dlatego Matrixa renderowali na FreeBSD a nie na Linux, bo aplikacje 'Linuxowe' dzialaly na FreeBSD szybciej w LINUX_COMPAT nie natywnie na Linuxie.

Idac tropem 'minuty ciszy', to czy Linux juz dorobil sie czegokolwiek na kształt ZFS Boot Environments (za pomoca sysutils/beadm)?
Czy problemy/destabilizacja z hal/polocykit/udev/systemd w koncu sie ustabilizowaly i Linux ma juz dojrzale rozwiazanie na Hardware Abstraction Layer, cos co by dorownywalo djrzaloscia devd z FreeBSD?
Czy Linux ma juz 'natywne' rozwiazanie na miare FreeBSD Jails, czy dalej zapewniaja to tylko 'zewnetrzne' projekty?
Czy problemy z ALSA/PulseAudio/Jack/... sa juz 'za nami' i mozna w koncu uzywac wielu roznych zrodel OSS, jest to w koncu zrobione porzadnie jak we FreeBSD?

Mozna tak oczywiscie sobie 'strzelac' w obie strony, pytanie jaki jest tego sens?

Minuta ciszy była dlatego, że przeczytałem o niebezpieczeństwie i "niepotrzebności" montowania linuxproc.
Ja osobiście ani przeciwko *BSD ani LINUX_COMPAT nic nie mam.
Alsa śmiga u mnie elegancko, problemów brak, Pulseaudio nie używam i nie zamierzam używać.
Hal? a co to takiego? już zapomniałem, że kiedyś było ;)
Systemd - nie używam, i raczej nie zacznę, choć muszę przyznać, ze w Debianie jakośtam działa, nawet prawidłowo.
Integracja systemd z udevem spowodowała rozpoczęcie prac nad projektem eudev, które rozpoczęli developerzy Gentoo.
Istnieją istotne przesłanki do tego, abym bliżej zaprzyjaźnił się z tym projektem.
ZFS się w Linuxie bardzo przyda, choć to jeszcze daleka droga, żeby się pojawił.
FreeBSD jails?
Podobne możliwości ma lxc - dostępny w każdej dystrybucji, jest też jailkit,
A i zwykły linuksowy chroot , dozbrojony przez Grsecurity pod względem bezpieczeństwa nie pozostaje w tyle, wręcz przeciwnie.
Do tego np kvm jest w każdym dystrybucyjnym jaju i chodzi nawet pod jajem z Grsec i Paxem, czego o Xenie  nie mogę powiedzieć, a i z Virtualboxem różnie bywa w takich warunkach.

Jeśli chodzi o PA, SystemD i inne pomysły tego samego autora, to mam o nich znacznie gorszą opinię, aniżeli jakikolwiek użytkownik *BSD.

Za sznureczki dotyczące limitowania dziękuję, przydadzą się, choć pod względem konfiguracji wyglądają chyba groźniej, niż cgroups.
Ale to pierwsze wrażenie, w praniu może się okazać co innego. ;)

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-12-04 22:10:22)