| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Obviamente, não é para usar em máquinas de produção. Para os utilizadores de RedHat: RPMS
hugs
Strange |
| | | | | Para quem tiver interessado em saber o que trás de novo o kernel 2.6, visite este link. Uma das coisas que me chamou a atenção no link acima referido, foi: Another security-related change is that binary modules (for example, drivers shipped by a hardware manufacturer) can no longer "overload" system calls with their own and can no longer see and modify the system call table. Isto quer dizer que por exemplo os rootkits que andam para aí a utilizar LKM para se tornarem "invisiveis" modificando system calls vão passar a ser inuteis? Ou estou errado? Cumprimentos,
Paulo
|
| | | | | | Bom, nao necessariamente. A questao e' que agora ha' uma verificacao da licença sob a qual o modulo e' publicado, e de acordo com ela, tem acesso a mais ou menos syscalls. Se for uma licença considerada free -- GPL, GPLv2, GPL and additional rights, Dual BSD/GPL, Dual MPL/GPL (ver em include/linux/module.h) -- tem acesso aos simbolos exportados como EXPORT_SYMBOL_GPL. Caso seja um modulo proprietario, obviamente que nao pode ser publicado debaixo de nenhuma dessas licenças, o que fara' com que as interfaces do kernel a que tem acesso sao notoriamente reduzidas.
Quantos aos rootkits, bom, suponho que nao ha' nada que impeça alguem de os escrever de modo a que incluam MODULE_LICENSE("GPL"); ... Ate' porque nem sequer e' preciso que tenha sido compilado suporte para modulos para se injectar codigo no kernel. Desactivar modulos por motivos de seguranca e' um logro -- apenas da' uma falsa sensaçao de seguranca.
--
(c) Anónimo Cobarde, 1999-2002 |
| | | | Penso que neste caso a questao nao e' essa. O que se passa e' que agora a syscall table (um simples array de pointers para as syscalls, nomeadamente sys_call_table) deixou de ser exportada pelo kernel. Dai' que os modulos externos ja' nao podem fazer o que chamam de 'hijacking' das system calls (basicamente substituirem o codigo das syscalls nativas) uma vez que simplesmente nao as veem, mesmo que estejam sob qualquer uma das licencas mencionadas.
|
| | | | | viva já tenho esse kernel compilado e a funcionar. nao existem muitas mais funcionalidades visiveis em relacao ao 2.4.22(-pre), no entanto os menus de configuracao do kernel sofreram algumas alteracoes. o sistema de build melhorou imenso: já nao é preciso fazer make dep-- as dependencias sao calculadas on-demand. O problema é que certas dependencias nao estao a funcionar la muito bem. EXistem certas opcoes que quando se mudam implicam recompilar o kernel e modulos quase todos! modulos: aqui tive problemas. Os velhos modutils ja nao funcionam. Tem que se instalar o pacote module-init-tools-0.9.12 (esta no tux.cprm.net ... linux/people/rusty/modules acho eu) e substituir o /etc/modules.conf pelo /etc/modprobe.conf . Vem la um script que faz a conversao, mas há certos modulos que mudaram e tem que se ter cuidado com isso (isso vai afectar os modulos de som). Alem de criar os aliases neste ficheiro, é preciso um passo logo no inicio: echo /sbin/modprobe > /proc/sys/kernel/modprobe . Esta feature ja existia, mas esse ficheiro costumava vir com defaults. Agora vem vazio, o que significa que os modules autoloading nao vao funcionar. Tem que se meter algumas no inicio do boot aquele echo. neste novo kernel, ja nao temos que usar o subsistema scsi para aceder aos CDRWs. Podemos tirar das opcoes todos os generics scsi (ide-scsi) e usar o device /dev/hdc (whatever) directamente nas tools. Exemplo: cdrecord dev=/dev/hdc -v x.iso . Alem de ser mais rapido (tira-se o layer scsi-atapi do meio) existe uma grande vantagem funcional: o modulo usado para escrever é o mesmo para ler. Tipicamente eu fazia: cdrecord -scanbus (carregava o ide-scsi via autoloading); gravava; modprobe -r (removia o modulo ide-scsi); mount /mnt/cdrom (carregava o ide-cd) para ler. Agora ja nao é preciso nada disto: cdrecord && mount seguido funciona. tenho ainda uma msg no boot sobre flushing (bdflush/updated) mas ainda nao resolvi esse. deve resumir-se a instalar uma versao nova do bdflush. outra nota é que em X aconteceu uma ou outra coisa esquisita: o xosview (monitorizar disco, cpu, rede, etc) simplesmente nao arranca e fica a consumir cpu-- tipo loop infinito; e o xterm ficou muito lento. Um ls -al numa directoria grande demora consideravelmente. Pensava que isto um problema do X, mas outros utilitarios comportam-se normalmente. Exemplo: o rxvt é rapido a fazer o ls -al. cya
--
carlos
|
| | | | | | >modulos: [snip] Alem de criar os aliases neste ficheiro, é preciso um passo logo no inicio: echo /sbin/modprobe > /proc/sys/kernel/modprobe . Esta feature ja existia, mas esse ficheiro costumava vir com defaults. Agora vem vazio, o que significa que os modules autoloading nao vao funcionar. Tem que se meter algumas no inicio do boot aquele echo.
Edita o teu /etc/rc.d/rc.sysinit e procura a linha onde se verifica se /proc/ksyms existe e muda esse teste para /proc/modules. Voila', module autolading :)
>tenho ainda uma msg no boot sobre flushing (bdflush/updated) mas ainda nao resolvi esse. deve resumir-se a instalar uma versao nova do bdflush.
Edita o teu /etc/inittab e remove (ou comenta) a linha que diz "ud::once:/sbin/update", ou semelhante.
>outra nota é que em X aconteceu uma ou outra coisa esquisita: o xosview (monitorizar disco, cpu, rede, etc) simplesmente nao arranca e fica a consumir cpu-- tipo loop infinito; e o xterm ficou muito lento. Um ls -al numa directoria grande demora consideravelmente. Pensava que isto um problema do X, mas outros utilitarios comportam-se normalmente. Exemplo: o rxvt é rapido a fazer o ls -al.
O problema do 'xosview' deve-se ao facto do output de /proc/stat ter mudado consideravelmente. Precisas de instalar uma versao mais recente.
Quanto ao problema do xterm, estas a usar devfs e devpts? Se sim, instala o ultimo pacote do devfsd disponivel pela tua distro, e certifica-te que realmente montas o devpts em /dev/pts. A partir do 2.5.60-e-qualquer coisa passou a ser mandatorio, por isso verifica se o teu /etc/fstab contem uma linha para o montar:
$ grep pts /etc/fstab
none /dev/pts devpts mode=0620 0 0
--
(c) Anónimo Cobarde, 1999-2002 |
| | | | Respondendo a mim proprio:
O problema do xterm pode ser outro. Ha' um bug em versoes mais antigas do gnome-terminal (que suponho e' baseado no xterm, mas posso estar enganado), bug esse que so' se torna aparente com o 2.{5,6} devido 'as profundas mudancas no scheduler. No gnome-terminal ja' foi corrigido, podera' ainda nao ter sido no xterm, se e' que ambos partilham uma codebase mais ou menos comum.
--
(c) Anónimo Cobarde, 1999-2002 |
| | | | | "Esta feature ja existia, mas esse ficheiro costumava vir com defaults." Não, mas os scripts de arranque costuma verificar se /proc/ksyms como indicação de suporte de módulos por parte do kernel. O 2.6 já não cria esse ficheiro. "Alem de ser mais rapido (tira-se o layer scsi-atapi do meio) existe uma grande vantagem funcional: o modulo usado para escrever é o mesmo para ler." Não notarás uma maior rapidez. Além disso, nada te impedia anteriormente de usar exclusivamente o ide-scsi para ler e escrever cds/dvds. De qualquer modo, usar atapi é mandatório no 2.6-pre, já que ide-scsi está "broken" "tenho ainda uma msg no boot sobre flushing (bdflush/updated) mas ainda nao resolvi esse." A resolução é simples: desliga-o. O novo kernel não precisa do daemon. "e o xterm ficou muito lento." Problemas de X são normalmente devido a má interacção entre um nice -n -10 X e preemptive kernel. Verifica que o teu sistema não arranca o servidor X desse modo. Mas não sei se será essa a causa se apenas o xterm se comporta assim.
hugs
Strange |
| | | | cdrecord dev=/dev/hdc -v x.iso . Alem de ser mais rapido (tira-se o layer scsi-atapi do meio) existe uma grande vantagem funcional: o modulo usado para escrever é o mesmo para ler. Tipicamente eu fazia: cdrecord -scanbus (carregava o ide-scsi via autoloading); gravava; modprobe -r (removia o modulo ide-scsi); mount /mnt/cdrom (carregava o ide-cd) para ler. Agora ja nao é preciso nada disto: cdrecord && mount seguido funciona Já podias montar o cdrom na mesma .. mas usas o device /dev/scd[num] respectivo para montar o cdrom para leitura ...(ou mudas o link /dev/cdrom para apontar para /dev/scd[0]) .. Para isto precisas de ter o SCSI CD-ROM activado no kernel para além do generic SCSI ... Por outro lado, acredito que fique mais rápido sem o layer scsi pelo meio ...;)
|
| | | |
modulos: aqui tive problemas. Os velhos modutils ja nao funcionam. Tem que se instalar o pacote module-init-tools-0.9.12 (esta no tux.cprm.net ... linux/people/rusty/modules acho eu) e substituir o /etc/modules.conf pelo /etc/modprobe.conf . Vem la um script que faz a conversao, mas há certos modulos que mudaram e tem que se ter cuidado com isso (isso vai afectar os modulos de som).
Isso pq se passa a usar o ALSA por default, e não o OSS como antes. Eu ja uso o ALSA ha mais de 1 ano.
Alem de ser mais rapido (tira-se o layer scsi-atapi do meio) existe uma grande vantagem funcional: o modulo usado para escrever é o mesmo para ler. Tipicamente eu fazia: cdrecord -scanbus (carregava o ide-scsi via autoloading); gravava; modprobe -r (removia o modulo ide-scsi); mount /mnt/cdrom (carregava o ide-cd) para ler. Agora ja nao é preciso nada disto: cdrecord && mount seguido funciona.
Alguem te devia ter dito que se selecionasses SCSI cdrom support no kernel podias fazer mount /dev/scd1 /mnt/cdrom. E duvido que seja mais rapido por usar o ATAPI directo ate pq o ATAPI nao passa de uma maneira de mandar comandos SCSI pelo bus IDE.
|
| | | | so vamos esperar que a saida do Linus da Transmeta, reduza os prazos das releases, a 2.4 final ocorreu quase 1 ano apos a previsao inicial. A 2.6 nao saira antes do final do mes de Julho.
IBM executives said in June that the company expected products using the 2.6 kernel to be released in the first half of 2004. Previously, they had hoped for the second half of 2003.
e ainda queria alguem que esta fosse a 3.0 :\
embora nao entenda muito este conceito pre1 test como major release ie uma 2.6 ao inves de uma 2.576 compreendo que o objectivo do Linus e' picar o pessoal para o derradeiro teste final, a ver vamos se ainda sai antes do MES de agosto.
ja tou a ver a miriade de people de laptop na beach a testar o ultimo kernel
ou
a ver as suas ferias "interrompidas" de forma abrupta por que o HotShot la do IT dept decidiu meter o ultimo kernel em maquinas de producao
Make World; Not War; |
| | | | | | A saida do Linus da Transmeta pouco ou nada vai afectar a sua capacidade de trabalho, tal como ele proprio referiu na altura do anuncio. Como tal, o facto de ele continuar a trabalhar la' ou nao nao devera ter qualquer influencia numa saida mais ou menos rapida do 2.6. Como ele proprio tambem referiu.
O 2.4 teve, se nao me engano, 12 versoes -test e uma versao -prerelease, mediando cerca de 7 meses e 1 semana entre o primeiro -test1 e o 2.4.0 final (25 de maio de 2000 a 4 de janeiro de 2001). O ciclo para o 2.6 devera' ser, previsivelmente, menor, devido a varios factores (entre os quais a importancia fulcral do Andrew Morton, e tambem ao facto de haver uma base de beta testers muito mais alargada). Possivelmente teremos o 2.6.0 algures para o outono, ou se algo correr horrivelmente mal, para o fim do ano.
Btw, ha' alguem suficientemente irresponsavel para correr o 2.6.0-test1 numa maquina de producao, quando e' sabido que tem varios problemas de seguranca conhecidos e documentados? o -test2 ja' devera' ter a maioria deles corrigidos, mas o -test1, segundo o Alan Cox tem pelo menos 1 remote crash e 1 local root.
--
(c) Anónimo Cobarde, 1999-2002 |
| | | | sim a 2.4 era para sair ainda em 2000 ie finais de dezembro mas acabou por sair 5 janeiro 2001
e sim decorreram 7 meses, mas isto ja depois das provisoes iniciais terem sido alteradas dai o "quase 1 ano" e nao "quase meio ano".
Btw, ha' alguem suficientemente irresponsavel para correr o 2.6.0-test1
acredito que muitos. 2.6.0 stable final final final muitos vao actualizar, e depois os problemas vao surgir. sinceramente, na minha opiniao as ultimas 2, 3 finais do branch beta e' que deviam ser os pre test1 e 2 e 3 e 4 e por ai fora e nao passar para o odd branch.
o problema sendo 2.5.75 ninguem instala ninguem experimenta ninguem reporta bugs ninguem nada, e ai compreendo o linus ao subir um valor a odd branch para picar o pessoal.
como ele diz "its just a number..."
esperar para ver
Make World; Not War; |
| | | | Seguindo aquilo que aconteceu com o 2.4 , só quando chegar o 2.6.12 ou 14 é que sequer penso em mudar alguma coisa... Assum de repente estou a lembrar-me das barracadas do 2.4.12 e 2.4.13...
|
| | | | Assum de repente estou a lembrar-me das barracadas do 2.4.12 e 2.4.13...
Tambem afectaram a arvore 2.2
Andavas com o 2.0 na altura? Ja para não falar que tb tiveste ate ao 2.4.20 remote DoS e local root bugs. Bom o melhor é mesmo usar o Windows ;)
|
| | | | Que se comecam com um "vamos la a ver" e a meio da compilacao se cancela com um suspiro "se calhar e melhor estar quieto".
Seja como for, estou ancioso por este novo kernel. Talvez agora de para jogar quake enquanto se gravam CDs ;)
## I live the way I type; fast, with a lot of mistakes. |
| | | | | | Talvez agora de para jogar quake enquanto se gravam CDs ;)
Bem, quake não sei, mas com o 2.4.20 não tenho problemas nenhuns em gravar CDs enquanto compilo o mozilla (está bem, o meu gravador é apenas 8x).
-- Carlos Rodrigues
|
| | | |
Bem, quake não sei, mas com o 2.4.20 não tenho problemas nenhuns em gravar CDs enquanto compilo o mozilla (está bem, o meu gravador é apenas 8x).
O meu é de 52x e nao tenho problemas. Posso estar a fazer tudo e mais alguma coisa ao mesmo tempo que gravo a 52x. São as maravilhas do BurnFree :)
|
| |
|
