Покажи Публикации - wfw
* Виж публикациите на потр. | Виж темите на потр. | Виж прикачените файлове на потр
Страници: [1] 2 3 ... 17
1  BSD секция / Настройки на софтуер / Re: redhat маха iptables ! -: Май 12, 2019, 01:10
не мисля, че само redhat махат iptables...
в debian testing в момента ситуацията е подобна за съжаление:

https://wiki.debian.org/nftables
2  Linux секция за начинаещи / Настройка на хардуер / Re: Разрешаване на проблем със SSD и SATA 3 контролера му.. -: Апр 06, 2018, 01:20

за коя опция в биос говориш и този сата 3 контролер нее ли за райд? тоест ако го  ползвам райд нали няма да имам трим? аз затова не го пускам до сега.. или има начин да имам трим и  да ползвам контролера?

LSI контролерите имат по 2 фирмуера - IT и IR. В единия всъщност нямаш RAID леър, ако мога така да го нарека в БИОС-а, това ти позволява една идея по-бърза работа директно с диска. Често се ползва за системи, които ползват дисковете в JBOD режим, например, ако ползваш ZFS.

От уикито на LSI може да попаднеш на следната информация:

Only HBA that are flashed to IT firmware or MegaRAID drives that are set to JBOD support TRIM
3  Хардуер за Линукс / Сървъри / Re: Въпрос за SSD.. -: Мар 04, 2018, 14:35
Ти само дъното ли имаш или цял сървър със SAS кабелите? Че в спецификацията пише че sas портовете са 6Gb/s.
цяла конфигурация  съм сглобил. имах само дъното. кабели лесно се намират, ама нямам сас контролер. в дъното има мини сас два порта ама нз те дали биха ми свършили работа..  Проблема е, е съм невеж и не разбирам. помогни ми :(

SAS портовете са обратно съвместими със SATA устройства, така че няма проблем да включиш SATA дискове на SAS портове. Обратното не е възможно.

Също така няма проблем да заредиш от SAS/SATA Контролер, стига самия контролер да има БИОС. При условие, че ти работи на дъното, за какъв ти е да купуваш допълнително хардуер, и без това събираш нещо бюджетно доколкото разбирам.
4  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Intel security проблем -: Яну 05, 2018, 09:45
Цитат
Yves-Alexis Perez corsac@debian.org
   
00:25 (9 hours ago)
   
to debian-securit.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -------------------------------------------------------------------------
Debian Security Advisory DSA-4078-1                   security@debian.org
https://www.debian.org/security/                        Yves-Alexis Perez
January 04, 2018                      https://www.debian.org/security/faq
- -------------------------------------------------------------------------

Package        : linux
CVE ID         : CVE-2017-5754

Multiple researchers have discovered a vulnerability in Intel processors,
enabling an attacker controlling an unprivileged process to read memory from
arbitrary addresses, including from the kernel and all other processes running
on the system.

This specific attack has been named Meltdown and is addressed in the Linux
kernel for the Intel x86-64 architecture by a patch set named Kernel Page Table
Isolation, enforcing a near complete separation of the kernel and userspace
address maps and preventing the attack. This solution might have a performance
impact, and can be disabled at boot time by passing `pti=off' to the kernel
command line.

We also identified a regression for ancient userspaces using the vsyscall
interface, for example chroot and containers using (e)glibc 2.13 and older,
including those based on Debian 7 or RHEL/CentOS 6. This regression will be
fixed in a later update.

The other vulnerabilities (named Spectre) published at the same time are not
addressed in this update and will be fixed in a later update.

For the oldstable distribution (jessie), this problem will be fixed in a
separate update.

For the stable distribution (stretch), this problem has been fixed in
version 4.9.65-3+deb9u2.

We recommend that you upgrade your linux packages.

For the detailed security status of linux please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/linux

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org

Това е официалното съобщение. Копирам го, защото има подсказки как може да се спре пач-а по време на зареждане и че кръпката решава само единия от двата проблема.
5  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Intel security проблем -: Яну 05, 2018, 00:22
за изтриване..
6  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Intel security проблем -: Яну 05, 2018, 00:11
малко нова информация по темата:

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html

https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

и разширена информация по втория пост:

https://googleprojectzero.blogspot.bg/2018/01/reading-privileged-memory-with-side.html

Проблема вече става не-само-интел...
7  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Intel security проблем -: Яну 04, 2018, 14:26
При Дебиан работата не е красива:

https://security-tracker.debian.org/tracker/source-package/linux

Код:
Bug wheezy jessie stretch buster sid Description
CVE-2017-5753 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2017-5715 vulnerable vulnerable vulnerable vulnerable vulnerable
8  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Intel security проблем -: Яну 04, 2018, 01:31
Вие се чудите за микро код в процесора, а какво ще кажете за цяла операционна система в интелските чипсети (на Андрю Таненбаум Миникс-а) - от Декемврийския скандал.

http://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/
Слава Богу, че и и за там не са намерили някой remote exploit, че доколкото четох преди си имал и напълно работещ network stack.
9  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: apache2 динамични виртуални хостове + SNI + Lets Encrypt? -: Яну 04, 2018, 01:27
cPanel и подобните си ресват сървъра като добавиш домейн (vhost). Но както всеки сървис на линукс това става за секунда така, че не е проблем.

cPanel влачи един уеб сървър, стартиран с root. Не ми се прекомпилира apache за тая работа, не ми се занимава с CGI + SUID, а и не съм го правил и шанса да го напиша не както трябва е голям :) Опитвам се да имам сравнително чиста среда - само пакети от текущия дебиан и малко код. Е, вече има rabbitmq в системата, но го ползвам и за други неща. Идеален е за RPC (надявам се).
10  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: apache2 динамични виртуални хостове + SNI + Lets Encrypt? -: Яну 03, 2018, 23:09
Искаше ми се да не рестартирам уеб сървъра при добавянето на нов домейн, но явно няма да стане. Вече си написах малък скрипт, през който изпращам съобщения на message broker, който пък ги доставя на един скрипт, стартиран като root, така ще мога да си добавям сайтове през една страничка, т.е. през процес с правата на уеб сървъра.
11  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Intel security проблем -: Яну 03, 2018, 23:01
Че това през BIOS-а ли го прави операционната система ?
Не. Инсталирания допълнително  микрокод подменя оригиналния при зареждане на ядрото. Официално, този микрокод коригира грешки в първоначално зададения и добавя нови възможности за работата на процесора, но в дейтвителност не се знае, какво точно включва.

https://wiki.debian.org/Microcode

Доколкото разбирам и БИОС-а може да съдържа ъпдейт на микрокода.

Тук е доста добре обяснено, няма общо с микрокода, правят Kernel Page Table Isolation (KPTI) и вече въпросната таблица с адреси не е достъпна от потребителските процеси:

https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/

12  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Intel security проблем -: Яну 03, 2018, 13:13
Интересното е, че AMD не са поразени което е поредната добра новина за EPYC.

Мярнах в една от новините, че кръпката на ядрото, която в момента е качена не прави разлика между интел и амд, т.е. и за двата производителя ще има забавяне, ако се качи кръпката.

Интересно ми е колко е напечено при клауд провайдерите, защото доколкото видях ще има масов рестарт на виртуалки...
13  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Intel security проблем -: Яну 03, 2018, 10:14
Нищо ново под слънцето... Не се ли наблюдава навсякъде? Съкратен цикъл на производство, намаляване на разходите, малко тестове... Дали е умишлено или не е въпрос на спекулация.

Да не казвам голяма дума, но за Интел е почти идеална ситуацията - всички текущи системи са афектед :) до -30% надолу за виртуалните машини. Изведнъж продават "новите" си процесори без въпросния бъг, които реално са 5% по-бързи, само че сега стават до 35% по-бързи :)
14  Linux секция за напреднали / Хардуерни и софтуерни проблеми / проблем с рутирането към виртуална машина -: Дек 02, 2017, 12:50
Здравейте,
имам много проста схемичка, знам, че е нещо лесно, но не мога да се сетя как да го намеря и реша:

Интернет -> Хипервайзор (br0) с IP 77.88.99.100 -> виртуална машина gateway с 2 интерфейса (77.88.99.101 към br0) и 10.11.12.1 към br1. -> виртуална машина във вътрешната мрежа - 10.11.12.2 към br2, на която работи един ДНС сървър

машината 10.11.12.2 си работи идеално, порт форуърда работи от реалното ИП към услугата, която предоставя, машината има интернет с MAQUERADE, но когато се опитам от гейта да направя telnet 10.11.12.2 53 с tcpdump виждам, че source IP адреса е 77.88.99.101, т.е. публичния адрес на гейта. Не е ли нормално да бъде вътрешния адрес, след като двете машини имат интерфейси в една и съща мрежа и той да се ползва за връзка м/у тях?

Освен това в arp таблицата на вътрешната машина виждам срещу мак адреса на гейта, че има 2 IP адреса, което очевидно не е така.

Идеи какво съм омазал?
15  Linux секция за напреднали / Хардуерни и софтуерни проблеми / apache2 динамични виртуални хостове + SNI + Lets Encrypt? -: Ное 29, 2017, 15:55
Здравейте,

най-общо казано искам да си пусна един уеб сървър, на който да си направя няколко (хиляди) HTTPS сайта, като всеки си има отделен VHOST. В идеалния случай, конфигурацията ще приема новите VHOST-ове без рестарт на уеб сървъва.

Ако сайтовете работят на HTTP няма никакъв проблем, ползваме mod_vhost_alias:

https://httpd.apache.org/docs/2.4/vhosts/mass.html

Не обичам, когато в документацията на HTTPD нещо е написано с червено: mod_rewrite is not the best way to configure virtual hosts. You should first consider the alternatives before resorting to mod_rewrite. See also the "how to avoid mod_rewrite document.
Затова изключвам тази опция.

mod_macro може да ми направи конфигурацията четима, но не решава проблема ми, защото след създаването на всеки VHOST ще се налага рестарт на уеб сървъра, а и редакция на конф. файл, което създава предпоставки за "фатална" грешка :)

Главния проблем е, че искам HTTPD да търси за SSLCertificateFile когато дойде заявка, а той го прави по време на първоначалното зареждане.

Обмислям и вариант с HAPROXY, който го играе SSL offloader и след него да пращам HTTP до уеб сървъра, но това е усложняване на схемата, което бих предприел само, ако нямам избор.

Та, някой да е правил нещо подобно? Някоя хитра идея, която му убягва? :)
Страници: [1] 2 3 ... 17